Skip to main content
Glama
Sign In
cledara-mcp

cledara-mcp

by ilyesBen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List people and teams

list_people
Read-onlyIdempotent

Retrieves people and teams in a workspace by inferring them from application owners, application teams, and recent cardholders, with optional lookback for cardholder data.

Instructions

People and teams in the workspace, inferred from application owners, application teams and cardholders seen in recent transactions (Cledara has no users endpoint).

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_people"
  }
}

Input Schema

NameRequiredDescriptionDefault
cardholderLookbackDaysNoHow many days of transactions to scan for cardholders. 0 skips cardholders.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds genuinely non-obvious context the annotations cannot: the data is inferred rather than authoritative, and it is surfaced from three indirect sources because no users endpoint exists — a real caveat for trusting results. It does not warn about staleness or completeness of the inference, keeping it from a 5.

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?

One sentence, front-loaded with the resource, then the derivation sources, then the reason those sources are used. Every clause carries information an agent could not get from the schema, and there is no filler.

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?

For a single-optional-parameter read-only tool this is nearly complete: it explains the origin and limits of the data, which is the main risk. The one gap is that with no output schema, the agent gets no hint of the returned shape (e.g., person vs team objects, identifier fields), so it must discover return structure by calling.

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 the single optional parameter (cardholderLookbackDays, its default of 90, and that 0 skips cardholders) is fully documented in the schema. The description's mention of 'cardholders seen in recent transactions' loosely motivates that parameter but adds no syntax or behavioral detail beyond the schema, so the baseline 3 applies.

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?

The description names the resource clearly ('People and teams in the workspace') and, crucially, explains where that resource comes from — application owners, application teams, and cardholders from recent transactions. The parenthetical 'Cledara has no users endpoint' distinguishes it from what an agent might expect and from siblings like list_applications and list_transactions, though the verb itself is only implied by the tool name.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: because there is no users endpoint, this is presumably the only way to enumerate people, but the description never says 'use this when you need to identify a person or resolve an owner/cardholder.' No exclusions or explicit alternative routing are given, leaving the agent to infer the selection rule.

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