MCP

Agentic Suite works with the Model Context Protocol in both directions. You can expose your workflows to MCP clients, and you can give your agents tools that live on other MCP servers.

Agentic Suite as an MCP server

The built-in MCP server publishes every published flow in your organization as a callable tool. Any MCP client can then list those tools and run them. Each tool is named execute_flow_<flow_id> and takes the flow’s declared inputs.

Run it with one of two transports:

# stdio: for Claude Desktop and other local clients (local process only)
python mcp_main.py --transport stdio

# SSE over HTTP, with authentication required on every tool call
python mcp_main.py --transport sse --port 8003 --auth

Require auth for any networked MCP server

Use --auth whenever the server is reachable over the network. When --auth is on, clients authenticate with an Agentic Suite API key (see Authentication), and the key owner becomes the identity the flow runs as, so tenant boundaries are preserved.

Running SSE without --auth exposes flow execution to anyone who can reach the port, with no organization scoping. Only do that on a trusted, isolated local network, never on a public interface. The stdio transport is safe by default because it is a local process, not a network listener.

Connect Claude Desktop

Point Claude Desktop at the stdio server. In your Claude Desktop MCP config:

{
  "mcpServers": {
    "agentic-suite": {
      "command": "python",
      "args": ["mcp_main.py", "--transport", "stdio"]
    }
  }
}

Claude then sees your published flows as tools and can run them in a conversation.

External MCP servers as tools

The other direction: register an MCP server you run elsewhere, and its tools become available to your agents and flows. This lets an agent call, for example, a GitHub or database MCP server during a run.

Registering an MCP server is an admin action

For a stdio server, the command, args, and env you register are executed on the backend host to reach the tools. That is privileged, so the create, update, and delete endpoints require the integrations:manage backoffice permission, not an ordinary member token. Grant it only to trusted operators, prefer pinned absolute command paths, and keep secrets in env rather than inline in args.

Register a server:

POST /api/v1/integrations/mcps/
Authorization: Bearer <token>
Content-Type: application/json

{
  "name": "GitHub MCP",
  "server_name": "github_mcp",
  "connection_type": "stdio",
  "command": "/usr/local/bin/github-mcp-server",
  "args": ["--stdio"],
  "env": { "GITHUB_TOKEN": "…" },
  "active": true
}

Inspect the tools a registered server exposes:

GET /api/v1/integrations/mcps/{mcp_id}/tools
Authorization: Bearer <token>

Call a tool directly (useful for testing a connection):

POST /api/v1/integrations/mcps/{mcp_id}/tools/{tool_name}/call
Authorization: Bearer <token>
Content-Type: application/json

{ "arguments": { "owner": "torvalds", "repo": "linux" } }

Once a server is registered and active, its tools are loaded into agent runs automatically, so an agent can choose them the same way it uses any other tool.

Which direction do you need?

• Want an MCP client (like Claude) to run your workflows? Use Agentic Suite as an MCP server.
• Want your agents to use tools hosted somewhere else? Register those external MCP servers.

Both can be on at once: your flows are exposed as tools while your agents consume tools from other servers.

Back to Integrate overview.