ezbookkeeping-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources/actions, with clear separation between list/get/manage. Minor overlap exists between list_tags and list_tag_groups, and between get_financial_summary/trends/reconciliation, but descriptions differentiate purposes.
Naming Consistency4/5
Follows a consistent snake_case verb_noun pattern (e.g., list_accounts, create_transaction), with some singular/plural inconsistency and the manage_* tools combining multiple operations. Overall predictable and readable.
Tool Count4/5
At 23 tools, this is on the heavy side but each tool maps to a distinct entity or operation in the bookkeeping domain. The breadth is justified by the variety of resources (accounts, categories, tags, templates, transactions, exchange rates) and features.
Completeness5/5
Provides comprehensive lifecycle coverage: CRUD for accounts, categories, tags, tab groups, templates, transactions, plus reporting, exchange rates, and batch operations. No obvious missing operations for the stated purpose.
Average 3.3/5 across 23 of 23 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions 'server-side statistics' without disclosing whether the operation is read-only, what data scope is included, timezone handling, or response behavior. The 'Return' wording suggests a read operation, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is concise, though slightly too terse given the complexity of the five-parameter schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 0% parameter coverage, the description carries the full burden of context. It gives the core purpose but lacks return value details, parameter semantics, and usage scenarios, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 five parameters. While start_time and end_time can be inferred from 'period', the purpose of keyword, ignore_case, and use_transaction_timezone is entirely unexplained, leaving the agent unable to populate them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and defines the scope ('period totals and category/account breakdown'), clearly distinguishing it from raw transaction search or trend analysis. It does not explicitly contrast with sibling tools like get_financial_trends, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_financial_trends or search_transactions. The description implies it is for period summaries but does not state exclusions, prerequisites, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the write-profile requirement but omits side effects, validation behavior, or consequences of creating a transaction (e.g., balance updates, duplicate handling). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and object. It is concise and wastes no words, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters, required fields, nested objects, and no output schema, yet the description covers only the basic purpose and a vague permission note. It does not guide the agent on required inputs, the relationship between source and destination amounts, or the expected response. The description is grossly inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 13 parameters. It merely echoes the type enum from the schema. The description adds no meaning beyond the structured schema, which is especially damaging given the complex nested objects and amount patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'transaction' and explicitly lists the four transaction types (income, expense, transfer, balance modification), which clearly distinguishes it from sibling tools like patch_transaction or delete_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as patch_transaction or apply_transaction_batch. It only mentions 'Requires standard write profile,' which is a permission note, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It names operations but does not disclose side effects (e.g., what delete or hide does), whether confirmation_token is required, differences between normal and scheduled templates, or response behavior. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the key actions. It is appropriately short for a tool whose schema is large, though it sacrifices depth. The sentence earns its place by stating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, enums, no output schema, no annotations), the description is severely incomplete. It only enumerates operations and omits critical context like the mode parameter (preview/apply), patch semantics, order reordering via orders, template_ref targeting, and confirmation_token. The description does not equip an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 parameter-level meaning. It mentions 'normal and scheduled' but does not explain key parameters like template, patch, orders, template_ref, mode, or confirmation_token. The description offers no compensation for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Create, update, hide, unhide, reorder or delete normal and scheduled transaction templates.' This precisely identifies the tool's scope and differentiates it from sibling list_templates, which is read-only. The enumeration of operations covers all the schema's operation enum values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. It does not mention that list_templates should be used for reading, nor does it describe prerequisites or context for operations like create vs update. The usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden for behavioral disclosure. It mentions the deletion permission/confirmation requirement, which is useful, but it does not disclose how Preview/Apply mode works, the role of confirmation_token, or side effects of hide/unhide/reorder operations. Significant behavioral ambiguity remains for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that efficiently lists all operations and the key deletion prerequisite. It avoids fluff and is easy to parse, though it could arguably include more detail without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex, multi-operation tool with seven parameters and deeply nested objects, yet the description only covers operation types and a single permission caveat. It omits critical context such as which parameters are needed for each operation, mode semantics, confirmation flow, and return behavior. The overall completeness is inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 seven parameters. The meanings of operation, mode, patch, orders, account, account_ref, and confirmation_token are entirely unclear from the description, leaving the complex nested schema as the only source of information. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies multiple account operations (create, update, hide, unhide, reorder, delete) with a clear verb+resource structure. It distinguishes this tool from sibling account-related tools like list_accounts and from tag/category management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one usage condition (deletion requires admin profile and Preview/Apply) but does not explicitly explain when to use this tool versus alternatives, nor does it state when not to use it. Usage context is implied by the tool name and operation list rather than explicitly spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It mentions that results include stable IDs, full tag data, editability, and a revision hash, which hints at read-only behavior and optimistic concurrency support. However, it does not disclose pagination behavior, default limits, filtering semantics, or any side effects. The provided context is minimal and does not fully characterize the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's purpose ('Search ezBookkeeping transactions') and then adds a concise, valuable detail about result contents. Every word earns its place, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 16 parameters and no output schema, this description is severely under-specified. It mentions only a few result fields and says nothing about pagination, default behavior, filtering logic, or response structure. For a complex search tool, this is far from a complete description and leaves the agent guessing about essential usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13% (only start_time and end_time have descriptions), so the tool description must compensate by explaining parameter meanings. It does not mention any of the 16 parameters, their filtering functions, or how they interact. The description adds no value beyond the schema's bare field names, leaving most parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource ('Search ezBookkeeping transactions'), and it distinguishes itself from sibling tools by indicating it returns multiple transactions with stable IDs and revision hashes, unlike get_transaction which fetches a single transaction. The addition of result specifics further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. There is no mention of using this before updating a transaction (despite the revision hash hint), nor any exclusions like 'use get_transaction for a single known ID'. The description implies a general search use case but does not provide comparative context with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It only discloses that delete uses Preview/Apply, omitting side effects, confirmation requirements, reversibility, and behavior for other operations. The mismatch between 'reorder' in the description and 'move' in the schema enum adds ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that wastes no words. However, the terminology inconsistency ('reorder' vs 'move') slightly reduces structure clarity, and the terse format could be improved with operation-specific details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 7 parameters, nested objects, multiple operations, and a preview/apply mode. The description fails to explain the meaning of mode, confirmation_token, orders, patch, or tag_ref, making it insufficient for correct invocation without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 7 parameters, and the description provides no parameter-level explanations. It does not describe tag, patch, orders, tag_ref, mode, or confirmation_token semantics, leaving the agent to infer everything from the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's actions: 'Create, update, hide, unhide, reorder or delete tags.' This is a specific verb+resource statement that distinguishes it from sibling tools like list_tags (listing) and manage_tag_group (group management).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The operation list implies usage for tag CRUD and reordering, but no explicit guidance is given about when to use this tool versus alternatives, nor does it explain the preview/apply flow for delete. The note 'Delete uses Preview/Apply' hints at a two-phase pattern but fails to clarify when preview vs apply should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions the output type but does not explain how parameters like time ranges, timezone handling, or filtering affect results, nor any limitations or side effects. The description is too sparse to convey behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the verb 'Return' and immediately specifies the scope. Perfectly concise for its simplicity, though it under-delivers on content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is far from complete. It does not explain key behaviors like time range handling, filtering, or timezone context, nor does it describe what the returned trends look like. The description is adequate for a trivial tool but insufficient for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only partially explains one parameter (kind) by linking 'income_expense' to monthly trends and 'assets' to daily trends. The remaining seven parameters (keyword, start_time, end_time, ignore_case, year_month variants, use_transaction_timezone) receive no explanation, leaving users with inadequate semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns financial trends, specifying two types: monthly income/expense trends and daily asset balance trends. This uses a specific verb ('Return') and resource ('financial trends'), and the granularity distinction differentiates it from sibling tools like get_financial_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, exclusions, or when to prefer other financial tools. The description is purely informative but lacks contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey all behavioral context, but it only mentions output content. It does not explain the effect of the include_hidden parameter, pagination, authentication needs, or whether hidden tags are included by default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is immediately informative and free of filler. It front-loads the key action and resource, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits critical information about the optional parameter and usage trade-offs. Given no output schema and no annotations, the description is too sparse to fully guide correct invocation, especially when distinguishing from list_tag_groups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the include_hidden parameter (0% coverage), and the tool description does not compensate by explaining what 'include_hidden' does. The parameter name gives some hint, but the description does not clarify whether 'all' includes hidden tags or whether a false value would hide them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'all transaction tags with group names,' specifying both the resource and the output detail. This differentiates it from sibling tools like list_tag_groups (which lists groups) and manage_tag (which manages tags).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_tag_groups or search_transactions. It simply states what it does, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It reveals that 'Delete uses Preview/Apply', but does not mention that other operations might also use preview/apply, nor does it explain side effects, permissions, or reversibility. The lack of detail about the preview/apply mechanism for non-delete operations is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key actions and adds a specific constraint about delete. It is concise and has no wasted words, though the extreme brevity contributes to the lack of parameter guidance. It earns its place but is slightly under-specified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, nested objects, 6 operations, no output schema, and no annotations, yet the description is only 16 words. It does not explain how operations map to parameters, what preview/apply means for each operation, what the response format is, or what the confirmation_token is for. This is wholly inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 compensate at all. It lists operations (create, update, hide, etc.) but never links them to the parameters (category, patch, orders, category_ref, mode, confirmation_token). For instance, it says 'reorder' but doesn't mention the 'orders' array. The description adds no semantic value beyond the schema's raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists the verbs 'Create, update, hide, unhide, reorder or delete' with the resource 'transaction categories', clearly distinguishing it from read-only siblings like list_categories. It also adds a specific note that 'Delete uses Preview/Apply', which further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by enumerating all category management operations. However, it does not explicitly state when to use this tool over alternatives (e.g., list_categories for viewing), nor does it explain when to use preview vs. apply mode beyond the delete case. This is clear context but lacks exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation by using 'Return' and specifies the data returned, but it does not disclose potential edge cases, formatting, or session context beyond that. This is acceptable for a read-only tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, front-loaded with the action and core resource. Every word contributes meaning, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide complete context. It gives a high-level summary but omits details about time range semantics, account object formats, and the structure of the returned statement. This is insufficient for a tool with three parameters and no structured return info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It mentions 'account' implicitly but does not explain the start_time and end_time parameters at all. The account parameter's flexible schema (string or object) is not addressed, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns account opening/closing balances and transaction running balances for reconciliation. This is a specific verb+resource combination that distinguishes it from siblings like get_financial_summary or get_financial_trends, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for reconciliation' implies the tool should be used when a reconciliation statement is needed, but there is no explicit guidance on when not to use it or which sibling to choose instead. The intended use is clear from context but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that delete uses a preview/apply workflow, which is useful, but it does not explain behavior for create/update/move operations, whether confirmation tokens are required, or any side effects or permissions. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that each add value. It efficiently communicates the core purpose and the delete preview/apply note. However, it is somewhat under-specified for the tool's complexity, which slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects) and the absence of both annotations and an output schema, the description is far from complete. It does not explain the preview/apply workflow for operations other than delete, how to reference groups, or what the tool returns. The description leaves substantial gaps for an agent to safely and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'operation' enum values in plain language (create, rename, reorder, delete) and hints at 'mode' via the preview/apply note. However, it does not explain 'group', 'patch', 'orders', 'group_ref', or 'confirmation_token', leaving many parameters with only schema-defined names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: create, rename, reorder, or delete a tag group. It identifies the resource (tag group) and provides specific operations, distinguishing it from siblings like list_tag_groups and manage_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for managing tag groups but does not explicitly state when to use this tool versus alternatives or any exclusions. The note 'Delete uses Preview/Apply' offers some operational guidance for the delete operation, but the overall context of when to prefer this tool is not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'with a revision hash', which hints at additional behavior (possibly returning a hash for optimistic concurrency), but it doesn't disclose what the revision hash is for, whether the transaction is returned in full, what happens if the ID is invalid, or any error behavior. For a read tool, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, eight words, front-loaded with verb and resource. Zero waste. Perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description is minimally adequate: it identifies the operation and a distinctive detail (revision hash). However, it could add context on the revision hash's purpose and possibly differentiate from search_transactions. Given the tool's simplicity, a 3 is fair – it's not incomplete to a dangerous degree, but leaves some behavioral mystery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but there is only one parameter ('transaction_id') with a clear name and minLength. The description adds the concept of 'revision hash', which is relevant to the response, not the parameter. Since there's only one simple param, the description does not need to say much, but it doesn't clarify the expected format of the ID (e.g., UUID, numeric). Still, the name is self-explanatory, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') with a single resource ('one transaction by ID') and adds the detail 'with a revision hash'. It distinguishes from sibling 'search_transactions' (which would find multiple) and 'list_accounts' (different resource). However, it could more explicitly contrast with 'search_transactions' to fully close the gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context suggests this is for retrieving a single transaction when the ID is known, whereas 'search_transactions' is for broader queries. However, the description doesn't explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or typical scenarios. It provides minimal guidance beyond the obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'trees' hinting at hierarchical output, but fails to explain that the 'type' parameter is optional, what happens when omitted, or how 'include_hidden' affects results. No return format, permissions, or side-effect information is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the core purpose efficiently and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description lacks important behavioral details such as the optionality of the 'type' filter, the default behavior of 'include_hidden' (which defaults to true), and the structure or content of the returned trees. Without these, the description is adequate but incomplete for an agent to fully predict behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. The parameter names 'type' and 'include_hidden' are somewhat self-explanatory, but the description does not clarify that 'type' filters the tree or that 'include_hidden' controls hidden categories, leaving the agent to infer their semantics from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List income, expense and transfer category trees' clearly states the action (list) and the resource (category trees), and distinguishes it from sibling tools like list_accounts and list_tags. It also specifies the category types covered, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to retrieve category trees. However, it does not explicitly state when to use this tool versus alternatives (e.g., list_tags or manage_category), nor does it mention optionality or filtering behavior. The usage context is inferred from the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only repeats the action 'list' without revealing behaviors such as return format, ordering, or whether it includes inactive groups. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is appropriately concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides only the core action and resource. It is adequate for a very simple list tool but lacks information about return structure or distinctions from similar list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List transaction tag groups' states a clear verb and resource. It distinguishes from sibling tools like list_tags by specifying 'tag groups', though it does not explicitly contrast against siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's purpose but provides no explicit guidance on when to use it versus alternatives like list_tags or manage_tag_group. It is minimally useful but lacks clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must signal behavior. 'Preview' and 'signed confirmation token' imply a non-mutating operation that returns a credential for later use, but the description does not explicitly state that no changes are applied, token expiration, or that the token is required by apply_transaction_batch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core action. The phrase 'one batch category, tag or account update' is slightly awkward but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a large nested schema, no output schema, and no annotations, one sentence is insufficient for an agent to invoke this tool correctly. The description omits how the selector filters transactions, what operations are available, and how the returned token is consumed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only vaguely mentions 'category, tag or account update'. It does not explain the selector object, the six operation variants, or how the two required parameters relate. This adds minimal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Preview') and resource ('batch transaction update'), and mentions the signed confirmation token output. This clearly distinguishes it from the sibling tool apply_transaction_batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a pre-apply verification step by saying 'Preview' and returning a token, but it never explicitly states 'use before apply_transaction_batch' or provides when-not-to-use guidance. The sibling apply tool is an obvious alternative but is not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the scope ('all accounts and subaccounts') and output fields, but omits details about the include_hidden parameter, permissions, or side effects. This leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word adds value, and there is no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple list operation, but it omits the include_hidden parameter behavior and any potential pagination or filtering context. The presence of the parameter suggests additional nuance that is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% for the include_hidden parameter, and the description does not mention it at all. The parameter name and default value in the schema provide some meaning, but the description fails to clarify when to use it or what 'hidden' refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource as 'all accounts and subaccounts'. It specifies the return fields (IDs, balances, hierarchy paths), which distinguishes it from sibling tools like list_tags or get_financial_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage by naming the exact resource and operation, but it does not explicitly state when to use this tool versus alternatives like get_financial_summary or manage_account. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that extended write profile is required, which is a behavioral trait. However, it does not reveal side effects (e.g., whether delete reverts to system rate, whether setting overrides existing rate) or any irreversible consequences. This is basic but incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by a necessary permission note. There is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain effects or return values, but it doesn't. It also omits context on how custom rates interact with system rates or user-specific behavior. It is minimally adequate but lacks important context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'set or delete' (reflecting the operation parameter) but provides no explanation of what 'rate' should look like or what 'currency' refers to. The schema's maxLength/minLength for currency is present, but the description adds no semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set or delete a user custom exchange rate.' It uses a specific verb ('set'/'delete') and resource ('custom exchange rate'), and this distinguishes it from sibling tools like get_exchange_rates, which is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting or deleting a custom rate, but it doesn't explicitly compare to alternatives or state when to use this vs. other rate-related tools. The mention of 'Requires extended write profile' provides a prerequisite, which is useful but not sufficient for clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must compensate. It only conveys the basic action without disclosing default behavior when template_type is omitted, return format, ordering, or pagination, leaving significant behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value, making it highly concise for a tool with one simple parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no annotations, no output schema), the description is minimally adequate. It covers the core action but omits details about default behavior and output structure, which are expected for a complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's 'normal or scheduled' maps to the enum values 'normal' and 'schedule', providing partial semantic context. However, it is ambiguous whether the parameter filters or both types are listed by default, and it does not explicitly reference the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 (transaction templates), and distinguishes between 'normal or scheduled' templates, which differentiates it from sibling tools like list_accounts, list_tags, and manage_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving templates, optionally filtered by type. It provides clear context but does not explicitly exclude use cases or mention manage_template for modifications, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds a useful behavioral note: 'Every target revision is checked again before writing.' This discloses a safety check, but it doesn't mention side effects, permission requirements, idempotency, or error handling. The description adds some value but leaves significant behavioral aspects unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, focused sentences. The first states the purpose, the second adds a behavioral detail. There is no filler or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is minimally viable. It explains the core action and a safety check, but lacks information about the expected response, the source of the confirmation token, and the relationship to preview_transaction_batch. This leaves gaps for an agent trying to use the tool correctly in a composite workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lone parameter 'confirmation_token'. The description says 'previously previewed', which hints that the token comes from a preview, but it doesn't explicitly say to use the token returned by preview_transaction_batch or explain its role beyond being a confirmation. This added meaning is minimal and insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Apply a previously previewed batch operation.' The verb 'apply' is distinct from 'preview' in the sibling tool preview_transaction_batch, and the resource is the batch operation. This makes the purpose unambiguous and differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use the tool: after a batch operation has been previewed. This sets a clear prerequisite without explicitly naming alternatives. It doesn't state when not to use it or compare to individual transaction tools like patch_transaction, but the context is sufficient for a simple confirmation step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that apply mode is destructive and requires a confirmation token, which is key behavioral context. However, it does not explain what preview returns, whether deletions are reversible, or what side effects occur, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence states the action and scope; second sentence adds a critical conditional requirement. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two modes and a token requirement, but no output schema and no annotations. The description covers the essentials but omits return values, how to obtain the confirmation token, and error behavior. For an agent to use it safely, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for confirmation_token by explaining it is required for apply mode, but does not explain how to obtain it. transaction_id and mode are left to be inferred from names and the enum, which is acceptable but not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('preview or apply deletion') and specifies the resource ('one transaction'), which distinguishes it from batch siblings like preview_transaction_batch and apply_transaction_batch. The two modes are explicitly named, and the token requirement adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for single-transaction deletions, and the two modes (preview vs apply) indicate when to use each. However, it does not explicitly mention alternatives (e.g., using batch tools for multiple transactions) or provide exclusionary guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses two key behaviors: it only updates selected fields (preserving unspecified ones) and uses expected_revision for optimistic concurrency control. However, it does not detail error handling, side effects, or return value, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the essential purpose and the critical usage instruction. Every word earns its place; no redundant filler. The structure is front-loaded with the primary function and then the key prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested patch object with many subfields, no output schema, and no annotations. The description is too short to adequately guide an agent on constructing the patch correctly, especially the semantics of tag operations and other optional fields. It covers the core idea but is under-specified for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the purpose and source of expected_revision, but does not explain transaction_id or the structure of the patch object, especially ambiguous nested fields like tags_add vs tags_set vs tags_remove. The parameter names in the schema provide some meaning, but the description adds minimal value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'safely update selected transaction fields while preserving all unspecified fields', which is a specific verb ('update') plus resource ('transaction') with a clear scope (partial update). It distinguishes itself from create/delete tools and clearly indicates patch semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to supply expected_revision from get/search to prevent lost updates, providing clear context on when and how to use the tool. It implies the prerequisite of fetching the transaction first, but does not explicitly name alternatives or exclusion conditions (e.g., 'do not use for creation'), despite the context being strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It tells us the tool returns combined upstream and custom rates, which is useful context. However, it does not explicitly state whether this is a read-only operation (though 'Return' suggests it), whether it makes external network calls, or how it handles failures. This is a partial disclosure but lacks explicit reassurance about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence: 'Return latest upstream and user-custom exchange rates.' It is front-loaded with the verb and object, and every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a zero-parameter getter, the description covers the main purpose. It does not specify the output format (e.g., whether results are keyed by currency or array of objects), and there's no output schema to fill the gap. Still, it is sufficient for most use cases, so a small deduction for lack of return structure detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is trivially 100%. With no parameters to describe, the baseline of 4 applies. The description adds nothing extra about parameters because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and identifies the resource as 'exchange rates', further clarifying it returns both 'upstream and user-custom' rates. This distinguishes it from sibling 'manage_custom_exchange_rate' which modifies rates rather than returning them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve exchange rates, but provides no explicit guidance on when to choose this over alternatives like 'manage_custom_exchange_rate' or how it relates to other financial data tools. There is no mention of any conditions or exclusions, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. The verb 'Return' implies a read-only operation, but it does not elaborate on whether any state changes, network calls, or authentication are involved. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and clearly enumerates the outputs. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, no output schema, and 0 parameters, the description fully specifies what is returned. It is complete and sufficient for an agent to understand the tool's purpose and expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, and the description naturally adds no parameter details. With 0 parameters and 100% schema coverage, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning upstream version information and enabled MCP write capabilities. This is specific and distinguishes it from sibling data retrieval tools like list_accounts or search_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided, but the tool's unique scope (server information) makes its use self-evident. It does not mention alternatives or exclusions, but for a 0-parameter informational tool, this is acceptable minicipal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ezbookkeeping-mcp-server MCP server](https://glama.ai/mcp/servers/abco20/ezbookkeeping-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/abco20/ezbookkeeping-mcp-server)

Score Badge

Copy to your README.md:

[![ezbookkeeping-mcp-server MCP server](https://glama.ai/mcp/servers/abco20/ezbookkeeping-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/abco20/ezbookkeeping-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/abco20/ezbookkeeping-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server