Connect Pylon to Claude: Manage Support Teams & User Workflows

A February 2026 Gartner survey revealed that 91% of customer service leaders are under intense executive pressure to implement AI. The business mandate is clear: automate support triage, reduce response times, and sync account intelligence across platforms. Pylon has rapidly become the default B2B support platform for companies relying on Slack Connect and Microsoft Teams. It centralizes omnichannel support, but if you want to build custom AI agents that interact with your Pylon data - or simply want to query Pylon users directly from Claude - you hit a wall.

There is no native Claude connector for Pylon. Connecting Anthropic's Large Language Model (LLM) to Pylon's REST API requires an integration layer. You either spend weeks building and hosting a custom Model Context Protocol (MCP) server, or you use a managed infrastructure layer that handles the boilerplate for you.

This guide breaks down exactly how to use Truto's SuperAI to generate a managed MCP server for Pylon, connect it natively to Claude Desktop (if you use OpenAI, see our guide for connecting Pylon to ChatGPT), and execute complex support workflows using natural language.

The Engineering Reality of Custom API Connectors

A custom MCP server is a self-hosted integration layer that translates an LLM's natural language tool calls into structured REST API requests.

Anthropic's rollout of Custom Connectors in Claude Desktop gave engineers a standardized way to connect models to external systems. The protocol itself is elegant. The reality of implementing it against vendor APIs is entirely different.

If you decide to build a custom MCP server for Pylon, you are responsible for the entire API lifecycle. You have to handle API token security. You have to write and maintain massive JSON schemas for every endpoint you want the LLM to access. When the LLM requests a list of users, you have to write the logic to handle pagination cursors - instructing the model to pass the exact next_cursor value back on subsequent calls.

Third-party APIs are notorious for undocumented edge cases, inconsistent error payloads, and strict rate limits. When you build a custom MCP server, you absorb all of that technical debt. Your AI agent is only as reliable as the integration layer beneath it. If your custom server crashes because an API returned a 502 Bad Gateway or an unexpected HTML error page instead of JSON, Claude will simply hallucinate a response or fail entirely.

The Pylon API Architecture: Why Consistency Matters for LLMs

Pylon recently launched their official API to unlock custom in-app frontends and backend event tracking. For developers building AI agents, Pylon's API architecture is notably well-suited for LLM consumption.

The API features nested objects in payloads, consistent payload shapes across endpoints, and request IDs for debugging. This consistency is critical. Large Language Models are pattern-matching engines. If an API returns a user's role as a string ("admin") on a list endpoint, but as a nested object ({"id": 1, "name": "admin"}) on a single-item endpoint, the LLM will struggle to write reliable extraction logic. Pylon's consistent schema means Claude can reliably predict the shape of the response, drastically reducing hallucination rates when formatting markdown tables or answering analytical questions.

Managed MCP: Dynamic Tool Generation

A managed MCP server is a hosted infrastructure layer that implements the Model Context Protocol, automatically handling token lifecycles, API rate limits, and dynamic tool generation to expose the full surface area of third-party SaaS APIs to AI models.

Truto's approach to MCP is dynamic and documentation-driven. Rather than hand-coding tool definitions for every integration, Truto derives them from two existing data sources: the integration's resource definitions (which define what API endpoints exist) and documentation records (which provide human-readable descriptions and JSON Schema definitions for each resource method).

A tool only appears in the MCP server if it has a corresponding documentation entry. This acts as a quality gate to ensure only well-documented endpoints are exposed to Claude.

sequenceDiagram
    participant C as Claude Desktop
    participant M as Truto MCP Router
    participant P as Proxy API Layer
    participant V as Pylon API

    C->>M: POST /mcp/:token (tools/call)
    M->>M: Validate token & load schemas
    M->>M: Split flat arguments into Query & Body
    M->>P: Execute Proxy API Request
    P->>V: Authenticated REST Call
    V-->>P: JSON Response
    P-->>M: Normalized API Result
    M-->>C: JSON-RPC 2.0 Response

When you connect a Pylon account to Truto, you can instantly generate a secure, self-contained MCP server URL. That URL contains a cryptographic token that encodes which account to use and what tools to expose. You paste that URL into Claude Desktop, and the model instantly understands how to interact with Pylon.

Step-by-Step: Connecting Pylon to Claude

Wiring up Pylon to Claude Desktop takes about three minutes. You do not need to write any local code or manage local environment variables.

1. Get Your Pylon API Token

Pylon authenticates API requests using standard API tokens.

1. Log in to your Pylon account as an Administrator.
2. Navigate to Settings > API Tokens.
3. Generate a new API token. Copy this token immediately - you will not be able to see it again.

2. Connect Pylon to Truto

Next, you need to store this credential securely in Truto to create an Integrated Account.

1. Log in to your Truto dashboard.
2. Click Connect Account and open the generated link.
3. Paste the API token you generated in the previous step.
4. Once connected, Truto will assign an integrated_account_id to this connection.

3. Generate the MCP Server URL

Now we generate the actual MCP server. You can do this via the Truto UI or via the API. Each MCP server is scoped to a single integrated account.

Via the Truto UI:

1. Navigate to the integrated account page for your Pylon connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (name, allowed methods, expiry, etc.).
5. Copy the generated MCP server URL.

Via the API:

curl -X POST https://api.truto.one/integrated-account/<integrated_account_id>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Pylon Support MCP",
    "config": {
      "methods": ["read", "write"]
    }
  }'

API Response:

{
  "id": "mcp_abc123",
  "name": "Pylon Support MCP",
  "config": {
    "methods":["read", "write"]
  },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890..."
}

Keep the url value handy. This URL alone is enough to authenticate and serve tools to Claude.

4. Configure Claude Desktop

Claude Desktop now supports Custom Connectors natively in the UI, replacing the old method of manually editing the claude_desktop_config.json file.

1. Open the Claude Desktop app.
2. Navigate to Settings > Connectors.
3. Scroll to the bottom and click Add custom connector.
4. Enter a name (e.g., "Pylon Support").
5. Paste the Truto MCP url into the URL field.
6. Click Add, then click Connect to initialize the server.

Claude will perform an MCP handshake, requesting the tools/list from Truto. Truto dynamically generates the tool schemas based on the Pylon integration and returns them to Claude.

The Pylon Tool Inventory

Once connected, Claude has access to the raw proxy APIs for Pylon. Truto automatically formats the tool names into descriptive snake_case strings. The full list of available tools and their descriptions is documented on the Pylon integration page. Here are the core tools available for managing Pylon users, along with how Claude uses them.

list_all_pylon_users

Description: List all users within the Pylon platform, returning a collection of user objects with IDs, names, and contact details.

This is a read-only list method. Truto automatically injects limit and next_cursor properties into the query schema. The description explicitly instructs Claude to pass cursor values back unchanged, abstracting the pagination logic away from the prompt.

{
  "name": "list_all_pylon_users",
  "description": "List all users within the Pylon platform, returning a collection of user objects with IDs, names, and contact details.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "limit": {
        "type": "string",
        "description": "The number of records to fetch"
      },
      "next_cursor": {
        "type": "string",
        "description": "The cursor to fetch the next set of records. Always send back exactly the cursor value you received (nextCursor) without decoding, modifying, or parsing it."
      }
    }
  }
}

Example Prompt:

"Pull a list of the first 50 users in our Pylon account and format their names and emails into a markdown table."

get_single_pylon_user_by_id

Description: Retrieve detailed information for a specific user in Pylon using their ID, including profile fields and status.

For individual get methods, Truto automatically injects an id property into the schema and marks it as required. This ensures Claude knows exactly which identifier to pass.

Example Prompt:

"Get the profile details for the Pylon user with ID usr_89234abc. Tell me what their current role and status is."

update_a_pylon_user_by_id

Description: Update a user in Pylon by providing their unique ID. Returns user details including avatar URL, email, name, role, and status.

This is a write method. When Claude calls this tool, it constructs a JSON payload matching the body schema defined in Truto's documentation records.

Example Prompt:

"Update the Pylon user usr_89234abc. Change their status to inactive and append ' - Offboarded' to their name."

list_all_pylon_me

Description: Retrieve the account details and profile information of the currently authenticated Pylon user.

This is highly useful for verifying the permissions and identity of the API token you used to connect the account, ensuring Claude is operating with the correct privilege level.

Example Prompt:

"Who am I authenticated as in Pylon? What is my role?"

Architectural Edge Cases to Watch Out For

Using LLMs to orchestrate API calls is powerful, but it introduces unique architectural constraints. We built Truto's MCP implementation to handle these edge cases, but you should understand them when designing your AI workflows.

1. The Flat Input Namespace Problem

When an MCP client (like Claude) calls a tool, all arguments arrive as a single flat JSON object. However, REST APIs strictly separate query parameters (e.g., ?status=active) from body parameters (e.g., {"name": "John"}).

Truto's MCP router solves this by splitting the flat argument object into query and body parameters using the property keys defined in the respective JSON schemas. If a query schema and a body schema both define a property with the exact same name, the query schema's copy wins. In practice, this rarely causes issues, but it is a quirk of translating LLM tool calls into REST semantics.

2. Method Filtering for Security

You do not always want Claude to have write access to your production support systems. By default, an MCP server exposes all documented endpoints.

When generating the MCP server URL in Truto, you can use the config.methods array to restrict access. Setting methods: ["read"] ensures that only get and list operations are exposed to the model. Attempting to call update_a_pylon_user_by_id will fail because the tool simply will not exist in the server's capabilities.

3. Server Expiration for Ephemeral Access

If you are building an automated workflow or giving a contractor temporary access to query Pylon data via Claude, you should not issue permanent credentials. Truto supports an expires_at field when creating an MCP server.

When the expiration time is reached, Truto automatically deletes the underlying token records from the database and edge KV storage. The MCP server URL immediately stops working, ensuring no stale access remains.

4. Advanced Security: Double Authentication

By default, an MCP server's token URL is the only authentication required. Anyone with the URL can connect Claude to it. For local development or isolated use cases, this is fine.

However, if you are deploying this MCP server in a shared environment where the URL might be logged or exposed, you need stricter controls. Truto supports a require_api_token_auth configuration flag.

When enabled, possession of the MCP URL alone is not sufficient. The MCP client must also provide a valid Truto API token as a Bearer token in the Authorization header. This adds a secondary authentication layer, ensuring that only authenticated team members or authorized services can execute tools against your Pylon account.

Wrapping Up

Native AI connectors are fundamentally limited by the product decisions of the AI vendor. They give you access to a curated fraction of an API. A managed MCP server inverts that model. By dynamically generating tools from integration schemas, you get 100% API coverage without writing a single line of integration code.

Connecting Pylon to Claude via Truto allows your support operations, IT admins, and success teams to query user data, update profiles, and audit accounts using natural language. You bypass the technical debt of maintaining custom JSON-RPC servers, handling pagination, and securing API tokens.