Connect DingConnect to Claude: Manage Mobile Transfers & Pricing

If your team needs to connect DingConnect to Claude to automate global mobile top-ups, manage agent balances, or orchestrate complex digital product sales, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and DingConnect's transaction-heavy REST API. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses ChatGPT, check out our guide on connecting DingConnect to ChatGPT or explore our broader architectural overview on connecting DingConnect to AI Agents.

Giving a Large Language Model (LLM) read and write access to a high-volume telecom and payments API like DingConnect is a serious engineering challenge. You have to handle complex multi-step discovery chains (locating carriers by phone number before quoting prices), map massive nested JSON schemas to MCP tool definitions, and deal with DingConnect's specific timeout constraints and error codes. Every time DingConnect updates an endpoint or adds a new product SKU, 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 DingConnect, connect it natively to Claude, and execute complex top-up and pricing workflows using natural language.

The Engineering Reality of the DingConnect API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against specialized transactional APIs is painful. DingConnect is built to process global telecom airtime, gift cards, and bill payments across hundreds of distinct carriers. Its API reflects that complexity.

If you decide to build a custom DingConnect MCP server, here are the specific integration challenges you will face:

The Multi-Step Product Discovery Chain

You cannot simply instruct an LLM to "send a $10 top-up to +15551234567". DingConnect requires a strict, multi-step orchestration process to execute a transaction. First, you must pass the phone number to an account lookup endpoint to determine the carrier and region. Second, you must query available products for that specific carrier to find valid SKU codes. Third, you must request a price estimate to calculate exact exchange rates, distributor fees, and taxes. Finally, you execute the transfer. An LLM has no context for this sequence. Your MCP server must expose strictly defined tools that guide the model through this exact chronological chain.

Synchronous Timeouts and Ephemeral Transaction States

DingConnect handles transfers synchronously, but interacting with downstream global telecom providers introduces latency. The DingConnect API enforces a strict 90-second timeout on transfers. If a transfer exceeds this, the API returns a ProviderTimedOut error code, and the agent is not charged. However, this means your MCP server must handle long-running HTTP connections without dropping the JSON-RPC request back to the LLM. Furthermore, confirming a transfer's final success requires polling transfer records to check the ProcessingState, as a "successful" API call only means the transfer was accepted for processing, not that the end-user received the airtime.

Opaque Error Codes and Commission Math

When a DingConnect transaction fails, the API does not always return a user-friendly string. It returns arrays of integer ErrorCodes. To explain what went wrong to an end-user, your system must map these codes against the dedicated error code descriptions endpoint. Additionally, agent balances (GetBalances) report raw funds plus commission-on-sale increments, but exclude processing transfers. Exposing this directly to an LLM without clear schema descriptions often results in hallucinations regarding how much "spend" the agent actually has available.

Factual Note on Rate Limits and API Resiliency

When exposing DingConnect to Claude, rate limiting is a critical architectural consideration. Truto does not retry, throttle, or apply backoff on rate limit errors.

When the upstream DingConnect API returns an HTTP 429 (Too Many Requests), Truto passes that error directly back to the caller (your MCP client or Claude). Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec.

It is entirely the caller's responsibility to implement retry logic and exponential backoff. Do not design your AI workflows assuming the MCP server will absorb rate limit errors. You must instruct your agent to respect the normalized headers and pause execution when limits are reached.

How to Create a DingConnect MCP Server

Truto dynamically generates MCP tools based on the underlying integration's documented resources and endpoints. Tools are served over a JSON-RPC 2.0 endpoint (/mcp/:token). You can generate this endpoint securely using either the Truto UI or the REST API.

Method 1: Via the Truto UI

This is the fastest path for developers building internal AI workflows or testing prompts in Claude Desktop.

1. Log into your Truto dashboard and navigate to the Integrated Accounts section.
2. Select your connected DingConnect account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Configure the server (e.g., name it "DingConnect Production", filter for specific tags, or set an expiration date).
6. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/abc123def456...).

Method 2: Via the Truto API

For B2B SaaS platforms provisioning AI agents for multiple tenants, you should generate MCP servers programmatically. Each server is scoped to a single integrated DingConnect account.

Make an authenticated POST request to the Truto 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": "DingConnect Automation Agent",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The Truto API verifies that the integration has available tools, generates a secure cryptographic token, stores it in distributed KV storage, and returns a ready-to-use URL:

{
  "id": "mcp_abc123",
  "name": "DingConnect Automation Agent",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

How to Connect the MCP Server to Claude

Once you have your Truto MCP URL, you need to connect it to Claude. The process differs depending on whether you are using the consumer UI or a local developer environment.

Method A: Via the Claude UI

If you are using Claude's web interface or team workspaces (features and UI placement depend on your Anthropic plan):

1. In Claude, navigate to Settings -> Integrations (or Connectors).
2. Click Add MCP Server or Add custom connector.
3. Paste the Truto MCP URL you generated above.
4. Click Add or Save.

Claude will immediately perform a JSON-RPC handshake (initialize) with Truto, discover the DingConnect tools, and make them available in your chat context.

Method B: Via Manual Config File (Claude Desktop)

If you are developing locally with Claude Desktop, you must configure the server using your claude_desktop_config.json file. Truto provides MCP endpoints over Server-Sent Events (SSE), so you will use the official @modelcontextprotocol/server-sse proxy to connect.

Locate your config file:

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

Add the DingConnect server block:

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

Restart Claude Desktop. The app will spawn the SSE transport, connect to Truto, and pull down the DingConnect integration schema.

DingConnect MCP Tools for Claude

Truto translates DingConnect's REST resources into discrete, description-rich tools. When Claude calls tools/list, it receives a payload containing the tool name, description, and JSON schema requirements.

Here are the most critical hero tools for automating DingConnect workflows.

1. list_all_ding_connect_get_account_lookups

This tool allows the LLM to inspect a phone number (in international format) and return the associated telecom provider, country, and region code. This is the mandatory first step before finding top-up products.

"Look up the telecom provider and region details for the phone number +525512345678."

2. list_all_ding_connect_get_products

Once the LLM knows the provider code and region, it uses this tool to list the available digital products (SKUs) that can be sent to that account. It returns pricing limits, benefits, and the specific SkuCode needed to execute a transfer.

"Get the available top-up products and SKU codes for the provider code 'Telcel_MX'."

3. create_a_ding_connect_estimate_price

Before executing a transfer, this tool calculates the exact exchange rates, distributor fees, and tax rates. The LLM must pass the chosen SkuCode and the desired SendValue.

"Estimate the price and taxes for sending $10 using SKU code 'MX_TELCEL_10' to +525512345678."

4. list_all_ding_connect_get_balances

Executing top-ups consumes agent funds. This tool checks the current DingConnect agent balance, returning the available currency and amount (excluding processing transfers but including commissions).

"Check our current agent balance to ensure we have at least $50 available for top-ups."

5. create_a_ding_connect_send_transfer

This tool executes the actual mobile top-up. The LLM must supply the SkuCode, SendValue, and AccountNumber. It returns the TransferId, ProcessingState, and digital receipt details.

"Send a transfer of $10 to +525512345678 using SKU 'MX_TELCEL_10'. Return the transfer ID and processing state."

6. list_all_ding_connect_list_transfer_records

Because transfers can take up to 90 seconds or enter transient states, this tool queries the historical record of transfers. The LLM uses this to check if a previously submitted transfer was successful or failed.

"Check the status of the last 5 transfers submitted today to confirm if any are stuck in a processing state."

(To view the complete schema details, query parameters, and full inventory of available tools, visit the DingConnect integration page.)

Workflows in Action

When you give Claude access to the DingConnect MCP server, it can autonomously chain these tools together to execute complex telecom workflows without requiring you to write custom orchestration logic.

Workflow 1: Quoting and Executing a Global Top-Up

A customer service agent requests Claude to process a mobile recharge for a user in another country.

"Can you look up the carrier for +639171234567, find a $5 data plan, give me a price estimate including fees, and if our agent balance is sufficient, process the top-up?"

How Claude executes this:

1. Calls list_all_ding_connect_get_account_lookups with the phone number to identify the provider (e.g., Globe Telecom Philippines).
2. Calls list_all_ding_connect_get_products filtered by the provider code to find the correct data plan SkuCode.
3. Calls create_a_ding_connect_estimate_price to calculate the final USD cost, accounting for FX rates and DingConnect fees.
4. Calls list_all_ding_connect_get_balances to verify the agent account has enough funds.
5. Calls create_a_ding_connect_send_transfer to push the transaction through.

Outcome: Claude replies with a summary of the carrier, the exact cost breakdown, and the final Transfer ID confirming the top-up was successful.

sequenceDiagram
  participant Claude as Claude Desktop
  participant MCP as Truto MCP Server
  participant Upstream as DingConnect API

  Claude->>MCP: tools/call (get_account_lookups)
  MCP->>Upstream: GET /api/V1/AccountLookup
  Upstream-->>MCP: ProviderCode: Globe_PH
  MCP-->>Claude: JSON-RPC Response

  Claude->>MCP: tools/call (get_products)
  MCP->>Upstream: GET /api/V1/GetProducts
  Upstream-->>MCP: SkuCode array
  MCP-->>Claude: JSON-RPC Response

  Claude->>MCP: tools/call (estimate_price)
  MCP->>Upstream: POST /api/V1/Estimate
  Upstream-->>MCP: Fee and Tax Data
  MCP-->>Claude: JSON-RPC Response

  Claude->>MCP: tools/call (send_transfer)
  MCP->>Upstream: POST /api/V1/SendTransfer
  Upstream-->>MCP: TransferId & Receipt
  MCP-->>Claude: JSON-RPC Response

Workflow 2: Auditing Failed Transactions and Error Codes

An operations manager needs to figure out why recent transactions to a specific region are failing.

"Pull the transfer records for today. Find any that failed, identify their error codes, and look up the human-readable description for those codes."

How Claude executes this:

1. Calls list_all_ding_connect_list_transfer_records using pagination to pull the latest transfers.
2. Filters the JSON response in its context window for records where ProcessingState is not 'Complete'.
3. Extracts the raw integer arrays from the ErrorCodes field on the failed records.
4. Calls list_all_ding_connect_get_error_code_descriptions to fetch the dictionary of error strings.
5. Matches the integers to the strings to understand the failure root cause.

Outcome: Claude provides a clear report: "3 transfers failed today. Two failed due to Error 14 ('Insufficient Agent Balance') and one failed due to Error 201 ('Product temporarily unavailable at operator')."

Security and Access Control

Exposing real-world financial transaction capabilities to an LLM requires strict governance. Truto provides several mechanisms to lock down your DingConnect MCP servers:

• Method Filtering (config.methods): You can restrict a server to read-only operations (e.g., methods: ["read"]). This allows Claude to look up accounts and check balances but prevents it from executing a create_a_ding_connect_send_transfer command.
• Tag Filtering (config.tags): Group tools by functional area. You can expose only reporting tools to a financial analyst agent, while giving a customer support agent access to top-up tools.
• Secondary Authentication (require_api_token_auth): By default, possessing the MCP URL grants access. By enabling this flag, clients must also pass a valid Truto API token in the headers, ensuring that even if an MCP URL is leaked in logs, it cannot be abused without valid user credentials.
• Ephemeral Servers (expires_at): You can generate an MCP URL that self-destructs at a specific ISO datetime. Truto's durable alarms will automatically wipe the server and its KV records when the time expires, which is perfect for temporary debugging sessions.

Moving from Brittle Code to Autonomous Connectivity

Building a custom integration layer for DingConnect involves deep architectural overhead: handling polling, managing opaque error schemas, securely storing credentials, and standardizing pagination. By using a managed MCP server, you offload the entire infrastructure layer. Truto handles the translation between JSON-RPC 2.0 and REST, meaning you can focus entirely on designing the AI prompts and workflows that drive your business.