Skip to main content

MCP servers

Out of the box, agents can search your knowledge, send emails, call webhooks, and generate documents. MCP servers extend that list. MCP (Model Context Protocol) is an open standard for giving AI systems tools, and there are servers for databases, payment platforms, file systems, and hundreds of other things. Register one in Docana and your agents can use its tools.

Looking for the other direction?

This page is about giving your Docana agents external tools. To use Docana itself as an MCP server from Claude Code, Cursor, and other AI tools, see Docana MCP.

Manage them at MCP Servers in the Developer section.

Everything on this page also works headless. The API registers and manages servers (POST /api/v1/mcp-servers/) and enables them per application, the CLI wraps it (docana mcp-servers create, docana app <id> mcp enable), and AI tools connected to Docana's MCP server get the same operations as tools.

Register a server​

Click Add MCP Server and fill in:

  • Name and Description: how it shows up in the list
  • Provider template: select a supported provider or choose Custom to enter the connection details.
  • URL: the remote server's address, such as https://mcp.stripe.com.
  • Transport: choose the HTTP transport supported by that server.
  • Authentication: choose the method required by the provider and fill in its credentials.
  • Enabled and Private: control whether the server is available and whether teammates can see it.

Use HTTP Headers for additional request headers, then click Save Changes. The form registers a remote server. It does not expose a local command or environment-variable editor.

Register a remote MCP server with its URL, transport, and authentication method. This is the Custom provider form.
Register a remote MCP server with its URL, transport, and authentication method. This is the Custom provider form.

Enable it for an application​

Registering a server doesn't change anything by itself. Open your application, go to its MCP Servers settings, and toggle on the servers this application should use. From then on, agents in that application can call the server's tools in their workflows.

That separation is deliberate. Your customer-facing support agent probably shouldn't have the same tools as your internal finance agent.

Where the tools show up​

Once enabled, the server's tools are available to agents like built-in tools: in instruction steps and tool-call actions in the Agent Builder. The agent decides when to use them, the same way it decides when to search your knowledge.

Best practices​

  1. Start with read-only servers: a tool that looks things up can't break anything. Add write access once you trust the workflow.
  2. Keep credentials out of agents: authentication lives on the server registration, not in prompts.
  3. Enable per application, narrowly: each application should see only the tools it needs.
  4. Test in the assistant first: ask the assistant to use the new tool and watch the result before wiring it into production workflows.

Next steps​