Banana Accounting MCP Server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools have clearly distinct purposes, such as table vs. rowlist operations and various financial figures. However, there are some overlapping utilities like banana_infos, banana_info_table, and banana_info_value, which could cause confusion. Overall, descriptions help clarify boundaries.
Naming Consistency5/5All tool names start with the 'banana_' prefix and use underscores consistently. The naming follows a resource-oriented hierarchy (e.g., banana_vat_balance, banana_table_rowcount), making it predictable and easy to navigate.
Tool Count2/5With 53 tools, the server is heavily over the typical range for an MCP server. While the accounting domain is broad, many tools are highly specialized or could be consolidated, and the count feels excessive for most use cases.
Completeness4/5The server provides comprehensive read access to accounting data, including tables, financial figures, reports, and documents, plus document creation. Minor gaps exist, such as lacking update/delete operations for accounting data (aside from appdata) and some discovery endpoints, but these are acceptable for a read-heavy API.
Average 3.8/5 across 53 of 53 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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.jsonto 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?
Annotations include readOnlyHint=true, confirming read-only operation, but the description adds no further behavioral detail. It does not explain how the interest is calculated, how the period or rate affect the result, or what output format to expect. No contradiction exists, but no value is added beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded, with no filler or redundant information. It earns its place by clearly stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not describe the return value's format or behavior, such as whether it returns a single number, a table, or how it handles multiple accounts. This lack of context makes the tool underspecified for an agent to fully understand what it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all six parameters, so the baseline of 3 applies. The tool description adds no extra meaning to the parameters, but the schema already documents each parameter's purpose and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the resource ('calculated interest on an account/group/class for budget transactions'), which distinguishes it from siblings like banana_interest or banana_budget. However, it does not explicitly name alternative tools or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as banana_interest for actual transactions. The description only states what it does, leaving the agent to infer usage context from the name and sibling list.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds no additional behavioral context, such as return format, error behavior, or side effects. The statement 'Requires projectionstart' is redundant with the schema's required field list, providing no new behavioral insight beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, followed by the key requirement. There is no wasted wording, and it is appropriately sized for a simple read operation with comprehensive schema documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 7 parameters, 3 required, and no output schema. The description does not explain the return value's structure or any behavior beyond the basic action, which is a significant gap. With no output schema, the description should provide more context about what the figure represents or how it is calculated, but it remains minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema: it mentions 'VAT code or VAT group', which is already detailed in the vat_code property. It does not elaborate on the meaning of 'projectionstart' or the 'type' parameter, leaving the schema to carry the burden, which it does adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'projection VAT figure' for a VAT code or group, which is a specific verb-resource pair. It distinguishes itself from siblings like banana_vat_balance and banana_vat_budget by focusing on 'projection', though it could more explicitly differentiate from the generic banana_projection tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions that 'projectionstart' is required, which is a prerequisite, not a usage guideline. It provides no guidance on when to use this tool versus alternatives like banana_vat_balance or banana_projection, nor any scenarios where it is preferred. No exclusions or alternatives are mentioned.
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?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds only 'Defaults to JSON,' which is also present in the format parameter's schema description. It does not disclose what the report contains, how periods are filtered, or any other behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the core purpose immediately. While minimal, it is appropriately sized for the information it conveys, consistent with high-scoring concise examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should compensate by explaining what the VAT report returns or how to interpret the output. It does not, and it also lacks guidance on parameter combinations or limitations. Given the tool's moderate complexity (6 optional parameters), this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters have descriptions in the schema, achieving 100% coverage. The description itself does not add any parameter semantics beyond stating the default JSON format, which is already documented. Thus the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'the VAT report for a document.' It is clear but does not explicitly differentiate from sibling VAT tools such as banana_vat_balance or banana_vat_projection, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It simply states what it does without context, exclusions, or preferred scenarios. This is a significant gap given the many related VAT tools in the sibling list.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that it defaults to JSON and clarifies the output as 'budget transactions', but does not disclose other behavioral traits such as document prerequisites 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the key action and scope. It is efficient and contains no redundant information beyond what is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 many sibling card/budget tools, the description is too sparse. It does not define what a 'budget card' is, what the response looks like, or when to prefer this over banana_budget, leaving important gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all 8 parameters, so the description adds little beyond the schema. The only addition, 'Defaults to JSON', is already present in the format parameter's schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Return'), resource ('budget card (budget transactions)'), and scope ('for an account'). It distinguishes from sibling tools by using 'budget card', though the overlap with banana_budget is not explicitly addressed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like banana_budget or banana_account_card. It does not mention when-not-to-use or provide any context for selection among sibling tools.
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?
Annotations declare readOnlyHint=true, so the read-only nature is already known. The description adds minimal context: it requires projectionstart and defaults to JSON. However, it does not explain what the projection card contains or any side behaviors, but given annotation coverage, this is acceptable baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences: the first states the purpose, the second adds a key requirement and default. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 9-parameter tool with no output schema and rich sibling context. The description is too brief to explain what a 'projection card' represents, how it relates to other card/projection tools, or what the response looks like. The complete parameter documentation in the schema only partially compensates for the lack of behavioral and return context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters have descriptions. The tool description only reiterates the required parameter (projectionstart) and the default format (JSON), both already present in the schema. No additional semantic value is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Return the projection card for an account.' This clearly identifies the tool's function and resource. While it doesn't explicitly differentiate from sibling tools like banana_account_card or banana_projection, the name and title make 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as banana_projection or banana_account_card. The only usage hint is 'Requires projectionstart,' which is a prerequisite, not a usage guideline.
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?
The description adds useful behavioral context beyond annotations: 'The data is sent as the request body' and the accepted payload types. Annotations already signal a write operation (readOnlyHint=false), so the description doesn't need to restate that. However, it does not disclose important behaviors such as whether existing data under the same id is overwritten, or any authentication/rate-limit considerations, leaving gaps that annotations do not fill.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, consisting of two short sentences that are front-loaded with the core purpose ('Save web-app data under a data id') and then provide the necessary payload format details. Every sentence adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description adequately covers the basic purpose and payload types. However, it lacks information about behavior such as overwrite semantics, return values, or error conditions, which would be especially important since no output schema exists and annotations do not provide destructive hints. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The schema already describes both parameters: 'data_id' as a key and 'data' as the payload. The description adds minimal extra value, mainly clarifying that the data is sent as the request body, which is not explicitly in the schema but is a minor transport detail. No significant additional semantic meaning is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Save web-app data under a data id.' This clearly communicates the action and distinguishes it from retrieval (get) and deletion (delete) tools. However, it does not explicitly differentiate from the sibling tool 'banana_appdata_form', relying on the tool name and implied semantics rather than an explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as 'banana_appdata_get' or 'banana_appdata_delete'. The description only explains how to format the data ('Provide a JSON object/array... or a raw string'), not when to choose this tool. This is effectively no usage guidance, as the 'save' purpose is implied but not contrasted with siblings.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds the default JSON format, which is useful, but provides no additional behavior details such as output structure or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. Every word contributes to conveying the core function and default format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema/annotations cover much of the context. However, the description does not clarify what exactly the 'file info table' contains or when this tool is preferable to related info tools, leaving some gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter has a descriptive comment. The description's 'Defaults to JSON' merely restates what the format parameter already explains, so it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Return the file info table for a document.' This is clear and indicates the tool's scope, though it does not explicitly differentiate from the related sibling 'banana_info_value' beyond the word 'table'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like banana_info_value or banana_infos. The 'Defaults to JSON' note hints at format but not at selection criteria or exclusions.
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?
The readOnlyHint annotation already indicates a safe read operation, and the description adds the behavioral detail that the result is returned as text. However, it does not disclose potential edge cases such as behavior when the rowlist does not exist or whether the operation could be slow. Given the annotation coverage, the additional context is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the verb, resource, and output format. It contains no filler or redundancy, making it exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only row count tool, the description is adequate but not complete. It lacks guidance on how to discover rowlist names (e.g., via banana_rowlist_names) and does not mention error handling. With no output schema, the explicit 'as text' return detail helps, but the tool remains minimally specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions (100% coverage) for all three parameters doc, table, and rowlist, so the description does not need to add parameter details. The description offers no extra semantics beyond what the schema already supplies, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the number of rows in a named row list of a table, using the specific verb 'Return' and resource 'named row list of a table'. It is unambiguous and distinctly different from sibling tools like banana_table_rowcount, though it does not explicitly call out the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as banana_table_rowcount or banana_rowlist_names. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name and schema alone.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description aligns with this by saying 'Return'. However, the description adds no extra behavioral context beyond the annotations, such as what happens if the data id is missing or how the data is returned. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately communicates the action, resource, and key parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with readOnlyHint, the description plus schema is largely sufficient. It lacks explicit notes about error behavior or the exact nature of 'app data', but the sibling tool names and annotations provide enough context for this straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes data_id with 100% coverage, including an example ('chart_xyz'). The description's phrase 'given data id' adds no new meaning beyond the schema, so the schema does the heavy lifting and baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies the resource ('stored web-app data') and the key input ('data id'). It clearly states what the tool does, but it does not explicitly contrast with sibling tools like banana_appdata_put or banana_appdata_delete, so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool vs. the related appdata tools (put/delete/form), no prerequisites, and no alternatives. The agent must infer usage from the tool name and description alone.
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?
Annotations already indicate readOnlyHint and openWorldHint, covering safety and scope. The description adds minimal behavioral context by noting the result is returned 'as text', but does not elaborate on error behavior or edge cases. With annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the purpose and output format without unnecessary words. It is well-structured and immediately readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only count tool, the description combined with schema and annotations provides sufficient context. The schema explains parameters, annotations confirm non-destructive behavior, and the description indicates the return format. It lacks details on error handling, but this is a minor gap for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, with both 'doc' and 'table' explained. The description adds no additional parameter semantics, so the baseline score of 3 applies as the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('Return') and resource ('number of rows in a table'), and specifies the output format as text. However, it does not explicitly differentiate from sibling tools like banana_rowlist_rowcount, though the 'table' context provides implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 banana_table or banana_rowlist_rowcount. It simply describes the action without any context or exclusions, leaving the agent to infer usage from the name.
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?
Annotations already declare readOnlyHint=true, and the description's verb 'Return' aligns with this. However, the description adds no additional behavioral context, such as how period/filter parameters affect the returned figure or that the tool is read-only. This is consistent with the annotations, so no contradiction, but the value added is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. It contains no superfluous words or redundant information, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters (including a multi-enum 'type' and filter/period/frequency modifiers) and no output schema, the description is too terse. It does not explain how the parameters interact, what the returned 'budget VAT figure' represents, or what format the result takes. This is a minimal but under-specified description for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no parameter-specific details beyond what the schema already provides. The baseline of 3 applies because the schema fully documents each parameter, including enums and examples, so the description is not required to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a specific resource ('budget VAT figure') scoped to 'VAT code or VAT group.' This clearly distinguishes it from sibling tools like banana_vat_balance (VAT balance) and banana_vat_projection (VAT projection) by the 'budget' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as banana_vat_balance or banana_budget. It does not state exclusions, prerequisites, or typical scenarios. The only implicit usage is that it returns budget VAT figures, but no comparison or selection criteria are 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?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the return format (JSON array of {id, descr}) and an example, which is useful but does not provide further behavioral context like pagination or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the output format and includes a concrete example. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and good annotations, the description fully explains the return value and format. It lacks usage guidance, but the core functionality is well-specified and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'doc' parameter, so the schema already explains its meaning. The description adds no additional parameter semantics, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of VAT codes with a specific JSON structure, which is a specific verb+resource. It differentiates from sibling tools like banana_vat_description by indicating it lists all codes rather than describing a single one, though it doesn't 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as banana_vat_description or banana_vat_balance. The description only states what it does, leaving the agent to infer usage from its name and sibling 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read nature is covered. The description adds no significant behavioral disclosures beyond what annotations and schema provide, such as default output format (already in schema) or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with the purpose front-loaded, making it easy to scan. 'Defaults to JSON' is slightly redundant with the schema but not harmful; overall it is concise and structured well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With all seven parameters fully documented in the schema and safe-read annotations, the description provides adequate high-level context for a report tool. It defines the return value (accounting report) and available modes, though it does not detail output shape or edge cases, which is acceptable given schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description need not repeat parameter details. It names several parameter families (view, columns, navigation, period, subdivision) but adds no meaning beyond the schema's full descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an 'accounting report (enhanced balance sheet / P&L) for a document', with a specific verb and resource. It distinguishes itself from siblings like banana_balance by calling out 'enhanced balance sheet / P&L', 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving an accounting report and mentions supported options (view, columns, navigation, period, subdivision), giving some usage context. However, it does not state when to use this over sibling reporting tools or provide any exclusions or alternative guidance.
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?
The description adds the important behavior of how positive/negative rates affect debit vs credit amounts, which goes beyond the readOnlyHint annotation. This gives the agent operational insight without contradicting the readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly conveys the core function without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has 6 parameters including period, frequency, and filter, the description doesn't explain how these interact with the calculation. The sign convention is helpful, but the overall behavior is not fully specified for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all 6 parameters with examples (e.g., account selector syntax, rate format), so the description doesn't need to add param details. The description minimally references account/group/class, which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Return the calculated interest on an account/group/class' with a specific verb and resource, making the primary function clear. However, it doesn't distinguish from similar tools like banana_budget_interest, so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description gives a calculation rule but no context about prerequisites, selection criteria, or exclusions.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the behavioral default 'Defaults to JSON,' which is useful. However, it does not mention any other behavioral traits (e.g., response size, pagination, or error conditions). With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Return the content of a named row list within a table. Defaults to JSON.' It is front-loaded with the core action and object, and every word serves a purpose. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 7 parameters and no output schema, the description provides the essential purpose but lacks context about the response structure (beyond JSON default) and how to apply the parameters. The rich schema compensates, but the description could be more complete for an agent deciding to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 7 parameters, so the description does not need to add parameter details. The description itself adds no extra meaning beyond the schema, which is the expected baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return the content of a named row list within a table.' This uses a specific verb and resource, distinguishing it from siblings like banana_rowlist_cell (single cell) and banana_table (full table). Adding 'Defaults to JSON' provides extra clarity about the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or contrast with the many sibling tools (e.g., banana_rowlist_names, banana_rowlist_cell). The agent is left to infer usage 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?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds 'Defaults to JSON,' but this is redundant with the schema's format parameter description. The pipe-separated support is also already documented in the vat_code parameter. No additional behavioral context (e.g., return structure, authorization) is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently states the action, resource, and a key usage example. This is an excellent model of conciseness, even if it sacrifices depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description is quite minimal. The schema covers parameters and annotations cover safety, but the description does not explain what an 'account card' contains or what the response looks like. For a simple read-only tool, this is minimally viable but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description does not add new meaning beyond what the schema provides; it merely repeats the multiple-vat-code example already in the vat_code parameter description. Thus it neither improves nor harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return the account card for a VAT code.' It uses a specific verb and resource, and the pipe-separated example ('V0|V80') clarifies multiple-code handling. This distinguishes it from sibling tools like banana_vat_balance or banana_vat_description, which serve different VAT-related purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—use this tool when you need a VAT code card—but it provides no explicit when-to-use guidance or mention of alternatives. There are no exclusions or scenarios where another tool would be preferred, leaving the agent to infer usage from the purpose alone.
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?
Annotations already indicate readOnlyHint and openWorldHint, and the description confirms a read-only operation by stating it returns data. It adds the output structure, but doesn't disclose potential edge cases, pagination, or error 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly front-loaded with the action and result. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description adequately specifies the return format. It could mention that it returns all segments or clarify the context of 'segments', but given sibling tools and annotations, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with a complete description of 'doc'. The description adds no additional parameter information, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Return') and resource ('list of segments'), specifying the output format as JSON array of {id, descr} objects. This clearly distinguishes from sibling tools like banana_groups and banana_vatcodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling list tools. It doesn't mention prerequisites, selection criteria, or alternatives.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds useful context like 'Defaults to JSON' and output format options, but does not disclose potential limitations (e.g., pagination, error behavior, or response structure), which would be valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clean sentences: the first states the primary action, the second covers defaults and capabilities. It is front-loaded, succinct, and every clause adds value without unnecessary waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of read-only annotations, the description covers the essential behavior well. It could optionally mention return value structure or limitations, but the core context is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters already have descriptive explanations. The description reinforces the meaning of 'format', 'view', and 'columns' but does not add new syntax or behavioral details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's core function with a specific verb and resource: 'Return the content of a table in a document.' It doesn't explicitly differentiate from siblings like banana_cell or banana_rowlist, but the name and description make its role clear as the general table reader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the mention of defaults (JSON) and configurable options (view, columns, output format), but there are no explicit 'when to use' or alternative comparisons. The description lacks exclusionary guidance for when to prefer banana_table over similar read tools.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the single-cell scoping and the identification mechanism, but does not disclose error behavior, return value format, or other operational nuances. This is acceptable given the low bar set by annotations, but not additive beyond the basics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the action and key inputs. No filler or redundant phrasing is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only cell-access tool with fully described parameters and safe annotations, the description is complete enough. It accurately conveys what the tool does without needing to explain return values in depth, as the column type inherently determines the returned value's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with each parameter already explained in detail. The description simply reiterates 'table, row selector, and column XML name' without adding any new semantic meaning or contextual details about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('value of a single cell'), and identifies the distinguishing parameters (table, row selector, column XML name). This clearly differentiates it from sibling tools like banana_rowlist_cell, which operate on rowlists rather than arbitrary tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention exclusions, prerequisites, or related tools such as banana_rowlist_cell or banana_table, leaving the usage context implicit.
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?
Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds 'Requires projectionstart' and 'Supports period, frequency and filter,' but these are mostly parameter capabilities rather than deeper behavioral traits like return format or edge cases. Given the annotation coverage, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action ('Return the projection figure...'). It includes key requirements and supported options with no unnecessary words, earning a perfect score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers all parameters in detail, there is no output schema and the description does not explain what the returned figure looks like or how it behaves in edge cases. For a tool with 7 parameters and domain-specific concepts like 'projectionstart', the description is minimal but not fully inadequate, as it does highlight required and supported parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only repeats parameter names ('projectionstart', 'period', 'frequency', 'filter') without adding syntax, formatting, or relationships beyond the schema. It does not compensate for any gaps because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a projection figure for an account, group, or balance class, using a specific verb and resource. This distinguishes it from siblings like banana_balance (balance) and banana_budget (budget). The mention of 'Requires projectionstart' further specifies the tool's unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for projection figures but does not explicitly state when to use this tool versus alternatives like banana_balance or banana_vat_projection. No exclusions or alternative tool names are provided, so the guidance is only implicit.
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?
Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds that the file defines an object-oriented interface, which describes the file content rather than tool behavior. It does not disclose potential edge cases such as whether the document must be open or what happens if an invalid document name is provided, but the annotation diminishes the need for safety disclosures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that clearly explains what is returned and why. It is appropriately sized with no filler or redundant details, and the key verb 'Return' is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with good annotations, the description adequately explains the return value and the intended input context. However, since there is no output schema, it might have elaborated on the response format or error behavior, but the current wording is sufficient for most use cases. Minor gap but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 100%, with the doc parameter description already explaining its meaning and default behavior. The tool description simply says 'for a given document', adding no new semantic information beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a specific resource (the bananaapiv2.js JavaScript file) and explains its purpose (defines an object-oriented interface to the web server). This is a specific verb+resource pair that distinguishes it from sibling tools, which mostly handle data operations rather than returning API files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving the API file for a given document, but it does not explicitly state when to use this tool instead of alternatives or mention any exclusions. No alternative tools are referenced, leaving the user to infer appropriate usage from the tool's purpose.
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?
Annotations already declare readOnlyHint=false, so the description adds minimal context about the destructive nature. It describes what is deleted ('stored web-app data') but does not mention irreversibility, permissions, or side effects. Given the annotations, this is acceptable but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded, with no wasted words. It effectively communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description is adequate. It states the action and target, and combined with annotations, the tool's behavior is sufficiently understood. It does not explain return values or error cases, but the simplicity keeps this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage for the only parameter, 'data_id', with an example ('chart_xyz'). The description echoes this without adding new meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('stored web-app data') for a given data id. It distinguishes from sibling tools like banana_appdata_get or banana_appdata_put by specifying the deletion operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by identifying the target (data id) but does not explicitly state when to use this tool versus alternatives like banana_appdata_put or banana_appdata_form. It lacks clear context or exclusionary guidance, leaving usage to be inferred.
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?
Annotations already declare readOnlyHint and openWorldHint, so the read-only nature is known. The description adds the return format and the notion of period abbreviations, but it does not disclose behavior for invalid periods, missing docs, or how 'accounting' is resolved. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, the output format, and the input scope efficiently, earning its place without repeating annotation or schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with well-documented parameters and readOnlyHint, the description is nearly complete. Minor ambiguity remains about the phrase 'of the accounting' — it likely means the accounting period but is not explicitly stated, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with 100% coverage, including a default mechanism for doc and an example for period. The description only reinforces the idea of a 'period abbreviation' without adding meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return'), names the resource ('end date'), and specifies the output format (YYYY-MM-DD). It clearly distinguishes from the sibling tool banana_start_period by focusing on the end date, and scopes the input to an accounting period or period abbreviation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing the closing date of an accounting period or abbreviation, but it gives no explicit guidance on when to prefer this tool over alternatives such as banana_start_period. No exclusions or alternative tool names are mentioned.
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?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds the endpoint path and an example but does not disclose behavior for missing files, size limits, or content types. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and resource, includes the API path and an example, and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with strong annotations and no output schema, the description is adequate: it states the resource, path, and example. Edge cases like missing files are not covered, but the tool's simplicity lowers that requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter with a clear description, so the description does not need to add much. It adds the path pattern and an example filename, but this is marginal beyond schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'a file stored in Banana's user data folder', including the API path '/v2/files/{file_name}' and a concrete example 'httpconfig.ini'. This clearly distinguishes it from sibling tools that operate on tables, cells, or accounting data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading a file from the user data folder, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions. Sibling tools like banana_appdata_get exist, but no comparative guidance is given.
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?
Annotations already declare readOnlyHint true and openWorldHint true, so the description does not need to cover safety or return variability. It adds the behavioral detail that the value is addressed by section and id, which is useful but not extensive. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the action and includes a clarifying example. It is front-loaded and free of filler, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with fully documented parameters, the description sufficiently covers the main purpose. It does not describe the return format, but openWorldHint indicates arbitrary return types, reducing the need for that detail. The tool is simple enough that this description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover 100% of the parameters with meaningful explanations and examples. The tool description only repeats the example, adding no new semantic value beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return a single file-info value' with a specific addressing mechanism via section and id names. It provides concrete examples for both parameters, making the tool's function unmistakable and distinct from sibling tools like banana_infos or banana_info_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving one specific info value by section and id, but does not explicitly contrast it with alternatives such as banana_infos (which likely returns multiple). The phrase 'single' hints at the use case, but there is no explicit when-to-use or when-not-to-use guidance.
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?
The readOnlyHint annotation already covers the safety profile. The description adds that it returns 'all transactions in chronological/posting order' and defaults to JSON, which is useful but minimal. It does not explain pagination, filtering options, or output structure beyond the raw journal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and scope. No redundant fluff; every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only report tool with no required params and full schema coverage, the description is adequate. It conveys the fundamental behavior and default format. It lacks explicit mention of output shape, but that is less critical given the simplicity and read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 4 parameters, so the description need not add much. The description does mention default JSON format, which echoes the schema, but does not provide additional meaning beyond schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('journal'), and clarifies that it includes all transactions in chronological/posting order. This clearly distinguishes it from sibling tools that focus on balances, accounts, or specific table views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context implies use for retrieving the full transaction journal of a document, but it does not explicitly mention alternatives or when not to use it. Sibling tool names suggest there are other report tools, but no exclusions or comparisons are 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to repeat safety. It adds no additional behavioral details beyond the read-only return of a value, and does not mention potential edge cases (e.g., row not found). This is minimally adequate given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the core action ('Return the value') and includes all necessary scoping in a clear order. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only cell retrieval tool with no output schema, the description is complete enough. It specifies the identification components and the result ('value'), and the schema covers parameter details. Slightly more context about return type or error behavior could be added, but it is not necessary given the simple nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description does not add meaning beyond restating the parameter roles. Baseline 3 is appropriate when the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Return the value of a single cell within a named row list' and identifies the key resource identifiers (table, row list, row selector, column XML name). This distinguishes it from sibling tools like banana_rowlist (returns whole list) or banana_cell (likely for table cells).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the exact parameters needed, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. For example, it does not say 'to read a single cell, use this; to read entire rowlist, use banana_rowlist'.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that the result is a JSON array with an example format, but does not disclose behavior for edge cases like missing tables or empty row list sets. Given the safe read annotation, the added context is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with an example, front-loaded and concise. Every element contributes; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with good annotations and full schema parameter coverage, the description sufficiently conveys the output format. It could mention error scenarios or empty results, but given the tool's simplicity, the current description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions for 'table' and 'doc'. The description does not add further parameter detail, but the schema already fully explains the inputs, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description precisely states the tool returns a JSON array of row list names for a given table, with an example. This clearly distinguishes it from sibling tools like banana_table_names (which lists table names) and banana_rowlist (which deals with row list contents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage simply by stating what it does, but it does not explicitly explain when to use this tool over alternatives. No mention of exclusions or prerequisites such as the need for an existing table.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, informing the agent that this is a safe read operation. The description adds only the endpoint path, not the return structure or other behavioral details. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action 'Return', includes the endpoint, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only), the description is sufficient to allow correct invocation. However, with no output schema, a bit more detail about what the 'settings page' returns (e.g., HTML vs JSON) would enhance completeness, though it's not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is an empty object. The baseline for 0 params is 4, and the description doesn't need to add parameter semantics beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return the Banana web server settings page (`/v2/settings`)' uses a specific verb ('Return') and resource ('web server settings page') with the exact endpoint. No sibling tool covers 'settings', so it is clearly distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or prerequisites. Given the large sibling list, more context about usage would be valuable.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a read-only operation. The description adds that the tool supports period, frequency, and filter, which informs how the result may vary. However, it does not disclose details about return format, edge cases, or the meaning of 'current' relative to period/frequency, leaving some behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the purpose and then lists the supported parameter types. It contains 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description gives a clear idea of the return value ('VAT balance figure') and the key modifiers (VAT code/group, period, frequency, filter). While the schema covers all parameters, the description could have clarified how 'current' interacts with period/frequency, but overall it is sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters fully. The description mentions 'period, frequency and filter' but adds no additional syntax or meaning beyond what the schema provides. Thus the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Return') and resource ('VAT balance figure for a VAT code or VAT group'), which distinguishes it from sibling tools like banana_vat_report or banana_vat_description. It also mentions the supported filters (period, frequency, filter), providing clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving VAT balance figures, but it does not explicitly contrast it with alternatives such as banana_balance or banana_vat_report. No when-not-to-use guidance is provided, so the usage context is only hinted at through the resource and parameter descriptions.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value beyond annotations by specifying the exact structure of the returned JSON array and giving a concrete example, which clarifies 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action to return the list, states the return format, and includes a concrete example. Every element is useful with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no output schema, the description fully explains the return value format and provides an example. The optional parameter is adequately documented in the schema, so no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional 'doc' parameter, and its description is already clear. The tool description adds no new parameter-related information, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and identifies the exact resource ('accounting groups') with an explicit output format ('JSON array of {id, descr} objects'). The example disambiguates it from sibling tools like banana_accounts or banana_segments by naming accounting groups directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as banana_segments or banana_accounts. The description only states what it returns, not in which scenarios it should be chosen or avoided.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read. The description adds 'Defaults to JSON' which is a useful behavioral detail beyond the schema, but it does not disclose other traits like response size, pagination, or error conditions. This is acceptable given annotation coverage but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every word adds value. It avoids restating schema details verbatim while still giving a concise overview.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, all fully described in the schema, and no output schema, the description adequately sets expectations by calling it a ledger and noting the JSON default. It could have mentioned the response structure or pagination, but the schema and read-only annotations make it sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already well documented. The description merely lists some parameter names ('view, columns, navigation, period and filter') without adding deeper meaning. The only slight addition is 'Defaults to JSON', but that is also in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Return' and a clear resource: 'the account card (ledger of transactions) for an account'. It distinguishes this tool from siblings like banana_balance or banana_journal by naming a unique resource (account card) with a clarifying parenthetical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need the account card ledger for a specific account. It does not explicitly mention alternatives or exclusions, but the context is unambiguous, which aligns with 'clear context, no exclusions'.
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?
Annotations already declare readOnlyHint=true, covering the safe-read aspect. The description adds useful context about group targeting and optional column selection, but does not disclose behavior for missing accounts, invalid columns, or the exact return format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and containing only essential usage details (group targeting and optional column). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 parameters, no output schema), the description covers the core function, group targeting, and optional column return. It could optionally mention return format or error behavior, but the schema and annotations cover the parameters and read-only nature, making this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already documents all parameters, including the 'Gr=1' syntax and the column XML name. The description does not add any parameter semantics beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Return the description of an account or group', a specific verb+object pair. It also explains the 'Gr=<id>' syntax for targeting groups and mentions the optional column feature, making it clearly distinct from sibling tools such as banana_accounts or banana_cell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for retrieving descriptions, and it provides a specific usage guideline with the 'Gr=<id>' selector. It does not explicitly list alternative tools or exclusions, but the context is sufficiently clear for when to use this tool.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral detail beyond annotations: it specifies that the output contains 'XML names' (as opposed to display names) and is returned as a JSON array. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the action, resource, and output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description adequately explains the return value (JSON array of XML names) and the schema covers the parameters. While output schema is absent, the description fills that gap. It does not mention error behavior or integration with other actions, but these are not critical for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with descriptions (doc and table). Since the description does not add any parameter-specific meaning beyond what the schema already provides, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return the list of column XML names for a table as a JSON array.' It specifies a concrete verb, resource, and output format, distinguishing it from sibling tools like banana_table_names (lists table names) and banana_cell (reads a specific cell).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the name and description (e.g., when needing column names for a table), but the description does not explicitly state when to use this tool versus alternatives or provide any exclusions. No sibling tool is mentioned as a comparison.
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 annotations declaring readOnlyHint and openWorldHint, the safety profile is already known. The description adds valuable context by specifying the exact return format (JSON array of {id, descr} objects) with an example, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the purpose and includes a concrete example. Every word contributes to understanding the tool's output, with no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only list tool with one optional parameter and no output schema. The description fully specifies the return structure with an example, making it complete for an agent to understand what to expect without needing additional return-type documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter 'doc' with a full description, so the description does not need to add parameter details. The description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of accounts as a JSON array of {id, descr} objects, which is a specific verb+resource combination. It distinguishes itself from sibling tools like banana_account_description or banana_account_card by focusing on the full list retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the full list of accounts is needed, but it does not explicitly mention alternatives or when not to use this tool. There is no direct comparison to sibling tools such as banana_account_description for individual account lookups.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the return type (HTML page) and the purpose (listing endpoints), but does not mention error handling, default behavior for missing doc, or any rate limits. This is moderate value beyond annotations, consistent with a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no wasted words. The first sentence tells exactly what it does; the second adds use-case context. Ideal compactness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and clear read-only annotations, the description is fully sufficient. It states the return type and practical use, leaving no critical gaps for the agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single 'doc' parameter, including an example and default handling. The description adds no parameter-specific details beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an HTML page listing all available HTTP requests/endpoints for a given document, with a specific verb ('Return') and resource ('HTML page'). This differentiates it from sibling data-access tools by focusing on endpoint discovery, not data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining it is 'useful for discovering what data a specific accounting file exposes.' This implies use in exploration workflows, but it does not explicitly name alternatives or when-not-to-use conditions, 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?
Annotations already declare the tool as read-only and open-world, so the description does not need to restate those. It adds the exact endpoint, which is useful, but no additional behavioral traits (e.g., response size, caching, or side effects) are disclosed. Since the annotations cover the safety profile, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function with no filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and a simple help-page action, the description is fully sufficient. It specifies the endpoint and the result, leaving no critical gap for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 correctly omits parameter details, as there are none to explain. It adds no unnecessary confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the specific resource ('the web server help page (`/v2/help`)'), making it distinct from all sibling tools, none of which are help-related. It is a specific verb+resource pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool's nature as a help resource; an agent would naturally call it when needing help information. However, there is no explicit guidance about when to use it versus other tools, nor are any alternatives mentioned, so it stops short of a 4.
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?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description's value lies in specifying the return format (a JSON array of {section, id, value} objects) and the 'all' qualifier suggesting no filtering. This adds useful behavioral detail beyond the annotations, though it does not disclose error handling or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that communicates the action, resource, and output format without wasted words. It is well-structured and front-loaded with the verb 'Return'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with one optional parameter and no output schema. The description adequately covers the return value structure, and the schema handles parameter details. No additional context seems necessary for an AI 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage (100%) for the single optional parameter 'doc', including its description and default behavior. The description does not add any additional parameter semantics; the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns all file infos for a document, specifying the exact output format as a JSON array of {section, id, value} objects. This distinguishes it from sibling tools like banana_info_value and banana_info_table which likely return specific individual info items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need all file infos for a document, use this tool. However, it does not explicitly mention when to prefer this over alternatives such as banana_info_value or banana_info_table, nor does it mention any exclusions or conditions.
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?
The annotations already indicate readOnlyHint=false and openWorldHint=true, signaling potential side effects. The description adds context about the execution environment (server-side, path resolution relative to the user's document directory) and optional inputs. However, it does not disclose the return value (script output, errors, etc.) or further side-effect details, so the description only partially enhances the annotation-provided behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, focused sentences. Each sentence delivers essential information: the core action, path handling, and optional parameters. No redundant or filler content, and the most critical information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and is a script execution tool, the description could be more complete about what the caller receives (e.g., script output, success/failure indication). It covers the action well but leaves uncertainty about the response and any post-execution effects, which is a notable gap for such an operationally significant tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by clarifying that scriptfile paths can be absolute or relative to the user's document directory, which is absent from the schema. It also groups the optional parameters in a concise way, reinforcing the relationship between document and input data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute a Banana JavaScript file on the server (`/v2/script`)'. It identifies the specific action (execute), the resource (Banana script file), and the endpoint. This distinctly separates it from the many data-retrieval siblings like banana_accounts or banana_balance, which are all read-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—whenever a Banana script needs to be run—and the sibling list shows no other tool for script execution. However, it does not explicitly state alternatives or exclusion criteria (e.g., 'use this for custom scripts, not for standard data queries'), so it lacks the full explicit guidance needed for 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?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. It adds useful behavioral context: the doc suffix convention for previous years and the supported filters. No contradiction with annotations, and openWorldHint is not explained but not contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, information-dense sentences. The first states purpose, the second explains the previous-year suffix, the third lists supported features. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the detailed schema (100% coverage) and read-only annotation, the description covers all essential usage aspects: what it returns, how to access previous years, and available filters. It doesn't describe return format, but with no output schema and openWorldHint=true, that's acceptable. Could add an example or mention limitations, but the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra semantic value by explaining the doc suffix convention ("_p1"/"_p2" for previous years), which is not in the schema, and by summarizing the period, frequency, and filter capabilities that map to parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an accounting balance figure, specifying the scope (account, group, or balance class). It distinguishes from siblings like banana_budget or banana_vat_balance by the generic balance focus and mention of groups/classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some guidance (using _p1/_p2 suffixes for previous years, supporting period/frequency/filter) but does not explicitly name alternatives or exclusions. It provides context but not a full when-to-use vs when-not-to-use comparison with sibling tools.
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?
Annotations declare readOnlyHint=true and openWorldHint=true, which already establish the safety profile. The description adds useful behavioral context by noting support for period, frequency, and filtering, and by specifying that it returns a budget figure for account/group/class selectors. While it doesn't describe the exact return format, the term 'figure' suggests a scalar value, and annotations cover the rest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose and key capabilities without any filler. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (6 params, 2 required, no output schema), the description plus schema covers the necessary information. The description indicates it returns a budget figure, and the schema explains the parameters. It could be slightly more explicit about what a 'budget figure' means, but overall it's complete for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it merely mentions 'period, frequency and filter' without additional detail. The schema's parameter descriptions already fully document each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a budget figure for an account, group, or balance class, with a specific verb and resource. It distinguishes itself from related sibling tools like banana_budget_card and banana_budget_interest by focusing on the raw budget figure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool supports (period, frequency, filter), implying when to use it for budget lookups. It doesn't explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer typical usage.
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?
Annotations already declare readOnlyHint=false and openWorldHint=true, so the description doesn't need to cover the safety profile. It adds that the tool POSTs a raw body, but does not elaborate on response behavior, error cases, or side effects beyond the implicit creation. This is adequate but not rich; the 'escape hatch' framing adds some context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The description is front-loaded with the essential purpose ('Escape hatch for the Send Data API: POST...') and immediately gives the shape requirement. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (raw POST) and the schema covers both parameters. The description provides the expected body shape and directs users to the common-case alternative. It does not explain the return value or the effect of the `show` parameter, but those are less critical for an escape hatch and are covered by the schema. Overall, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, so parameters are already documented. The description repeats the expected shape `{ fileType: {...}, data: <DocumentChange> }` which adds no new meaning beyond the schema's `body` description. There is no extra detail about the `show` parameter, but the schema covers it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Escape hatch for the Send Data API: POST a raw request body to `/v2/doc`.' It identifies the specific verb (POST), resource (/v2/doc), and scope (raw payload). It also distinguishes from the sibling tool by saying 'Use `banana_create_document` for the common cases.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool vs alternatives: 'Escape hatch' implies it is for cases that fall outside the standard wrapper, and 'Use `banana_create_document` for the common cases' gives a clear alternative. This is direct and actionable.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to state side effects. It adds the return format (YYYY-MM-DD) and that it can return either the accounting's start date or that of a given period abbreviation. This goes beyond the annotations but could be slightly clearer about 'the accounting'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action and output format without any filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only tool with parameters fully described in the schema, the description covers the core return value and input types. However, 'of the accounting' is slightly ambiguous (whether it means the fiscal year start or current period start), and no error behavior is mentioned. Given the presence of schema and annotations, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter descriptions, providing details for 'doc' and 'period' including abbreviations and date ranges. The description adds little beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' with a clear resource 'start date' and output format 'YYYY-MM-DD'. It distinguishes from sibling banana_end_period by explicitly focusing on the start date, 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for obtaining the start date of an accounting period or a given abbreviation like 'Q1'. However, it does not explicitly mention when not to use it or reference alternatives, though the sibling banana_end_period implies complementary usage. No exclusions are stated, but the purpose is evident.
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?
Annotations already declare readOnlyHint=true, covering the read-only nature of the operation. The description adds that it returns an HTML form and specifies the endpoint, but does not disclose other behavioral traits such as authentication requirements, rate limits, or the exact structure of the returned form. With annotations present, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the action, resource, endpoint, and purpose. No unnecessary words or redundant information are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with readOnlyHint annotation, the description fully explains what the tool returns (the HTML form) and why it exists (for CRUD on app data). The output is an HTML form as explicitly stated, so no output schema is needed. The description is complete for a simple form-fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with 0 parameters and 100% schema description coverage. There are no parameters to clarify, so the description correctly does not add parameter information. The baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the HTML form used to create, modify or delete app data (\`/v2/appdataform\`)'. This specifies a precise verb ('return'), a concrete resource (HTML form), and the operations it supports (create, modify, delete). It is clearly distinguished from sibling tools like banana_appdata_put, banana_appdata_delete, and banana_appdata_get, which perform the actual data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the HTML form for app data CRUD is needed, and the sibling tool names (appdata_put, appdata_delete, appdata_get) indicate alternatives that perform the operations directly. However, it does not explicitly say 'use this when you need the form, not the data operation', leaving that inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is already established. The description adds context by enumerating the returned fields and the optional single-value request behavior. No side effects or unusual behaviors are mentioned, but annotations cover the critical safety aspect, so the description adds meaningful value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly worded sentences. The first states the main purpose and scope, the second explains optional parameter usage. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature (annotated with readOnlyHint) and a single optional parameter, the description fully covers functionality. It lists the fields returned and explains the optional value_name parameter. No output schema is needed because the return fields are explicitly enumerated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes value_name with examples ("serial", "version"). The description adds the full set of available fields (version, serial, OS, Qt version, channel) and includes "name" as an additional example, giving richer semantic context than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves information about the running Banana Accounting application, listing specific fields (version, serial, OS, Qt version, channel). This distinguishes it from the sibling banana_application_version, which presumably only returns the version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use when you need application-level information. However, it does not explicitly mention alternatives or exclusion criteria, such as using banana_application_version when only the version is needed. No when-not guidance is included.
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?
The annotations already declare readOnlyHint and openWorldHint, so the agent knows this is a safe, side-effect-free operation. The description adds the return format with an example, providing useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's purpose and includes an example. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, read-only), the description is fully sufficient. It specifies the exact return value with an example, leaving no gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to explain. The baseline of 4 applies, and the description adds no additional parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the Banana Accounting application version string, with a concrete example format. This distinguishes it from sibling tools like banana_infos or banana_application by specifying the exact resource (version string).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the application version is needed, but provides no explicit guidance on when to choose this over alternatives. It doesn't mention exclusions or alternative tools, which is acceptable for a simple getter but leaves some room for interpretation.
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?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds behavioral value by disclosing that setting recheck=true triggers a fresh 'Recheck accounting' operation before returning results, which is not obvious from the schema alone. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and the second sentence explains the optional recheck behavior. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description provides sufficient context: what it returns (list of messages as JSON array), and the key behavioral option (recheck). No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage. The description adds extra semantic value for the recheck parameter by explaining its effect ('force a fresh Recheck accounting'), going beyond the schema's 'When true, run Recheck accounting first.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return the list of accounting validation/error messages as a JSON array.' This is a specific verb+resource combination that distinguishes it from the sibling tool banana_messages_count, which likely returns only a count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives guidance on when to set recheck=true ('to force a fresh Recheck accounting'), but it does not explicitly state when to use this tool versus alternatives or mention the sibling count tool. The usage context is implied rather than fully explicit.
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?
Annotations already declare readOnlyHint and openWorldHint. The description adds that the result is returned as text and explains the recheck behavior, implying potential caching of results without recheck. This exceeds basic annotation coverage without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the purpose and the key conditional. No filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple counting tool with 2 parameters and no output schema, the description covers the return format (text), the recheck condition, and the document parameter via schema. The annotations handle safety and external behavior, so the tool is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of both parameters (doc and recheck). The description repeats the recheck semantics already in the schema and adds no new parameter-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: returning the number of error messages in the accounting file as text. It distinguishes from siblings like banana_messages (which likely lists messages) and banana_table_rowcount by specifying the resource 'accounting file' and the count format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear conditional usage for the recheck parameter ('Set recheck=true to force a fresh...'), indicating when to trigger a recheck. However, it does not explicitly contrast with alternative tools (e.g., banana_messages) or mention when not to use this tool.
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 readOnlyHint=true already declared, the description adds valuable context by stating the exact return format (a JSON array of names) and the scope (all tables). This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a concrete example. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description fully explains what it returns (JSON array of table names) and the scope (all tables). Annotations cover safety, and the schema covers parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a thorough description of the 'doc' parameter, including naming conventions and defaults. The description adds no additional parameter information, so it receives the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('names of all tables in a document'), which clearly states the tool's function. It also provides an explicit output example and distinguishes itself from siblings like banana_table and banana_table_columns by focusing on names only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need the names of all tables in a document. It does not explicitly name alternatives or exclusions, but the phrase 'all tables' sets expectations and helps disambiguate from table-content tools.
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?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds the optional column behavior, which is a meaningful behavioral trait not present in the annotations. It does not describe error handling or return format, but for a simple read operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the primary purpose, and the second covers the optional parameter. Front-loaded and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one required parameter, the description, combined with full schema coverage and read-only annotations, provides sufficient context. No output schema exists, but the return value (a description string) is implied by the tool's name and description, so no additional detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds semantic value by explaining that the 'column' parameter overrides the default Description output, which links the parameter to the tool's primary behavior and clarifies its role beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return the description of a VAT code.' It specifies a concrete action and resource, and the optional column detail distinguishes it from sibling tools like banana_vatcodes, which likely lists VAT codes rather than retrieving a single description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need a VAT code description) but does not explicitly mention when to use this tool versus alternatives like banana_vatcodes, nor does it provide exclusions or alternatives. The optional column note gives a usage option but no strategic guidance.
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?
The readOnlyHint and openWorldHint annotations align with the 'Return' action. The description adds the endpoint path and the list of known apps, giving practical context beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, resource, endpoint, and known apps with zero filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description fully conveys the tool's purpose, target URL, and valid inputs. It is complete for the agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with descriptions and examples, achieving 100% coverage. The description reiterates the app_name example but adds no new semantic information beyond what the schema provides, so it does not elevate the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and clearly identifies the resource as a 'built-in WWW app HTML page' with the exact endpoint `/v2/doc/{doc}/apps/{app_name}`. It also lists known apps, which distinguishes it from any sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool returns an HTML page for a document, and it names two valid app values. It doesn't explicitly exclude alternatives, but no sibling offers similar functionality, so the usage context is sufficient.
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?
Annotations already indicate a write operation (readOnlyHint=false), and the description adds meaningful context: it opens a new window for review, does not modify existing files, and requires either accountingType or ac2_base64+title. This goes beyond the annotation flags without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the primary action, then side effects, then parameter selection guidance. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core behavior, side effects, and parameter modes. It lacks return value details, but no output schema exists and the tool's high-level, show-in-window purpose makes the return trivial. It is sufficiently complete for an agent to decide and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds critical usage semantics: the either/or relationship between accountingType and ac2_base64+title, and that row changes are applied table by table. This clarifies how parameters combine, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a NEW accounting file in Banana and shows it, with the specific verb 'Create' and resource 'accounting file'. It distinguishes from modifying existing files and from the lower-level sibling create_document_raw by emphasizing its high-level, show-in-window behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use: to create a new file and show it, and clarifies it does not modify an already-open file, which is an exclusion. However, it does not directly name alternatives like banana_create_document_raw, so the comparison with siblings is only implicit.
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?
Annotations already declare the tool as read-only, and the description adds useful behavioral details: the exact return format (JSON array), an example, and the edge case of an empty array when no document is open. This goes beyond the annotations and helps set 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action and result, and includes a useful example and a note about the empty-array behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description covers the return type, example, edge case, and how it fits into the broader toolset. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies. The description correctly focuses on output and usage, and there is no parameter information needed beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing open accounting documents and returning them as a JSON array of file names. It includes a concrete example and distinguishes itself from sibling tools by being the entry point for obtaining the `doc` value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Start here to discover the `doc` value used by other tools,' providing clear when-to-use guidance. It does not mention when not to use it or name alternatives, but the directive establishes it as the initial tool to call.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/AxLabs/banana-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server