MCP Server

Polygent ships a built-in MCP (Model Context Protocol) Server at the /mcp endpoint. Any MCP-compatible agent can call its tools to search tickets, fetch ticket details, and inspect session details — letting agents reason about your team's work directly without copy-pasting context.

What MCP gives you

Out of the box, every supported provider's agent — running inside or outside Polygent — can:

• Look up tickets by free-text search with stage and workspace filters
• Pull full ticket details including stage history and session summaries
• Pull session details including user, agent, and summary messages

So an agent working on "fix the bug from PT-457" can resolve PT-457 itself instead of asking you for the description.

Available tools

Tool	Purpose	Notes
search_tickets	Free-text ticket search	Supports OR logic, stage/workspace filters
get_ticket_details	Fetch one or more tickets in batch	Includes stage history, session summary
get_session_details	Fetch one or more sessions in batch	Includes user/agent/summary messages
create_ticket	Create a ticket from chat	Default: opens an interactive form; supports autoCreation / autoQueue for one-shot creation
ask_user_question	Ask the user a multiple-choice question	Renders an interactive choice UI; the user's answer is delivered back to the agent as a new message
add_memory_items / get_memory_items / remove_memory_items	Read/write workspace memory stores	Items are JSON arrays passed as strings
send_message	Send an inbox message to a user or all workspace members
write_plan	Render a Plan side panel in the chat and persist the plan	Chat sessions only
edit_plan	Revise the persisted plan via exact old/new string replacement (like the Edit tool; optional replaceAll) and refresh the open panel	Chat sessions only; the only way to update an existing plan
read_plan	Read the persisted plan content	Chat sessions only; use to recover the plan in a later turn (e.g. after context compaction) before calling edit_plan

Provider integration

Polygent's MCP server is exposed as a standard MCP HTTP endpoint. Each supported provider has its own way of registering MCP servers — Polygent generates the right config snippet for you.

Each supported provider registers MCP servers in its own way — a launch flag, a settings file, or an environment variable. Polygent generates and injects the correct configuration for the selected provider automatically.

Sessions launched by Polygent already have the MCP server pre-wired — agents can call the tools without any user setup.

External agents

Want your own agent (running outside Polygent) to use these tools? Point it at:

https://<your-polygent-server>/mcp

The /mcp endpoint requires no authentication so external agents can connect without API keys. The data it exposes — ticket titles, descriptions, stage history — is the same data visible in the UI to workspace members.

Security note for operators: If your Polygent server is network-exposed, the /mcp endpoint is reachable by any client that can reach the server. If this is a concern, restrict access to /mcp at the network or reverse-proxy layer (e.g., allow only internal IP ranges).

Example agent prompts

With MCP wired up, agents can self-serve common questions:

• "What's the description of ticket PT-456?"
• "List all tickets in QA right now in the mobile workspace"
• "Summarize the session attached to PT-512"
• "Find tickets mentioning 'auth bug' in the last week"

The agent calls the MCP tools, and Polygent answers — no human in the loop required.

User-defined MCP servers

Beyond the built-in Polygent MCP, administrators can register additional MCP servers so every agent run can reach your own tools — an internal docs server, a database query tool, a deployment API, a third-party MCP service. Manage them under Developer Tools → MCPs.

Each enabled server is injected into every agent run alongside the built-in Polygent MCP, so the model sees its tools automatically with no per-session setup.

Field	Notes
Name	A short identifier (letters, digits, _, -). Cannot be polygent — that name is reserved.
Transport	Streamable HTTP (the standard remote MCP transport). Local stdio servers are not supported.
URL	The absolute http:// / https:// URL of the server's endpoint.
API Key	Optional bearer token, sent as an Authorization: Bearer header on every request.
Enabled	Turn off to keep the entry but stop injecting it on the next run.

Security: API keys are write-only — once saved, the UI shows only whether a key is set, never the value itself. A malformed or unreachable server is skipped so one bad entry can't break other agent runs.

Scoping to bots

A bot can be restricted to a subset of the registered MCP servers (and a subset of the built-in Polygent tools). Leave the allowlist empty to give the bot every enabled server, or pick specific ones — useful for a read-only support bot that should reach your docs MCP but nothing that can change state. See the Bots guide.

Examples

Give agents your internal knowledge base Register an MCP server that exposes your company wiki or runbooks. Now any Develop session can answer "how do we deploy the billing service?" by calling your tool directly, instead of you pasting the runbook into the chat.

A read-only data lookup for a support bot Stand up an MCP server that wraps a read replica of your database. Create a support bot, set its MCP allowlist to just that server plus the built-in ticket-search tools, and enable read-only mode — the bot can answer "how many orders failed yesterday?" without any write access anywhere.

Permissions

Permission	Capability
mcps.view	View the MCPs page and the configured servers
mcps.manage	Create, edit, enable/disable, and delete MCP servers

Read-mostly by design

Most MCP tools are read-only — search_tickets, get_ticket_details, get_session_details, get_memory_items, read_plan. State changes are limited to user-visible, scope-checked operations: create_ticket (opens an interactive form by default), add_memory_items / remove_memory_items (against pre-existing stores), send_message (inbox), and write_plan / edit_plan (chat-session-scoped plans). Destructive operations against tickets and sessions still flow through the authenticated REST API and the UI.