Agent-native double-entry accounting ledger with x402 micropayments
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.
Average 3.6/5 across 11 of 11 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose: account inquiries, financial reports, directive management, validation, key generation, and batch submission. No two tools overlap in functionality despite some being related reports.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., export_ledger, get_balance_sheet, list_accounts). The naming is predictable and clear throughout.
With 11 tools covering ledger management, reporting, validation, and key generation, the count is well-scoped for the server's purpose. Each tool justifies its existence without being too few or too many.
The tool set covers essential operations for a Beancount ledger: submission of directives (single and batch), listing of accounts and directives, generation of key financial reports, balance queries, validation, and key registration. No obvious gaps are present.
export_ledgerBInspectExport the full ledger as literal Beancount text — a portable snapshot for fava/bean-report/etc., not the live store. Shares a combined free allowance of 2 with get_balance_sheet, get_income_statement, and get_trial_balance (the "report tier") — not 2 free calls for each of those four separately.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | ||
| signature | Yes | ||
| timestamp | Yes | ||
| public_key | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the tool is a snapshot export (not live store) and allowance sharing, but lacks details on permissions, rate limits, or return format.
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, efficient and front-loaded, but could be more concise by integrating parameter details.
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 no output schema and 5 parameters, the description omits critical parameter explanations and return value info, making it incomplete for a parameter-heavy 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?
With 0% schema description coverage, the description adds no meaning to any of the 5 parameters (nonce, signature, timestamp, public_key, optional payment_header), leaving agents without guidance.
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 exports the full ledger as Beancount text, a portable snapshot, distinguishing it from live store. It also contextually differentiates from sibling report tools via allowance sharing.
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?
Provides explicit context on when to possibly avoid (due to shared allowance with other report tools), but does not explicitly state when to use or not use alternatives beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_balanceBInspectBalance of a single account. Settles at the same fixed price whether the account exists or not — an "unknown account" answer is still a valid, billable response (no per-error pricing discount). No free-trial allowance for this specific tool, unlike list_directives (same price, but list_directives has 2 free calls and this doesn't) — the free tier applies to browsing (list_directives, list_accounts) and the report tier, not per-account lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | ||
| account | Yes | ||
| signature | Yes | ||
| timestamp | Yes | ||
| public_key | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides important behavioral details: fixed pricing regardless of account existence and no free-trial allowance. This informs the agent about billing implications beyond basic functionality.
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 moderately concise but includes a long second sentence with detailed pricing logic that could be shortened without losing meaning.
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 tool with 6 parameters, no output schema, and no annotations, the description covers only pricing context. Missing parameter explanations and return value information make it incomplete.
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 description does not explain any of the 6 parameters (nonce, account, signature, etc.) despite 0% schema coverage. The agent must rely solely on parameter names, which may be insufficient.
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 indicates it retrieves the balance of a single account. It distinguishes from sibling tools like list_accounts (listing) and get_balance_sheet (full report), but does not explicitly use a verb like 'get' in the first sentence.
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 mentions when to use (single account balance) and contrasts pricing with list_directives, but lacks explicit guidance on when not to use or alternatives for other scenarios like batch lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balance_sheetAInspectFull realize() balance sheet — often served from cache. Settles at the same fixed price regardless of cache hit/miss. Shares a combined free allowance of 2 with export_ledger, get_income_statement, and get_trial_balance (the "report tier") — not 2 free calls each.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | ||
| signature | Yes | ||
| timestamp | Yes | ||
| public_key | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses cache behavior and fixed pricing, but does not mention read-only nature, authentication requirements beyond parameters, or rate limits. This is adequate but not comprehensive.
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 only three sentences with no extraneous information. The core purpose is front-loaded, and every sentence adds value regarding caching, pricing, and allowance. It is a model of 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 absence of an output schema, the description should have explained the return value. It also fails to compensate for the lack of parameter descriptions. The tool has moderate complexity (auth params, optional payment header), so more context is 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 description coverage is 0% and the description provides no information about any of the 5 parameters (nonce, signature, timestamp, public_key, payment_header). The agent has no guidance on parameter usage or formats, which is a critical gap.
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 retrieves a 'full realize() balance sheet', specifying the resource and verb. It adds nuance about caching and fixed pricing, distinguishing it from siblings that might have different caching or pricing behaviors.
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 mentions a shared free allowance with export_ledger, get_income_statement, and get_trial_balance, guiding the agent on quota management. However, it does not explicitly state when not to use this tool or provide alternatives beyond the shared allowance mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_income_statementAInspectIncome statement, period-scoped by since/until (ISO date strings, both optional — omitted means whole history). Always books full history first, then clamps the output to the requested period (never filters input dates — see reports.py for why). Shares a combined free allowance of 2 with export_ledger, get_balance_sheet, and get_trial_balance (the "report tier") — not 2 free calls each.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | ||
| since | No | ||
| until | No | ||
| signature | Yes | ||
| timestamp | Yes | ||
| public_key | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden, revealing that the tool books full history then clamps output, and shares a combined allowance with three sibling tools.
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 wasted words, but the second sentence is dense and could be broken for readability.
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?
Covers purpose, key params, and behavioral quirk, but lacks description of return format (no output schema) and does not explain auth parameters, leaving some gaps.
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 description adds meaning for 'since' and 'until' (ISO dates, optional, behavior when omitted) but ignores the five other parameters (auth fields, payment_header), and schema coverage is 0%.
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 produces an income statement, period-scoped by since/until, and differentiates from sibling tools by mentioning combined allowance with report-tier siblings.
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 specifies when to use (for income statements) and notes shared allowance with related tools, but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trial_balanceCInspectTrial balance, period-scoped same as income statement — same underlying compute, priced and audited as its own resource. Shares a combined free allowance of 2 with export_ledger, get_balance_sheet, and get_income_statement (the "report tier") — not 2 free calls each.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | ||
| since | No | ||
| until | No | ||
| signature | Yes | ||
| timestamp | Yes | ||
| public_key | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pricing and audit behavior, and that it shares a combined free allowance, which is beyond basic purpose. However, with no annotations, it lacks detail on idempotency, side effects, 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?
Two sentences, front-loaded with the key noun 'Trial balance'. Efficient and to the point, though the second sentence is slightly dense.
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 no output schema and 7 parameters, the description is too sparse. It does not explain return values, pagination, or error handling. The free allowance note is useful but insufficient for complete understanding.
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 0%, and the description provides no information about any of the 7 parameters (since, until, nonce, etc.). This fails to add meaning 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 is a trial balance, period-scoped like the income statement. It identifies the specific financial report, distinguishing it as a separate resource. However, it could more explicitly state the verb 'get' or 'retrieve' for absolute clarity.
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 to use this tool vs alternatives like get_balance_sheet or get_income_statement. The description mentions shared free allowance but does not provide criteria for choosing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_accountsAInspectList all opened accounts with their currency constraints and booking method. No booking pass involved. Your first 2 calls per registered key are free (a separate allowance from list_directives' and the report tier's — see those tools).
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | ||
| signature | Yes | ||
| timestamp | Yes | ||
| public_key | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses free call allowance but lacks other behavioral details. With no annotations, the description should mention read-only nature or authentication requirements. Currently adequate but could improve.
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, front-loaded with purpose, no wasted words. Efficiently conveys the key point and a usage nuance.
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?
With 5 parameters (4 required), no output schema, and no parameter documentation, the description is woefully incomplete. The agent lacks essential information to use the 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 0%, and the description provides no information about the five parameters (public_key, nonce, timestamp, signature, payment_header). The agent has no way to understand how to call the tool correctly.
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 'List all opened accounts with their currency constraints and booking method.' The verb 'list' and the resource 'accounts' are specific. Additionally, it distinguishes from siblings by noting 'No booking pass involved.'
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?
Provides explicit context on free call allowance and distinguishes from sibling tools list_directives and report tier. However, does not explicitly state when NOT to use this tool or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_directivesAInspectList raw directives (optionally filtered by account/date range). No
booking involved — cheapest paid tool. since/until are ISO date
strings (YYYY-MM-DD). Your first 2 calls per registered key are free
(independent of the write/accounts/report allowances — see
list_accounts, get_balance_sheet).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| nonce | Yes | ||
| since | No | ||
| until | No | ||
| account | No | ||
| signature | Yes | ||
| timestamp | Yes | ||
| public_key | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that no booking is involved, it's paid (with free first 2 calls), and gives date format. However, it fails to mention authentication requirements (public_key, nonce, signature, timestamp are required in schema but not explained), error states, or what happens after listing. Adds some value but leaves significant gaps.
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?
Three sentences, concise and front-loaded with the main action. The marketing-like phrasing 'cheapest paid tool' adds some noise but is not excessive. Could be slightly tighter by removing 'independent of...' but overall efficient.
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?
Complex tool with 9 parameters, 4 required, and no output schema. Description lacks return format, definition of a directive, and explanation of required auth parameters. References to other tools help but do not compensate for missing fundamental context.
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 0%, yet description only explains since, until, and account parameters. It does not clarify required auth parameters (public_key, nonce, signature, timestamp) or other optional parameters like payment_header and limit. Insufficient given the complete absence of schema descriptions.
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 'List raw directives' with optional filters by account/date range. Distinguishes from siblings via 'no booking involved' and 'cheapest paid tool'. The verb and resource are specific and unambiguous.
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?
Provides context on when to use (cheapest, no booking) and mentions free tier. References other tools for allowances, but does not explicitly compare to siblings like submit_directive or validate_directive. Adequate but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
registerAInspectGenerate a new Ed25519 keypair for ledger identity. Returns the private key exactly once — it is never stored server-side and cannot be recovered if lost. This is a SEPARATE keypair from whatever wallet you use to authorize x402 payments (payment auth and ledger identity are two independent signing domains — see payments.py).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: the private key is returned exactly once, never stored server-side, and irretrievable. It also explains the separation of signing domains. While it lacks details on rate limits or authentication requirements, the critical behavioral traits are well-covered.
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 two sentences long, with the first sentence stating the purpose and the second adding crucial behavioral notes. Every word adds value—no fluff, and the key points are 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 tool has no parameters, no output schema, and a simple generation purpose, the description is complete. It explains what the tool does, the unique characteristics of the keypair, and the security implications, leaving no significant gaps.
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 tool has zero parameters, and schema description coverage is 100% (empty schema). The description adds meaning by explaining what the tool does without needing parameter details, achieving the baseline expectation for a no-parameter tool.
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 tool generates a new Ed25519 keypair for ledger identity, with a specific verb 'Generate' and resource 'Ed25519 keypair'. It distinguishes itself from sibling tools by emphasizing this is separate from payment auth (x402), using the phrase 'SEPARATE keypair' and referencing independent signing domains.
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 clear context on when to use the tool (to generate a keypair) and includes critical information that the private key is returned once and cannot be recovered. It also distinguishes from wallet-based payment authorization, though it does not explicitly state when not to use it or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_batchAInspectSubmit up to 1000 directives atomically — all persist together or none do. Priced 10x a single write, regardless of batch size within the cap. Always paid — the free-trial allowance (see submit_directive) applies to single writes only, never to batches, even if you haven't used any free writes yet. Paid.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | Yes | ||
| signature | Yes | ||
| timestamp | Yes | ||
| directives | Yes | ||
| public_key | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses atomicity ('all persist together or none do') and pricing (10x a single write). Since no annotations are provided, the description carries full behavioral burden. It lacks details on auth or error handling but covers key 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 concise, with key information front-loaded. It contains minimal fluff, though pricing info is repeated. Still, every sentence serves a 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?
The tool has 6 parameters and no output schema, yet the description omits parameter details, return format, and error behavior. It covers high-level semantics but lacks completeness for practical invocation.
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 0%, and the description does not explain any parameters (e.g., nonce, signature, payment_header). Only 'directives' is implied via 'Submit up to 1000 directives'. This is insufficient for correct parameter usage.
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 'Submit up to 1000 directives atomically', specifying the verb 'submit', resource 'directives', and scope 'batch'. It distinguishes the tool from sibling 'submit_directive' by noting pricing and free-trial differences.
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?
Explicitly states when to use: 'Always paid — the free-trial allowance... applies to single writes only, never to batches'. This directly tells the agent not to use this tool for free-tier users, providing clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_directiveAInspectSubmit one Beancount directive (open, transaction, close, balance, price, note, document — any type). Paid, except your first 20 accepted writes per registered key, which are free (this specific tool only — submit_batch is always paid, even for your first call). Call with no payment_header first: if free writes remain, this succeeds immediately; otherwise you'll get price/asset/recipient back, so you can retry with payment_header set to your signed X-PAYMENT-equivalent payload (fresh nonce required on the retry — each call is independently signed).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| nonce | Yes | ||
| signature | Yes | ||
| timestamp | Yes | ||
| public_key | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description fully explains payment, free tier, and nonce requirements. However, error cases beyond payment are not detailed.
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?
Information-rich but somewhat verbose; could be more concise by separating workflow from parameter description.
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?
Covers main behavior and two outcomes (success or payment info), but lacks return value format and error handling context for a tool with no output schema.
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 0% schema coverage, description doesn't explain individual parameters (text, nonce, signature, etc.) beyond their role in the workflow.
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 submits a Beancount directive (open, transaction, etc.) and differentiates from sibling submit_batch via free vs paid model.
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?
Explicitly explains the two-step process: call without payment_header first to get free writes, then on failure retry with payment_header and fresh nonce.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_directiveBInspectFree dry-run: parse+book text against your full history without persisting or charging anything. Still requires a valid signature (identity/replay protection is not a billing concern).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| nonce | Yes | ||
| signature | Yes | ||
| timestamp | Yes | ||
| public_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool does not persist or charge, but does not elaborate on error behavior, success output, or what 'parse+book' entails. No annotations are provided, so the description carries the full burden.
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 two concise sentences with front-loaded key information ('Free dry-run'), no extraneous details.
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?
With 5 required parameters, no output schema, and no annotations, the description is insufficient. It fails to explain parameters or return values, leaving the agent with incomplete context.
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 has 5 required parameters with 0% description coverage, and the tool description does not explain any parameters. No guidance on what public_key, nonce, timestamp, or signature mean or how they should be formatted.
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 is a 'free dry-run' that parses and books text without persisting or charging, distinguishing it from siblings like submit_directive that actually submit directives.
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 for testing before submission (dry-run) and notes signature requirement, but does not explicitly state when to use or when not to use it compared to alternatives like submit_directive.
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.
No comments yet. Be the first to start the discussion!
