Connect Alloy to Claude: Manage Onboarding Journeys & Compliance

If you need to connect Alloy to Claude to automate KYC decisions, identity verification, onboarding journeys, or fraud investigations, you need a Model Context Protocol (MCP) server. This infrastructure layer acts as the translation layer between Claude's natural language tool calls and Alloy's complex identity decisioning REST APIs. You can either spend weeks building, hosting, and securing this proxy layer yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL in seconds. If your team uses ChatGPT, check out our guide on connecting Alloy to ChatGPT or explore our broader architectural overview on connecting Alloy to AI Agents.

Giving a Large Language Model (LLM) read and write access to an enterprise decisioning engine like Alloy is an engineering challenge with severe consequences. You have to handle stringent OAuth token lifecycles, parse massive dynamic JSON schemas for journey applications, and securely manage PII data traversal. Every time Alloy updates an endpoint or modifies an evaluation payload requirement, you have to update your server code, redeploy, and test the integration. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Alloy, connect it natively to Claude, and execute complex compliance workflows using natural language.

The Engineering Reality of the Alloy API

A custom MCP server is a self-hosted integration layer that translates an LLM's JSON-RPC 2.0 tool calls into standard REST API requests. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against Alloy's heavily entity-centric API is painful.

If you decide to build a custom MCP server for Alloy, you own the entire API lifecycle. Here are the specific, unique challenges you will face:

Token-Based Identity Proliferation Alloy does not use a flat data model. Everything in the system revolves around unique, interdependent tokens. A single workflow might require an entity_token, a journey_token, a journey_application_token, and an evaluation_token. If you expose these endpoints raw to Claude, the model will frequently hallucinate token values or mix up an evaluation token with an entity token. Truto dynamically builds tool definitions from documentation, heavily enriching the JSON schemas with explicit descriptions that guide the LLM on exactly which token maps to which query parameter, preventing cascading execution failures.

Dynamic Journey Application Schemas When you submit an entity for onboarding via create_a_alloy_journey_application, the required payload is not static. It depends entirely on how the specific journey is configured within Alloy. If a journey requires a physical address and an SSN, passing only a name and email will fail. Writing a static OpenAPI spec for this is impossible. Truto handles this by passing raw schematics up to the MCP interface, allowing Claude to dynamically interpret the required fields based on the contextual error responses and schema descriptions.

Strict Rate Limiting and Backoff Rules Alloy enforces API limits that can quickly be exhausted by an overactive AI agent trying to paginate through thousands of historical fraud cases. It is critical to understand a specific architectural fact: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Alloy API returns an HTTP 429 (Too Many Requests), Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller - in this case, your agent framework or the Claude client - is strictly responsible for implementing retry and exponential backoff logic. Do not build an integration expecting the proxy layer to silently absorb rate limits.

How to Generate an Alloy MCP Server with Truto

Truto dynamic tool generation derives MCP tool definitions directly from the integration's documented resources. Tools are never cached or pre-built. They are instantiated dynamically based on the permissions and filters you configure.

You can generate an MCP server for Alloy using either the Truto UI or the API.

Method 1: Via the Truto UI

For teams who prefer visual configuration, the Truto dashboard provides a direct path to generating secure server URLs.

1. Navigate to the Integrated Accounts page for your active Alloy connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (name, allowed methods, specific tags, and an optional expiry datetime).
5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the API

For platform engineers building multi-tenant AI products, MCP servers can be provisioned programmatically. The API validates that the integration has tools available, generates a secure cryptographically hashed token, and returns a ready-to-use JSON-RPC endpoint.

Endpoint: POST /integrated-account/:id/mcp

// Example POST request to generate an Alloy MCP Server
{
  "name": "Alloy Compliance AI Agent",
  "config": {
    "methods": ["read", "write"], // Allow both querying and creating applications
    "require_api_token_auth": false
  },
  "expires_at": null
}

Response:

{
  "id": "mcp_8f7d9a1b",
  "name": "Alloy Compliance AI Agent",
  "config": {
    "methods": ["read", "write"]
  },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

This URL is fully self-contained. It encodes the targeted Alloy tenant and the required authentication to execute tools.

How to Connect the MCP Server to Claude

Once you have the Truto MCP server URL, you need to register it with Claude. This allows Claude's reasoning engine to request a list of available tools (tools/list) and invoke them (tools/call) during conversations.

Method A: Via the Claude UI

If you are using the Claude web interface or standard desktop client with custom connector support enabled:

1. In Claude, navigate to Settings -> Integrations (or Connectors).
2. Click Add MCP Server.
3. Paste the Truto MCP server URL generated in the previous step.
4. Click Add. Claude will immediately execute an initialization handshake and discover the available Alloy tools.

Method B: Via Manual Config File (Claude Desktop)

If you are developing locally with Claude Desktop, you must route the HTTP-based Truto MCP URL through a Server-Sent Events (SSE) transport adapter. Truto provides an open-source adapter specifically for this purpose.

Locate your Claude Desktop configuration file:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the following configuration, replacing the URL with your actual Truto URL:

{
  "mcpServers": {
    "alloy-compliance": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Restart Claude Desktop. The agent is now securely tethered to your Alloy tenant.

Hero Tools for Onboarding and Compliance

When Claude connects to the Alloy MCP server, it gains access to the standardized API surface. Here are the highest-leverage tools your agent can now call to automate compliance workloads.

create_a_alloy_journey_application

This is the core tool for initiating a new onboarding flow. It creates a new Journey Application in Alloy by submitting entity data against a predefined journey schema.

Contextual Usage: Claude uses this tool when a user instructs it to run a KYC or KYB check on a new applicant. The model will structure the required entity data (name, address, SSN, EIN) and submit it for automated decisioning.

"We have a new corporate client onboarding today. Their name is Acme Corp and the EIN is 12-3456789. Can you create a new journey application in Alloy using the 'Standard KYB Journey' token to run their initial checks?"

get_single_alloy_person_entity_by_id

Retrieves the complete profile of a person entity by its unique entity_token, including their verification status, addresses, and PII status.

Contextual Usage: Useful for auditing or investigating specific individuals whose onboarding applications were flagged for manual review.

"I need to review the profile for the person with entity token 'ent_abc123'. Can you pull their full record and tell me if their PII status indicates a mismatch on their date of birth?"

list_all_alloy_investigations

Fetches a list of active investigations in Alloy, supporting filters for state, type, and risk score.

Contextual Usage: Ideal for compliance triage. Claude can retrieve a queue of pending fraud investigations, summarize the risk scores, and present a prioritized list to human analysts.

"Pull the top 10 most recent fraud investigations that are currently in a 'pending' state. Sort them by risk score, highest to lowest, and give me a summary of the tags attached to the top three cases."

update_a_alloy_investigation_review_by_id

Allows the agent to submit a review decision for a specific investigation, appending notes and updating the entity state based on external context.

Contextual Usage: When a human operator approves an action via chat, Claude can formally log the review and close the investigation inside Alloy.

"I have reviewed the attached documentation for investigation token 'inv_xyz987'. It looks legitimate. Please update the investigation review to approve the case and add a note saying 'Address verified via manual utility bill review.'"

create_a_alloy_document

Uploads and attaches a new document (like a driver's license, passport, or utility bill) to a specific entity.

Contextual Usage: When a user uploads a document into the Claude chat interface, the agent can parse it, extract the necessary metadata, and push the file directly into the entity's Alloy profile for evidence retention.

"I just received this PDF of a utility bill from the customer we are reviewing. Can you upload it as a new document to entity token 'ent_abc123' and mark the document type as 'proof_of_address'?"

create_a_alloy_evaluation

Runs a standalone evaluation against a configured workflow without necessarily tying it to a long-running journey application.

Contextual Usage: Used for point-in-time checks, such as running a transaction monitoring rule or a one-off sanctions screen on an existing customer profile.

"Run a new evaluation against the 'Sanctions Screen Workflow' for the entity token 'ent_abc123'. Let me know if the evaluation returns an automatic approval or if it gets flagged for manual review."

To view the complete inventory of available operations and detailed JSON schemas, visit the Alloy integration page.

Workflows in Action

To understand the practical power of connecting Claude to Alloy, let us look at two real-world operational workflows.

Workflow 1: Automated KYC Onboarding and Triage

When compliance analysts review incoming applications, they often switch between email, CRMs, and Alloy. With an MCP server, they can drive the entire process from a single chat window.

"Start a KYC onboarding process for Jane Smith (DOB: 01/15/1985). Once the journey application is submitted, tell me if it was auto-approved. If it requires manual review, tell me which specific checks failed."

Execution Steps:

1. Claude calls create_a_alloy_person_entity to register Jane Smith in the system, returning a new entity_token.
2. Claude takes the generated entity_token and calls create_a_alloy_journey_application, submitting it against the specified KYC journey.
3. The tool returns the journey response. Claude parses the output. If the state is approved, it informs the user. If the state is manual_review, Claude reads the data array to extract the exact failure reasons (e.g., "Address mismatch") and reports them to the analyst.

sequenceDiagram
    participant Analyst as Compliance Analyst
    participant Claude as Claude Desktop
    participant MCP as Truto MCP Server
    participant Alloy as Alloy API

    Analyst->>Claude: Start KYC for Jane Smith
    Claude->>MCP: Call create_a_alloy_person_entity<br>(Name, DOB)
    MCP->>Alloy: POST /v1/entities/person
    Alloy-->>MCP: Returns entity_token
    MCP-->>Claude: Tool result (entity_token: ent_892x)
    Claude->>MCP: Call create_a_alloy_journey_application<br>(journey_token, ent_892x)
    MCP->>Alloy: POST /v1/journeys/{token}/applications
    Alloy-->>MCP: Returns journey state & rules
    MCP-->>Claude: Tool result (status: manual_review)
    Claude-->>Analyst: "Requires review due to Address Mismatch."

Workflow 2: Fraud Case Investigation and Review

Managing investigation queues manually is slow and error-prone. AI agents can aggregate risk intelligence dynamically.

"Pull up the latest 5 open fraud investigations. For the highest risk one, retrieve the primary person's entity details and summarize why they were flagged. Then, clear the case by logging a review note: 'Reviewed by AI agent - false positive on velocity check'."

Execution Steps:

1. Claude calls list_all_alloy_investigations with a limit parameter to fetch the top 5 open investigations, sorting by risk_score.
2. Claude extracts the entity_tokens attached to the investigation with the highest score.
3. Claude calls get_single_alloy_person_entity_by_id to retrieve the subject's details and recent journey alerts.
4. Claude synthesizes the context and calls update_a_alloy_investigation_review_by_id, passing the required investigation_token and the analyst's approval note to close the case.

Security and Access Control

Exposing a compliance engine to an LLM introduces operational risk. Truto's MCP servers are designed with strict boundary controls to prevent unauthorized access and hallucinated writes.

• Method Filtering: You can configure the MCP token to strictly allow specific HTTP methods. Passing methods: ["read"] ensures the agent can query cases and entities, but physically cannot call create or update endpoints, making the integration strictly read-only.
• Tag Filtering: Limit the surface area of the LLM by tagging resources. You can configure the server to only expose tools tagged as ["investigations"] while blocking access to core configuration endpoints.
• API Token Authentication: For internal enterprise deployments, setting require_api_token_auth: true means possession of the URL is not enough. The MCP client must also pass a valid Truto API session token, ensuring only authenticated team members can invoke the tools.
• Ephemeral Servers: Using the expires_at parameter, you can generate temporary MCP servers for contractors, automated nightly batch jobs, or specific triage tasks. Once the timestamp passes, Truto automatically terminates the token and destroys the database record.

Empowering Compliance Engineering

Building a custom integration layer for Alloy requires a deep understanding of token orchestration, dynamic schematics, and strict rate limiting architectures. By using Truto to generate a managed MCP server, you offload the entire lifecycle of authentication, pagination mapping, and schema generation. Your engineering team can focus on designing robust compliance workflows and tuning agent prompts, rather than writing boilerplate JSON-RPC handlers and maintaining OAuth flows.