journalize
Server Details
Agent-native double-entry accounting ledger with x402 micropayments
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.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.
Available Tools
11 toolsexport_ledgerAInspect
Export 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it exports a portable snapshot (not live store) and mentions rate limits via shared allowance. However, with no annotations, does not cover idempotency, side effects, or authentication details beyond parameters.
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, zero wasted words. First sentence clearly states purpose, second adds critical rate-limit context. Efficient and 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 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what Beancount text is, how to use the output, or the meaning of any parameter.
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 of the 5 parameters (cryptographic fields, payment_header). Completely 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?
Clearly states 'Export the full ledger as literal Beancount text', specifying the action (export), the resource (full ledger), and the output format. Distinguishes from siblings by noting it's a portable snapshot, not the live store.
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: use for fava/bean-report/etc., and shares a combined free allowance with other report tools. Implicitly tells when not to use (other report tools have separate allowances), but does not explicitly list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_balanceBInspect
Balance 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses that the tool charges the same price whether the account exists or not, and that no free trial applies. This adds valuable behavioral context beyond basic purpose.
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 spends two of three sentences on pricing details that could be condensed. The main purpose 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 zero parameter descriptions and no output schema, the description leaves significant gaps: how to sign requests, response format, and error conditions are absent. It is insufficient for an agent to use correctly without external knowledge.
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 the description does not explain any of the 6 parameters (nonce, account, signature, etc.). The tool requires cryptographic parameters, which are completely undocumented, severely hindering correct invocation.
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 returns the balance of a single account, which is a specific verb+resource. It is distinct from sibling tools like list_accounts or get_balance_sheet.
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 usage context regarding pricing and error handling, comparing to list_directives, but lacks explicit guidance on when to use this tool versus others or prerequisites like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balance_sheetBInspect
Full 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals caching behavior, fixed pricing regardless of cache state, and shared free allowance. This is useful but lacks details on side effects, permissions, or response structure.
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 with no wasted words. The first sentence delivers the core purpose and a key behavioral note (caching), and the second adds pricing context. Structure is optimal.
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 5 parameters (4 required) and no output schema, the description is incomplete. It ignores authentication parameters and return values. The pricing context is helpful but insufficient for an agent to use the tool correctly without additional knowledge.
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 provides zero explanation for any of the five parameters (nonce, signature, timestamp, public_key, payment_header). Since schema coverage is 0%, the description should compensate but offers no guidance on parameter semantics.
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 the 'Full realize() balance sheet', which is the core purpose matching the tool name. The mention of caching and pricing adds context, distinguishing it from financial report 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 provides pricing and allowance sharing info with specific sibling tools (export_ledger, get_income_statement, get_trial_balance), which guides agents on cost-aware usage. However, it does not explicitly state when to use this tool over alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_income_statementBInspect
Income 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses important behavioral traits: the tool always processes full history then clamps output to the requested period, and it shares a combined free allowance. This goes beyond typical function descriptions.
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 (two sentences) and front-loaded with the core purpose. It includes a parenthetical explaining internal behavior and quota, which is efficient, though 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 incomplete. It omits return value details, error conditions, and does not describe most parameters. The quota and internal behavior are helpful but insufficient for full agent 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?
The description adds meaning for the 'since' and 'until' parameters (ISO date strings, optional, default to whole history), but with 0% schema coverage and 7 parameters including authentication ones, it covers only 2 out of 7. It does not describe the required auth parameters or the optional payment_header.
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 provides an income statement scoped by optional since/until parameters. It distinguishes from siblings by noting the shared free allowance with other report tools, but does not explicitly contrast the nature of the report (e.g., income statement vs balance sheet).
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 a combined free allowance with three siblings, implying they are alternatives in terms of cost, but does not provide guidance on when to use this tool instead of others like get_balance_sheet or get_trial_balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trial_balanceCInspect
Trial 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as read-only nature, authentication needs, or side effects. Only hints at cost and audit status.
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 short sentences, no fluff, directly conveys key information about scope and cost sharing.
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 no output schema and 7 parameters, description lacks return value and parameter context, making it incomplete for effective tool selection and 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 description adds no meaning to any of the 7 parameters, leaving agent uninformed about their purpose.
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 retrieves a trial balance for a period, similar to income statement. Distinguishes from siblings via combined free allowance mention.
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 cost guidance on combined free allowance with sibling tools, but lacks explicit directive on when to choose this tool over alternatives like get_account_balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_accountsBInspect
List 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description is relied upon. It discloses that no booking pass is needed and mentions free call limits, but does not state read-only nature, side effects, or authentication requirements beyond what parameters imply. Incomplete for a safe listing operation.
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 core purpose, and the second sentence adds valuable context about free tier and sibling differentiation. 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?
Missing critical information: parameter details, return format (no output schema), error conditions, authentication flow. Given 0% schema coverage and no annotations, the description is too sparse for an agent to use correctly without guessing.
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 has 5 parameters with 0% description coverage. The description does not explain any parameter (nonce, signature, timestamp, public_key, payment_header), leaving the agent without guidance on format, defaults, or semantics. Fails to compensate for missing 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 it lists accounts with currency constraints and booking method, and distinguishes from other tools by noting no booking pass involved. But does not fully differentiate from all sibling tools like list_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?
Provides explicit context about free calls and separate allowance, and directs to other tools for details, indicating when to use this tool vs alternatives. However, does not specify prerequisites or scenarios where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_directivesAInspect
List 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it lists raw directives, no booking, paid but with free first 2 calls, and that free calls are independent of other allowances. Lacks explanation of required auth parameters (public_key, nonce, etc.) and output behavior.
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. First sentence states purpose and filtering; second sentence adds key behavioral and pricing details. No filler, every sentence adds 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?
Tool has 9 parameters with no output schema or annotations. Description covers purpose, filtering, pricing, and free calls, but fails to explain the 4 required auth parameters or the output format. Could be more complete given the complexity.
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%, so description must compensate. It explains since/until format (ISO date strings) and implies account is optional filter. However, it does not describe limit, nonce, signature, timestamp, public_key, or payment_header, leaving 6 of 9 parameters undocumented.
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 'List raw directives (optionally filtered by account/date range)' with specific action and scope. It distinguishes from siblings by noting 'no booking involved' and calling it the 'cheapest paid tool', which no other sibling does.
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?
Indicates when to use via 'cheapest paid tool' and mentions free first 2 calls. Provides date format for since/until. Does not explicitly say when not to use, but cross-references list_accounts and get_balance_sheet for allowances, offering indirect guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
registerAInspect
Generate 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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses that the private key is returned once, never stored server-side, and unrecoverable, which is critical transparency for a key generation tool.
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 main action, followed by critical warning. Every sentence earns its place 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 zero-param tool with no output schema, the description covers the operation, key type, one-time return, irrecoverability, and domain independence. Complete for the complexity.
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 (0), so baseline 4. Description adds context about key type and separation from wallet keys, which is helpful but not parameter-specific.
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 generates a new Ed25519 keypair for ledger identity, returning the private key once. Distinguishes from wallet auth keys, making its purpose 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?
Explicitly notes this is separate from payment auth, implying when to use. Could be more direct about when not to use, but the context signals sibling tools are all different operations, so differentiation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_batchAInspect
Submit 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: atomic persistence, pricing (10x cost, always paid), cap of 1000 directives, and free-trial exclusion. Without annotations, this covers essential traits for decision-making.
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?
Description is moderately concise but includes pricing details that could be separated or placed in annotations. The information is front-loaded and relatively clear, though it could be more structured.
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?
Despite missing parameter details, the description covers the core functionality (atomic batch, pricing, restrictions). With no output schema, it explains enough for an agent to use the tool 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 description coverage is 0% and description adds no details about parameters (nonce, signature, public_key, directives, payment_header). Only 'directives' is implied; other parameters remain undefined, leaving the agent uninformed about their semantics.
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 explicitly states 'Submit up to 1000 directives atomically', clearly defining the verb, resource, and scope. It distinguishes from sibling submit_directive by highlighting atomicity and batch size.
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 clear context on when to use (batch submission with atomicity) and pricing caveats (10x single write, free trial inapplicable). Lacks explicit 'when not to use' but sufficiently guides selection via distinction from submit_directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_directiveAInspect
Submit 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the payment model, retry mechanism, and independent signing. However, it omits details on success/failure responses and potential 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?
The description is somewhat lengthy but well-structured: purpose first, then payment model, then retry flow. Could be slightly more concise without losing clarity.
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?
Lacks output schema and does not describe return values beyond hints of success or payment info. Missing details on rate limits or error handling, leaving gaps 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 0%, but the description explains payment_header's retry role and implies standard authentication parameters (nonce, timestamp, etc.). It adds some context but not detailed semantics for each parameter.
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 specifies submitting one Beancount directive (open, transaction, etc.) and explicitly contrasts with submit_batch, making the tool's purpose clear and differentiated.
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?
It provides step-by-step guidance: call without payment_header first to check free writes, then retry with payment_header if payment is needed. Also notes that submit_batch is always paid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_directiveAInspect
Free 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States the tool does not persist or charge, and explains that the signature requirement is for identity/replay protection. No annotations exist, so the description carries the load; it covers key behavioral aspects.
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 compact sentences that front-load the core purpose and add a critical caveat. No extraneous 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?
No output schema and no parameter descriptions mean the agent lacks guidance on return values and parameter semantics. For a tool with 5 required parameters, 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 coverage is 0%, and the description only mentions 'text' and 'valid signature' generally. It does not explain the other parameters (nonce, timestamp, public_key) beyond their names.
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 describes a dry-run validation that parses and books text against history without persisting or charging, distinguishing it from the sibling submit_directive.
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?
Implictly indicates use for testing directives safely, and specifies that a valid signature is required. Could be improved by explicitly stating when not to use or comparing with siblings.
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!