modern-treasury
Server Details
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- m190/usefulapi-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 14 of 17 tools scored.
Each tool targets a distinct resource (counterparty, ledger account, payment order, etc.) with clear actions (create, get, list, ping). There is no ambiguity between tools.
All tools follow a consistent 'modern_treasury_verb_singular_or_plural_resource' pattern in snake_case. The naming is uniform and predictable.
17 tools cover multiple financial entities and operations, which is reasonable for a treasury API. It's on the higher end but not excessive given the domain.
The tool set is heavily read-only, with only one create operation (counterparty). Missing create/update/delete for payment orders, ledger transactions, and other core actions, which severely limits functionality for a treasury system.
Available Tools
17 toolsmodern_treasury_create_counterpartyCreate counterpartyADestructiveInspect
Creates a counterparty (contact) record in Modern Treasury. Creates a record only — no bank details, MOVES NO MONEY. API: POST /counterparties.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Counterparty (contact) name. | |
| No | Counterparty email. | ||
| metadata | No | Arbitrary string key/value metadata. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint: true, which may suggest potential side effects, but the description clarifies that it only creates a record and moves no money. This adds valuable context beyond the annotation, reassuring that the operation is limited. It could further mention reversibility or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the most critical information (purpose, scope, API endpoint) front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, scope, and endpoint, which is adequate for a simple create operation with complete schema coverage. However, since there is no output schema, mentioning the response format or common error cases would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description. The tool description does not add any additional parameter-level information beyond what is in the schema, so it earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Creates'), the resource ('counterparty (contact) record'), and explicitly distinguishes from related functionality by stating 'no bank details, MOVES NO MONEY'. This provides high clarity and differentiation from sibling tools that handle financial operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates the tool's limited scope ('Creates a record only') and what it does not do ('no bank details, MOVES NO MONEY'), which implies when to use it. However, it does not name specific alternatives for tasks involving bank details or money movement, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_get_counterpartyGet counterpartyARead-onlyInspect
Get a single counterparty by id. API: GET /counterparties/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Counterparty id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, so the description's 'Get' verb aligns with read-only behavior. No additional behavioral details are provided (e.g., rate limits, authorization, or side effects), but the annotation covers the main trait, earning a baseline 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with essential information. It sacrifices no clarity for brevity, though it could slightly expand on context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema) and high schema coverage, the description is sufficient but minimal. It does not mention the structure of the returned counterparty object, which is acceptable as the tool name implies the return type, but a bit more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id,' and its description in the schema is 'Counterparty id.' The tool description does not add extra meaning beyond this, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single counterparty by id,' specifying the action (get) and resource (counterparty). It implicitly distinguishes from sibling tools like modern_treasury_list_counterparties by indicating a single entity retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the API endpoint but offers no explicit guidance on when to use this tool versus alternatives (e.g., list counterparties or get other entities). It implies usage when an id is available but lacks exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_get_ledger_accountGet ledger accountARead-onlyInspect
Get a single ledger account by id, including balances. API: GET /ledger_accounts/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Ledger account id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the tool includes balances and specifies the HTTP GET endpoint, but beyond the readOnlyHint annotation, it does not disclose other behavioral traits such as error handling, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and key information. Every word is purposeful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and readOnlyHint annotation, the description fully conveys its purpose and behavior. Including the API endpoint and balance detail makes it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the 'id' parameter. The tool description adds the context of fetching 'by id' but does not provide additional semantics beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'single ledger account by id', and specifies it 'includes balances'. It is distinct from sibling tools like modern_treasury_list_ledger_accounts, which list multiple accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a specific id is known, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_get_payment_orderGet payment orderARead-onlyInspect
Get a single payment order by id (READ ONLY). API: GET /payment_orders/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Payment order id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true; description adds 'READ ONLY' and API endpoint, but no further behavioral context like auth requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with key action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with full schema and read-only hints, description adequately covers behavior, endpoint, and scope. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'id' described. Description doesn't add meaning beyond what schema provides; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and resource 'payment order', specifies 'single by id', distinguishes from list_payment_orders. The API endpoint adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage when you have an id; no explicit when-not or alternatives. The 'READ ONLY' hint provides minimal guidance but is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_get_transactionGet transactionARead-onlyInspect
Get a single transaction by id. API: GET /transactions/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Transaction id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true; description adds API endpoint but not behavioral traits beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences, no wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one required parameter and no output schema; description is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter description; the tool description does not add meaningful extra detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a single transaction by id, distinguishing from list_transactions or other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when you need a specific transaction by id, but lacks explicit exclusion of alternatives like list_transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_counterpartiesList counterpartiesBRead-onlyInspect
List counterparties (contacts). API: GET /counterparties.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by counterparty name. | |
| No | Filter by counterparty email. | ||
| per_page | No | Results per page (default 25, max 100). | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the read-only nature is clear. The description adds the API endpoint, confirming the operation. However, it provides no additional behavioral details such as pagination behavior, rate limits, or data freshness, which would be helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point (one sentence). It could include a bit more context, but it is not verbose and front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple list nature and good schema/annotations, the description covers the basics. However, it lacks usage guidelines and any notes on default ordering or pagination behavior, which would improve completeness for an agent invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description (e.g., 'Filter by counterparty name'). The tool description adds no further parameter-level meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists counterparties (contacts) using verb 'list' + resource, and the API endpoint confirms the action. It is clear and distinct from sibling tools like create or get, though it doesn't explicitly differentiate from other list tools (which target different resources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are sibling tools like create_counterparty and get_counterparty, but the description offers no context for when to list vs. get or create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_expected_paymentsList expected paymentsARead-onlyInspect
List expected payments (READ ONLY). API: GET /expected_payments.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status, e.g. unreconciled, reconciled. | |
| per_page | No | Results per page (default 25, max 100). | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only behavior is covered. The description confirms this with 'READ ONLY' and the GET method. No additional behavioral traits (e.g., pagination, sorting defaults) are disclosed, but the schema covers pagination fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus the API path. It avoids redundancy with the schema and annotations. All words add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with well-described parameters and annotations, the description is nearly complete. It lacks a mention that the response is a list, but this is implicit from the tool name and verb. Overall, it provides sufficient context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since all three parameters are described in the input schema. The description adds no extra meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('expected payments'), clearly indicating the tool's function. It distinguishes from sibling list tools by naming the specific resource. The annotation 'READ ONLY' and API path further clarify purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool versus alternatives is provided. However, since there is no sibling tool for expected payments, the context is somewhat implicit. A stronger description would include a hint about using single-resource tools for detail views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_external_accountsList external accountsARead-onlyInspect
List external (counterparty) bank accounts. API: GET /external_accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Results per page (default 25, max 100). | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). | |
| counterparty_id | No | Filter by owning counterparty id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the API endpoint (GET /external_accounts) but does not disclose additional behavioral traits beyond the readOnlyHint annotation. The schema covers pagination details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence plus the API endpoint. No fluff, immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple list operation, the description combined with schema and annotations is adequate. No output schema, but return type is implied. Minor gap in usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add parameter info. It adds no extra semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists external (counterparty) bank accounts, distinguishing it from sibling list tools like modern_treasury_list_internal_accounts. The verb 'list' and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The name and description imply use for external accounts, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_internal_accountsList internal accountsBRead-onlyInspect
List your organization's internal bank accounts. API: GET /internal_accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Results per page (default 25, max 100). | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats the API endpoint ('GET /internal_accounts') and does not disclose any behavioral traits beyond the annotation's readOnlyHint=true. It does not mention pagination behavior, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. However, the API endpoint is redundant given the tool name and could be omitted. Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two parameters and no output schema, the description minimally covers the basics. But it lacks context on what 'internal accounts' are, difference from external accounts, or expected result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters (per_page, after_cursor) well. The description adds no extra meaning beyond this, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'internal bank accounts', making it easy to understand the tool's purpose. It differentiates well from sibling tools like list_external_accounts or list_ledger_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_external_accounts. There are no hints about prerequisites, filtering, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_ledger_accountsList ledger accountsBRead-onlyInspect
List ledger accounts. API: GET /ledger_accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Results per page (default 25, max 100). | |
| ledger_id | No | Filter by ledger id. | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, and the description adds no additional behavioral context (e.g., pagination behavior, rate limits, or warnings). It simply restates the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences, minimal waste). However, it could include more useful information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description minimally covers the basic action. It lacks mention of return format or pagination behavior, but the parameters provide some context. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description does not add meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'ledger accounts', and the API endpoint is included. It distinguishes from siblings like get_ledger_account and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of prerequisites, filtering beyond parameters, or when not to use. The description only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_ledger_entriesList ledger entriesBRead-onlyInspect
List ledger entries (individual debits/credits). API: GET /ledger_entries.
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Results per page (default 25, max 100). | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). | |
| ledger_account_id | No | Filter by ledger account id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to reiterate safety. The description adds the API endpoint but no further behavioral details (e.g., pagination behavior, rate limits, or side effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—two sentences with no filler. Front-loads the purpose and includes the API endpoint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal complexity (3 optional params, no output schema), the description is adequate but does not explain return format or provide higher-level context to help an AI agent choose among many list siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described in the schema. The tool description adds no additional semantic meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists ledger entries and identifies them as 'individual debits/credits', which distinguishes from ledger transactions. However, it does not explicitly differentiate from other list siblings like list_ledger_accounts or list_ledger_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., list_ledger_transactions). No prerequisites, context, or usage scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_ledgersList ledgersBRead-onlyInspect
List double-entry ledgers. API: GET /ledgers.
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Results per page (default 25, max 100). | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only repeats 'List' and provides the API endpoint, adding no behavioral details beyond the annotation readOnlyHint. No mention of pagination, ordering, or other traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (8 words) and front-loaded with the key action. Every word serves a purpose, but additional context could be added without substantial bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 2 parameters and readOnlyHint annotation, the description provides the minimal functionality and endpoint. It does not mention return format or defaults, but given low complexity, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both per_page and after_cursor are described in the input schema. The description adds no extra parameter meaning; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List double-entry ledgers' clearly states the action (list) and the resource (ledgers). It distinguishes from sibling list tools for other resources like counterparties, accounts, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs alternatives, but the resource name differentiates it from other list tools. Usage is implied by the resource, but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_ledger_transactionsList ledger transactionsBRead-onlyInspect
List ledger transactions (READ ONLY — does not post value). API: GET /ledger_transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Results per page (default 25, max 100). | |
| ledger_id | No | Filter by ledger id. | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces the read-only behavior already indicated by annotations ('readOnlyHint': true) and adds the API endpoint. It does not disclose additional behavioral traits such as pagination behavior, result limits, or potential errors, but the annotations cover the key safety aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only one sentence that efficiently conveys the purpose and a critical safety note. No extraneous words are present, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully describes parameters, annotations indicate read-only, and no output schema exists, the description is mostly complete. It could mention the response structure or pagination behavior, but the schema parameters for pagination (per_page, after_cursor) imply this, and the description's brevity is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well-documented in the input schema. The description adds no information about parameters, so it does not enhance understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing ledger transactions and includes a specific note that it is read-only and does not post value. However, it does not explicitly differentiate this tool from sibling list tools like list_ledger_accounts or list_ledger_entries, leaving some ambiguity for an agent to select the correct one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. The description only states the operation and its read-only nature, but does not specify contexts or criteria that would help an agent decide between this and other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_payment_ordersList payment ordersARead-onlyInspect
List payment orders (READ ONLY — does not create or approve payments). API: GET /payment_orders.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status, e.g. approved, pending, completed. | |
| per_page | No | Results per page (default 25, max 100). | |
| direction | No | Filter by direction. | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). | |
| counterparty_id | No | Filter by counterparty id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces the annotation's readOnlyHint by explicitly stating 'READ ONLY — does not create or approve payments', and adds the HTTP method GET. This provides clarity beyond the annotation, though it does not disclose pagination behavior or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, front-loading the purpose and including the API endpoint. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description adequately conveys the tool's purpose and read-only nature, it lacks information about the return format (e.g., a paginated list of payment orders) since no output schema is provided. The pagination parameters imply pagination, but not explicitly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters with descriptions (coverage 100%), so the description does not need to add parameter details. It does not provide additional context beyond the schema, hence a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'payment orders', and emphasizes it is read-only. However, it does not explicitly differentiate from the sibling tool 'modern_treasury_get_payment_order' which retrieves a single order, leaving the scope (list vs. single) implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance by stating it is read-only and not for creation or approval, but it does not mention when to use this list tool versus other list tools or alternatives like 'modern_treasury_get_payment_order'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_returnsList returnsARead-onlyInspect
List payment returns (e.g. ACH returns). API: GET /returns.
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Results per page (default 25, max 100). | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'API: GET /returns' confirms a safe read operation, but adds little beyond that. No behavioral details about pagination, limits, or side effects are provided, though the schema covers pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one sentence plus the API endpoint. No redundant information is present; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list returns, two optional params, no output schema), the description is complete. The schema covers parameters, annotations cover safety, and the description provides purpose and endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (per_page, after_cursor) fully documented in the schema. The description adds no additional parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List payment returns' with an example 'ACH returns', using a specific verb and resource. This distinguishes it from sibling list tools like list_counterparties or list_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for listing returns, and sibling tools cover different entities. However, there is no explicit when-to-use or when-not-to-use guidance, which would elevate to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_list_transactionsList transactionsBRead-onlyInspect
List bank transactions. API: GET /transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Results per page (default 25, max 100). | |
| after_cursor | No | Pagination cursor from a prior response's next_cursor (X-After-Cursor header). | |
| internal_account_id | No | Filter by internal account id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds minimal behavioral context. It mentions the API method (GET) but does not discuss pagination, filtering, or other behaviors beyond what is evident from the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The most important information (purpose and API endpoint) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema coverage and annotations, the description is minimally adequate. However, it does not summarize key details like pagination or filtering, which would help an agent quickly understand the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds no additional meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists bank transactions and provides the API endpoint. The verb 'list' and resource 'bank transactions' are specific, but it does not explicitly differentiate from sibling list tools like list_payment_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is a sibling tool for getting a single transaction, but no mention of when to choose list versus get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modern_treasury_pingPing (auth check)ARead-onlyInspect
Verify connectivity and credentials. API: GET /ping.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds minimal context beyond annotations (readOnlyHint=true). Does not detail response format or failure modes. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded purpose, no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter ping tool without output schema, the description fully informs the agent of its function and endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage 100% vacuously. Baseline 4 applies; description adds no parameter info but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool verifies connectivity and credentials, distinguishing it from sibling CRUD tools. Specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when to use or alternatives, but the purpose is self-evident for a health check. Implied usage before other calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!