Connect Dixa to Claude: Audit and Retrieve Custom Data Definitions

If your team uses ChatGPT, check out our guide on connecting Dixa to ChatGPT or read our broader overview on connecting Dixa to AI Agents. For teams heavily invested in Anthropic's ecosystem, connecting Dixa to Claude unlocks significant operational value.

Helpdesks run on data, and in platforms like Dixa, custom attributes dictate how customer and conversation data is stored. Auditing these custom data definitions manually is tedious. By exposing Dixa's custom attribute API to Claude via Truto's MCP (Model Context Protocol) server feature, you can give LLMs direct visibility into your helpdesk schema.

This guide covers exactly how to deploy a Truto MCP server for Dixa, connect it to Claude, and execute real-world workflows.

Engineering Reality: Dixa API Quirks and Rate Limits

Before connecting an LLM directly to a SaaS API, it helps to understand the underlying mechanics of that API. Dixa's architecture presents a few specific quirks when querying custom attributes.

First, Dixa relies heavily on the entityType field. Custom attributes aren't globally flat; they belong to specific entities (like users or conversations). When building tools around this, the AI agent needs to parse the inputDefinition object to understand what data format an attribute expects (e.g., text, dropdown, integer) before it attempts to suggest integrations or mapping logic.

Second, understand how rate limits are handled. Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Dixa API returns an HTTP 429, Truto passes that error directly to the caller. What Truto does do is normalize the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller - in this case, the script orchestrating Claude or the developer - is entirely responsible for observing these headers and handling backoff logic.

Step 1: Create the Truto MCP Server

Truto automatically generates MCP tools dynamically from the integration's underlying documentation and schema definitions. Each server is scoped to a single integrated account. You can create this server in two ways.

Approach A: Via the Truto UI

1. Navigate to the integrated account page for your specific Dixa connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Define your configuration (e.g., name the server "Dixa Schema Auditor", select read-only methods).
5. Copy the generated MCP server URL (it will look like https://api.truto.one/mcp/<token>).

Approach B: Via the API

For teams managing infrastructure as code or provisioning environments programmatically, you can create the MCP server directly via a REST call to Truto.

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

{
  "name": "Dixa Claude MCP",
  "config": {
    "methods": ["read"]
  }
}

The API securely provisions the access mechanism and returns a ready-to-use URL:

{
  "id": "dixa-mcp-8812",
  "name": "Dixa Claude MCP",
  "config": { "methods": ["read"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Step 2: Connect the MCP Server to Claude

Once you have the url, connecting Claude is straightforward.

Via Claude Desktop/Web UI

1. Copy your MCP server URL from Truto.
2. In Claude, navigate to Settings -> Connectors -> Add custom connector.
3. Paste the Truto MCP URL and click Add.

Claude will immediately call the /initialize and tools/list JSON-RPC endpoints to discover what tools are available.

Via Configuration File

If you prefer manual configuration, you can update your claude_desktop_config.json file directly to include the Truto MCP server as an SSE (Server-Sent Events) or HTTP connector (depending on your local proxy setup, though Truto natively supports direct HTTP POST JSON-RPC communication for MCP).

{
  "mcpServers": {
    "dixa_truto": {
      "command": "curl",
      "args": [
        "-X", "POST",
        "https://api.truto.one/mcp/a1b2c3d4e5f6...",
        "-H", "Content-Type: application/json"
      ]
    }
  }
}

(Note: For browser-based AI tooling, Truto fully supports CORS on the /mcp path).

Tool Inventory: Dixa Custom Attributes

Truto dynamically parses the Dixa integration to build these tools. Below are the primary tools available for this integration. You can find full schema details on the Dixa integration page.

list_all_dixa_custom_attributes

Fetches a complete list of all custom attributes configured within your Dixa environment. This is critical for auditing what fields exist, what entity they belong to, and whether they are required or deactivated.

• Contextual usage: Use this when you need a top-down view of the data model. Pay special attention to the inputDefinition property to understand the underlying data type.
• Example prompt: "Claude, list all custom attributes in Dixa and group them by entityType. Highlight any that are marked as required but are currently deactivated."

get_single_dixa_custom_attribute_by_id

Retrieves the exact schema and metadata for a specific custom attribute based on its unique identifier.

• Contextual usage: Use this for deep-dive investigations into a specific field that might be causing synchronization errors in your ETL pipeline.
• Example prompt: "Claude, get the details for the Dixa custom attribute with ID 'attr_9823'. Tell me what its inputDefinition is and when it was last updated."

Full Inventory List

Here is the complete inventory of additional Dixa tools available. For full schema details, visit the Dixa integration page.

• list_all_dixa_custom_attributes - List all custom attributes in Dixa (returns metadata including id, entityType, identifier, label, and inputDefinition).
• get_single_dixa_custom_attribute_by_id - Get custom attribute by id in Dixa (returns isolated metadata for debugging).

Workflows in Action

By giving Claude access to these definitions, teams can automate complex auditing and documentation tasks.

Workflow 1: The IT Schema Audit

An IT admin is preparing for a data migration and needs to understand what legacy fields exist in the helpdesk that are no longer active but still cluttering the UI.

"Claude, please fetch all Dixa custom attributes. Filter the list to only show attributes where isDeactivated is true or isArchived is true. Provide this as a markdown table showing the ID, Label, EntityType, and InputDefinition."

Step-by-step execution:

1. Claude calls list_all_dixa_custom_attributes with no filters to return the full payload.
2. Claude parses the resulting JSON array.
3. Claude filters the array in-memory for isDeactivated == true or isArchived == true.
4. Claude formats the specific keys into a markdown table.

Result: The admin gets an immediate, clean view of technical debt in the data schema without manually clicking through Dixa's settings panels.

Workflow 2: Integration Engineer Verifying Payload Types

A DevOps engineer is writing a script to sync user data from an internal database to Dixa but keeps encountering payload validation errors on a specific field.

"Claude, check the custom attribute with ID 'usr_vip_status'. I need to know exactly what input definition it expects so I can format my POST request correctly. Is it a boolean or a dropdown string?"

Step-by-step execution:

1. Claude calls get_single_dixa_custom_attribute_by_id passing 'usr_vip_status' as the id argument.
2. Claude analyzes the inputDefinition object returned in the payload.
3. Claude explains to the engineer that the field is actually a dropdown and provides the valid enumerated string values it accepts.

Result: The engineer stops guessing the payload structure and immediately fixes their sync script.

Security and Access Control

Exposing an API directly to an LLM requires strict governance. Truto's MCP architecture provides native primitives to lock down exactly what Claude can do.

• Method Filtering: By defining methods: ["read"] during server creation, you completely strip create, update, and delete tools from the MCP server. Claude physically cannot write data back to Dixa.
• Tag Filtering: If Dixa had hundreds of resources, you could pass tags: ["schema_definitions"] to only expose tools relevant to that functional area, keeping the LLM focused and reducing context bloat.
• Extra Authentication (require_api_token_auth): If you enable this flag, possession of the MCP URL isn't enough. The client must also pass a valid Truto API token in the Authorization header. This secures servers where the URL might be exposed in configuration files.
• Ephemeral Servers (expires_at): You can pass a strict ISO datetime when creating the MCP server. Truto's background systems will automatically destroy the token and connections at that exact moment. This is perfect for giving contractors temporary auditing access.