MCP servers: tools for agents
What MCP is, how Gleyk uses MCP servers as a source of tools for agents, chat and research, the organization's server registry, the platform's built-in server and connecting external ones.
Model Context Protocol (MCP) is an open standard for exchanging context and tools between language models and external systems. A server publishes a set of tools with a description and an argument schema, and a client calls them over JSON-RPC. Gleyk uses MCP in both directions: the platform connects servers as a source of tools for agents, and it can itself act as a server for external clients.
The organization's MCP server registry
Tool servers are registered within an organization. In "User settings", open the tool servers section and click "Add":
- Enter a unique name, the connection type (SSE or streamable HTTP; stdio is not supported), the full address and, if needed, an authorization token. The token is sent in a header, not in the address.
- Click "Test connection". The platform fetches the list of tools with their descriptions.
- Review the tools and turn off those that the system owner has not approved, first of all the ones that change data.
- Save. The tool list and the enabled flag are cached; after changes on the server, refresh the list from the server card.
You can import and export the set of servers and make a test call of a tool with arguments right from the interface. Creating and changing a server are recorded in the audit log.
Where tools are used
- Agent on the canvas. In the "Agent" component you select tools from the connected servers. Tool metadata is converted to the model's function-calling format; execution runs in a ReAct loop: analyze the request, call a tool, add the result to the context, continue. The tool name, arguments, result and execution time are written to the trace.
- Assistant in chat. Explicitly selected MCP tools extend the tool catalog of the new chat core. The server binds the organization, user, session and node, and the message text cannot override this binding. Each tool call is checked for availability every time it is made, so a disabled tool stops working immediately.
- Research mode. Research tasks read from the registry of read tools: 1C, Bitrix24 and external sources through gateway modules. Write tools are not issued to research tasks.
- Automations. A polling trigger calls a tool on a schedule, takes a fingerprint of the response and starts the scenario only when the response changes.
Writing to an external system always goes through confirmation: chat stops the turn before a call that changes data and shows a confirmation card, the canvas parks execution on an approval node, and Telegram receives the "Confirm" and "Reject" buttons.
The built-in gateway and external servers
Gleyk ships with its own tool gateway in which integrations are implemented as modules: 1C, Bitrix24, Jira and Confluence, Telegram, legislation databases, advertising accounts and others. Gateway modules have what an arbitrary external server does not:
| Property | Gateway module | External MCP server |
|---|---|---|
| Organization binding | The gateway itself inserts the organization ID from the headers | The server only has access to the headers and the token |
| Secrets | Encrypted and bound to the organization; an envelope from another organization cannot be opened | Stored on the server side |
| Audit | Every call is in the log, and the records are tagged separately | The call is recorded on the Gleyk side |
| Response size | Trimmed to fit the model's context window, with continuation by offset | As the server returned it |
| Write confirmation | By the tool's classification | By the tool's annotations |
An external server suits ready-made integrations that vendors already provide (Atlassian, GitHub, HubSpot, Salesforce and others) and quick prototypes. If an integration becomes permanent, move it into a gateway module to get audit and sealed secrets.
The platform's built-in MCP server
Gleyk can itself act as an MCP server and offer a knowledge base search tool to external clients (IDEs, agents, other platforms). The server runs as a separate process next to the backend.
From source:
uv run mcp/server/server.py --host=127.0.0.1 --port=9382 \
--base-url=http://127.0.0.1:9380 --api-key=<api-key>In Docker Compose it is enabled through the command of the server service: --enable-mcpserver, --mcp-host, --mcp-port, --mcp-base-url, --mcp-mode, --mcp-host-api-key. There are two modes:
self-host(default): the API key is set at startup, and the server sees the knowledge bases of one organization;host: each client passes its own API key in the headers (api_keyorAuthorization) and sees its own bases.
Transports: /sse (legacy SSE) and /mcp (streamable HTTP). The server publishes the ragflow_retrieval tool with the arguments question, dataset_ids and an optional document_ids; the descriptions of all available bases with their IDs are included in the tool description, so a client can pass all the bases if it does not know which one is relevant.
An example Python client in host mode:
from mcp.client.sse import sse_client
async with sse_client("http://localhost:9382/sse", headers={"api_key": "<api-key>"}) as streams:
...Warning
The server verifies identity by API key only. On a public network this is not enough protection: bind the server to 127.0.0.1 or an internal address, and put a reverse proxy with TLS and access restrictions in front of it.
How to add your own tool
The fastest path for a prototype is to bring up your own server on any MCP library (for example, FastMCP, including generation from OpenAPI), publish it over streamable HTTP, check it with the MCP inspector and register it in the organization's registry. After that the tools are available in the "Agent" component and to assistants. For production use, describe which tools read data and which change it: whether the platform requires confirmation depends on that.
Related articles: Agents on the canvas, API key and SDK, Connecting 1C via OData.
Ask Sema