Skip to main content
Glama
Sign In
cledara-mcp

cledara-mcp

by ilyesBen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List Cledara transactions

list_transactions
Read-onlyIdempotent

Retrieve raw Cledara transactions—including SaaS and Spend card activity, transfers, and top-ups—for a date range; defaults to the last 30 days and supports pagination.

Instructions

List raw Cledara transactions (SaaS and Spend cards, transfers, top-ups) in a date range. Amounts are negative for debits. Defaults to the last 30 days. If nextOffset is returned, call again with that offset for more.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_transactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoEnd of range (inclusive): YYYY-MM-DD (UTC) or an RFC 3339 timestamp.
fromNoStart of range (inclusive): YYYY-MM-DD (UTC) or an RFC 3339 timestamp.
typesNoOnly return these transaction types (filtered after fetching).
offsetNoPagination offset from a previous call's nextOffset.
maxPagesNoAPI pages to fetch in this call.
applicationIdsNoOnly include transactions for these application IDs (from list_applications).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety bar is low. The description nonetheless adds real behavioral context the annotations can't: the amount sign convention (negative for debits) and the pagination loop contract with nextOffset, both of which are essential to interpreting results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each doing distinct work: scope, sign convention, default window plus pagination. Nothing is redundant and the resource definition leads.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately covers return shape basics (raw transactions, sign convention, nextOffset presence) and pagination. It doesn't mention that post-fetch type filtering can yield short pages, which matters for an agent accumulating results, but the core call correctness is covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are already documented, including the post-fetch nature of the types filter and the offset provenance. The description repeats the offset continuation usage but adds no syntax or constraint detail beyond the schema, which is the expected baseline here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List raw Cledara transactions') and enumerates the covered sources (SaaS and Spend cards, transfers, top-ups), which implicitly separates it from the aggregate sibling spend_summary. It never names a sibling alternative explicitly, so the differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete operating context: default window of the last 30 days when no range is supplied, and the exact continuation rule ('If nextOffset is returned, call again with that offset'). It stops short of when-not-to-use guidance or naming spend_summary as the aggregated alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools