Connect Cledara to Claude: View SaaS Apps and Transaction History

If your IT or finance team needs to connect Cledara to Claude to view SaaS applications, audit transaction history, or download billing invoices, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's JSON-RPC tool calls and Cledara's REST APIs. 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 sibling guide on /connect-cledara-to-chatgpt-audit-spend-and-manage-saas-invoices/ or explore our broader architectural overview on /connect-cledara-to-ai-agents-automate-saas-audits-and-expenses/.

Giving a Large Language Model (LLM) read and write access to a SaaS management and virtual card platform like Cledara is a serious engineering challenge. You have to handle strict API token lifecycles, map massive nested JSON schemas to MCP tool definitions, and deal with Cledara's domain-specific data constraints. Every time Cledara updates an endpoint or deprecates a resource, 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 Cledara, connect it natively to Claude Desktop, and execute complex SaaS auditing workflows using natural language.

The Engineering Reality of the Cledara 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 B2B APIs is painful. Cledara is built to manage company-wide software subscriptions, virtual credit cards, and accounting integrations. Its API reflects that financial and operational complexity.

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

Nested Application and Transaction Models Cledara's data model is deeply relational. A transaction record does not exist in a vacuum - it is tied to a specific application, a specific workspace, a virtual card, and associated accounting categorizations. When you fetch transactions, the payload includes nested objects for currency types, authorization timestamps (authorizedAt), and boolean flags like hasInvoice. If you pass raw, unfiltered Cledara API responses directly to Claude, you will quickly overwhelm the model's context window with deeply nested metadata. Truto's dynamic tool generation extracts just the query and body schemas from the documentation, forcing the LLM to adhere to a clean, flat input namespace.

Invoice URL Generation Lifecycle In Cledara, you cannot simply download an invoice by hitting a static GET endpoint with a file extension. Because invoices contain sensitive financial data, the API requires a specific procedure: you must query the transaction, confirm hasInvoice is true, and then request a short-lived, pre-signed download URL via a dedicated endpoint. An LLM needs explicit instructions to navigate this two-step lifecycle. Building this logic into a custom MCP server requires manual orchestration. Truto handles this by generating tools with explicit descriptions derived directly from the API documentation, guiding the LLM on exactly how to chain these calls together.

Strict Rate Limits and Header Normalization Cledara enforces strict rate limits on its API to prevent abuse, particularly on high-volume endpoints like transaction listing. It is crucial to understand that Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Cledara API returns an HTTP 429 Too Many Requests error, Truto passes that error directly back to the caller.

However, Truto does normalize the upstream rate limit information into standardized HTTP headers per the IETF specification (ratelimit-limit, ratelimit-remaining, ratelimit-reset). This means the MCP client or the LLM orchestration framework reading the JSON-RPC response must inspect these standardized headers and implement its own retry and backoff logic. Building a custom MCP server means you have to parse vendor-specific rate limit headers manually - Truto standardizes the observability, but leaves the execution control to your agent.

Generating the Cledara MCP Server

Truto's MCP servers are derived dynamically from your connected integration's underlying resources. When you connect a Cledara workspace, Truto evaluates the available API endpoints and documentation records to generate a list of AI-ready tools.

You can create this server through the Truto dashboard or programmatically via the API.

Method 1: Via the Truto UI

For teams who prefer visual configuration, you can generate an MCP server directly from the integrated account dashboard.

1. Log into your Truto environment and navigate to the Integrated Accounts page.
2. Select your connected Cledara account.
3. Click on the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration. For example, you can name it "Cledara Finance Audit", set allowed methods to "read" (to prevent accidental writes), and optionally set an expiration date.
6. Click Save and copy the generated MCP server URL. It will look something like https://api.truto.one/mcp/a1b2c3d4....

Method 2: Via the Truto API

For platform engineers building multi-tenant AI products, you can dynamically provision MCP servers for your users via the Truto API. This validates that the integration has tools available, generates a secure hashed token stored in edge infrastructure, and returns a ready-to-use URL.

Execute a POST request to /integrated-account/:id/mcp with your desired configuration:

curl -X POST https://api.truto.one/integrated-account/<CLEDARA_ACCOUNT_ID>/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Cledara AI Agent",
    "config": {
      "methods": ["read"],
      "require_api_token_auth": false
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The API returns the database record along with the secure endpoint URL:

{
  "id": "mcp_8f7d6e5c",
  "name": "Cledara AI Agent",
  "config": { "methods": ["read"] },
  "expires_at": "2026-12-31T23:59:59.000Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

This URL is fully self-contained. The cryptographic token in the path encodes the specific Cledara tenant and tool filters.

Connecting the MCP Server to Claude

Once you have your Truto MCP URL, you need to register it with your LLM client. All communication happens over HTTP POST using standard JSON-RPC 2.0 messages.

Method A: Via the Claude Desktop UI

If you are using Claude Desktop (or ChatGPT's UI), you can add the connector visually:

1. Open Claude Desktop.
2. Navigate to Settings > Integrations > Add MCP Server (in ChatGPT, this is under Settings > Connectors > Add custom connector).
3. Enter a friendly name, such as "Cledara Finance Engine".
4. Paste the Truto MCP URL you generated earlier.
5. Click Add.

Claude will immediately send an initialize request to the server to perform a handshake, followed by a tools/list request to discover the available Cledara operations.

Method B: Via Manual Config File

If you prefer managing infrastructure as code, you can define the MCP server in Claude Desktop's configuration file.

Locate your claude_desktop_config.json file (typically found in ~/Library/Application Support/Claude/ on macOS or %APPDATA%\Claude\ on Windows) and add the Server-Sent Events (SSE) transport configuration:

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

Restart Claude Desktop. The model now has real-time access to the Cledara API.

Hero Tools for Cledara

Truto exposes a standardized set of tools based on the Cledara API schema. We enforce a documentation-driven approach - a tool only appears in the MCP server if it has a corresponding documentation record defining its query and body schemas. This acts as a quality gate to prevent AI hallucinations.

Here are 5 hero tools you can utilize immediately to automate Cledara workflows.

list_all_cledara_transactions

This tool allows Claude to fetch transaction records within a Cledara workspace. It supports optional date-range and application filters. It returns detailed transaction records including the unique id, amount, currency, type, authorizedAt, virtual card details, the hasInvoice flag, and associated accounting field values.

Contextual Usage Notes: Because Cledara workspaces can process thousands of transactions, this endpoint utilizes pagination. Truto automatically injects limit and next_cursor properties into the JSON schema. The tool description explicitly instructs the LLM to pass cursor values back unchanged when paginating through large data sets.

"Claude, list all Cledara transactions for the last 30 days filtered by the application ID 'app_998877'. If there are more than 50 results, paginate through the list and calculate the total amount spent in USD."

get_single_cledara_transaction_invoice_url_by_id

This tool retrieves the temporary, pre-signed URL required to download a specific Cledara transaction invoice. It expects a single required parameter: the transaction id.

Contextual Usage Notes: This tool should only be called on transactions where the hasInvoice flag is true. The LLM can be instructed to first list transactions, filter for those with invoices, and then iterate through the IDs using this tool to compile a list of download links for the finance team.

"Look up the transaction with ID 'tx_123456'. If it has an invoice, get the invoice URL and format it as a markdown link so I can download it directly."

list_all_cledara_applications

This tool lists all SaaS applications registered within the Cledara workspace. It returns application records identified by a unique id, alongside metadata like the application name, status, assigned department, and renewal dates as defined by Cledara's upstream schema.

Contextual Usage Notes: This is the primary discovery tool for auditing Shadow IT or understanding the company's SaaS stack. The application IDs retrieved here are necessary inputs for filtering transactions in the list_all_cledara_transactions tool.

"Fetch all active applications in our Cledara workspace. Group them by department and output a table showing the application name, status, and unique ID."

get_single_cledara_application_by_id

This tool retrieves the full, granular details of a specific SaaS application. While the list tool provides a high-level overview, this endpoint returns the complete nested JSON object, including specific virtual card limits, exact renewal cadence, and the designated software owner.

Contextual Usage Notes: Use this when the agent needs to deep-dive into the compliance or ownership details of a specific software vendor before making a budget recommendation.

"Get the full details for the application ID 'app_112233'. Identify who the internal owner is and what the monthly virtual card spending limit is set to."

list_all_cledara_users

This tool fetches the directory of users within the Cledara workspace, including their roles, statuses, and assigned department configurations.

Contextual Usage Notes: User data is critical for mapping software spend back to specific teams. Claude can use this tool to cross-reference application owners against active employee lists to identify orphaned SaaS applications (apps owned by employees who have been offboarded).

"List all users in the Cledara workspace. Find any users whose status is inactive, then check if any of those inactive users are still listed as the primary owner for active applications."

For the complete tool inventory, schema details, and custom field handling, visit the Cledara integration page.

Workflows in Action

With the MCP server connected and tools exposed, Claude can orchestrate multi-step API workflows. Because Truto handles the flat input namespace - automatically parsing the LLM's arguments into the correct query parameters or request bodies based on the schemas - the agent can execute complex logic reliably.

Scenario 1: The Automated SaaS Spend Audit

Finance teams spend hours reconciling monthly SaaS expenditures. An AI agent can automate the discovery of missing invoices and calculate total spend per application.

"Claude, fetch all active Cledara applications. For the application named 'Datadog', list all transactions from the previous month. Calculate the total spend. If any transaction is missing an invoice, flag it. For the transactions that do have invoices, get their download URLs and provide them in a list."

Step-by-step execution:

1. Claude calls list_all_cledara_applications to find the exact ID for 'Datadog'.
2. Claude calls list_all_cledara_transactions using the discovered application ID and applies a date filter for the previous month.
3. Claude iterates through the results, calculating the sum of the amount fields.
4. Claude filters the array for records where hasInvoice is true, and calls get_single_cledara_transaction_invoice_url_by_id for each.
5. The user receives a clean markdown summary of total Datadog spend, a list of flagged transactions missing documentation, and direct links to download the available invoices.

sequenceDiagram
    participant User as Finance Team
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant CledaraAPI as Cledara API

    User->>Claude: "Audit Datadog spend & get invoices"
    Claude->>Truto: tools/call (list_all_cledara_applications)
    Truto->>CledaraAPI: GET /applications
    CledaraAPI-->>Truto: JSON Array of Apps
    Truto-->>Claude: Returns App ID 'app_8899'
    Claude->>Truto: tools/call (list_all_cledara_transactions)<br>query: {app_id: "app_8899"}
    Truto->>CledaraAPI: GET /transactions
    CledaraAPI-->>Truto: Transactions Data
    Truto-->>Claude: Returns Tx array
    Claude->>Truto: tools/call (get_single_cledara_transaction_invoice_url_by_id)<br>query: {id: "tx_123"}
    Truto->>CledaraAPI: GET /transactions/tx_123/invoice
    CledaraAPI-->>Truto: { "invoiceUrl": "https://..." }
    Truto-->>Claude: Returns URL string
    Claude-->>User: Markdown summary with calculations & links

Scenario 2: Identifying Orphaned Shadow IT

IT Administrators need to ensure that when employees leave, the SaaS applications they managed are reassigned or cancelled.

"Claude, get a list of all Cledara users. Identify anyone marked as 'inactive'. Next, get a list of all Cledara applications. Cross-reference the two lists. If an active application is owned by an inactive user, output a security alert detailing the app name, the inactive owner, and the monthly card limit."

Step-by-step execution:

1. Claude calls list_all_cledara_users and filters the response in memory for inactive statuses.
2. Claude calls list_all_cledara_applications to retrieve the workspace's entire software stack.
3. Claude compares the owner_id on each application against the list of inactive users.
4. For any matches, Claude extracts the application name and budget limits.
5. The user receives an actionable security report highlighting orphaned applications that need immediate credential rotation or cancellation.

Security and Access Control

When connecting an AI agent to a financial system like Cledara, security is paramount. Truto provides multiple layers of access control at the MCP token level:

• Method Filtering: You can strictly limit the MCP server to read-only operations. By passing config: { methods: ["read"] } during creation, Truto will generate tools for get and list operations, but will entirely strip create, update, or delete tools from the manifest. The LLM simply won't know write operations exist.
• Tag Filtering: If your Cledara integration is configured with custom tool_tags (e.g., tagging certain resources as "finance_only"), you can scope the MCP server to only expose tools matching specific tags.
• Require API Token Auth: By default, possession of the MCP server URL is enough to connect. If you set require_api_token_auth: true, Truto injects a secondary authentication middleware. The client must then pass a valid Truto API token as a Bearer token in the Authorization header, ensuring only authenticated systems can invoke tools.
• Automatic Expiration: You can provision temporary access for contractors or temporary AI agents by setting an expires_at ISO datetime. Truto's edge infrastructure schedules an alarm that automatically deletes the token and configuration from storage exactly when the time expires, enforcing least-privilege access.

By leveraging Truto's managed MCP architecture, your engineering team escapes the burden of writing integration boilerplate, managing pagination loops, and updating custom JSON mappings. You simply generate the server, connect the LLM, and start auditing your SaaS stack instantly.