MCP server

Model Context Protocol (MCP) is a new standard protocol for LLMs to connect to external services and interact with them. You can build custom remote MCP servers directly from the Tines storyboard.

To get started, search for "MCP" in the Templates section on the left panel, and drag your first MCP server to the storyboard. After configuring it with some tools, you can reference the server URL and authentication parameters from your MCP client to try it out.

Adding tools 

MCP servers support template, send-to-story and custom tools. They can can be configured in the same way as the AI Agent action. They will be exposed directly via the server and available for invocation from your client. Tool names, descriptions and arguments are automatically available on your MCP client after successful connection.

Access control 

There are four access control modes for MCP servers:

  • Anyone with the path (public)

  • Anyone with the secret (passed in via the URL or HTTP Authorization)

  • Only team members (requires a Tines API key)

  • Members of this Tines tenant (requires a Tines API key)

You can read more about these here.

Configuring your MCP client 

An MCP server created in Tines can be used directly by any client that supports the Streamable HTTP protocol for remote MCP servers. Typically, you can use an MCP setting like this on a client that supports this syntax.

{
  "mcpServers": {
    "tines": {
      "url": "https://<tenant>.tines.com/mcp/<mcp-path>",
      "headers": {
        "Authorization": "Bearer <webhook-secret or api-key>"
      }
    }
  }
}

Additionally, if you are using a client that only support local servers (stdio), you can use mcp-remote to act as a local proxy. To do this, you need Node.js installed locally and the following MCP settings:

{
  "mcpServers": {
    "tines": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://<tenant>.tines.com/mcp/<mcp-path>",
        "--header",
        "Authorization:${AUTH_HEADER}",
        "--transport",
        "http-only"
      ],
      "env": {
        "AUTH_HEADER": "Basic <webhook-secret or api-key>"
      }
    }
  }
}

🪄Tip

Protocol details 

  • Only Streamable HTTP is supported (no SSE or stdio). See above for information about using a mcp-remote as an adaptor

  • Authentication can be done via the HTTP Authorization header or via the URL (when using secrets)

  • The supported MCP protocol version is2025-06-18

    • Version 2025-03-26 has partial support, and should work on the majority of clients that support it.

    • Version 2024-11-05 is not supported

  • Only tools are supported. Tool responses are always text.

Unsupported features 
  • Prompts

  • Resources

  • OAuth

  • Notifications

  • Sessions

  • Pagination

  • JSON-RPC Batching (only relevant for spec 2025-03-26)

Limits 

The MCP server implementation is subject to the same limits that apply to response-enabled webhooks. That is:

  • Tool response time cannot exceed 30 seconds.

    • After this time your client will receive a timeout error.

    • When this happens, the tool can continue to run in the background, but the result does not reach the client.

  • You cannot have more than 100 (1000 in dedicated tenants) concurrent tool/call requests.

    • These are counted globally across all MCP servers and response-enabled webhooks in your tenant.

  • Tool execution happens asynchronously and is subject to the same fair orchestration system that applies to all stories.

  • You can link up to 25 tools to one MCP server.

Emitted events 

The MCP server will emit events for the requests it gets. These are:

  • initialize

  • tools/list

  • tools/call

In the case of the tools/call emitted event, the tool result is not included in the event. However, each tool call will be available on the tool itself, which emits an event upon completion.

To avoid unnecessary noise, methods that do not provide meaningful information (such as notifications or ping) will not result in downstream events.

When an API key is used to authenticate, the email of the API key's owner will be available in the downstream event, at <<headers.email>>.

Other configuration options 

The description of the MCP server action will be exposed directly to clients as instructions, in case you wish to share general context about the MCP server with the LLM using it.

MCP servers share many of the configuration options that webhooks offer. For example, you can set these like you would on a normal webhook:

  • Enable CORS

  • Match rules

  • Rate limiting

Was this helpful?