aruba-fatturazione-elettronica-mcp

by mnbro

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation3/5
Many tools have similar purposes (e.g., multiple get_invoice methods, several summary/export variants), but they are differentiated by parameters like direction (sent/received) or identifier type. The sheer number of tools, however, can cause selection ambiguity, especially among overlapping report and summary tools.
Naming Consistency2/5
The naming is inconsistent: some tools use an 'aruba_' prefix while others (e.g., fiscal_document_summary, tax_summary) do not. Verb choices vary widely (answer, compare, detect, export, explain, find, get, etc.) without a predictable pattern, making it harder to infer tool purposes from names alone.
Tool Count1/5
With 70 tools, the count is extremely high for an MCP server. This number far exceeds the typical well-scoped range of 3-15 tools and feels overwhelming, suggesting many tools could be consolidated or pruned.
Completeness4/5
For a read-only analysis server focused on Aruba FatturaPA invoices, the toolset is quite comprehensive. It covers search, retrieval, XML parsing, summaries, exports, anomaly detection, and reports. Minor gaps exist (e.g., no send/write capabilities), but the domain is well-covered for querying and analysis.
Average 2.8/5 across 70 of 70 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on April 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description repeats 'read-only'. No additional behavioral details like pagination, response format, or what 'conceptual' means are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague sentence. It is underspecified rather than concisely informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters and many sibling tools, the description is wholly inadequate. It does not cover the tool's complexity or provide necessary usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the 13 parameters. Parameter names alone (e.g., direction, date_from) are insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Conceptual invoice search over read-only Aruba invoice lists' but does not specify whether it searches received, sent, or both invoices, nor how it differs from sibling tools like aruba_find_received_invoices or aruba_search_invoice_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Given many sibling search tools, the description lacks any context for appropriate usage.
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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds little beyond mentioning 'Sensitive' and 'Base64', which might be inferred from the output schema. No contradiction, but minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks substance. Conciseness should not sacrifice clarity; here it is under-specified, failing to convey key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low schema coverage and existence of an output schema, the description should clarify what 'sent notifications' are, what 'Base64 read' means, and how 'confirm_read' affects behavior. It does none of these, leaving major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it does not explain the 'invoiceId' path parameter or the 'confirm_read' boolean. The agent receives no help on parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'GET /services/notification/out/{invoiceId}. Sensitive notification Base64 read' is vague about what exactly the tool returns (the notification? Its Base64-encoded content?). It does not distinguish it from siblings like aruba_get_sent_notifications_by_invoice_filename or aruba_get_received_notifications_by_invoice_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., by invoice ID vs filename, sent vs received). The description does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotations. Annotations already indicate it is read-only, idempotent, and non-destructive, but the description does not elaborate on any additional constraints or effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (6 words), it sacrifices essential information. It fails to front-load critical details about parameters or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no schema description coverage, and an output schema, the description is woefully incomplete. It does not explain the tool's purpose in enough detail to allow correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the description does not explain any parameters (year, month, direction, limit). The agent has no indication of what these parameters mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Monthly invoice status summary,' which indicates it produces a summary of invoice status for a given month. However, it lacks specificity about what the summary includes or how it differs from similar tools like 'aruba_yearly_summary' or 'aruba_invoice_status_report'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, read-only operation. The description adds 'informational' but does not disclose any behavioral traits beyond the annotations, such as what happens with invalid dates or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is too brief to be helpful. While it avoids verbosity, it under-specifies the tool's functionality, making it less useful than a slightly longer but more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description is incomplete. It does not explain what the summary contains, how it is filtered by period, the meaning of direction, or the structure of the output, leaving the agent without sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to provide any meaning for the parameters (fromDate, toDate, direction, limit). Parameter names are somewhat self-explanatory, but 'direction' is ambiguous and unclarified, and the description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'return' and the resource 'informational fiscal document summary for a period', but it is vague about what the summary includes. It does not clearly differentiate from similar sibling tools like fiscal_document_summary, monthly_summary, or yearly_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The description only implies a period-based summary without additional 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 and idempotentHint. The description adds a sensitivity warning about file/PDF Base64, which is useful. However, it does not explain other behaviors like the effect of confirm_read or what happens when includePdf is true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one line), but it sacrifices key information. It is not structured as a proper tool description and lacks a clear subject-verb-object format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, an output schema, and many sibling tools, this description is grossly insufficient. It fails to convey what the tool returns, when to use it, and how parameters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain any parameters. The meaning of 'includePdf', 'includeFile', 'confirm_read' remains unclear from the description alone. This adds no value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions the REST path and the action of retrieving by filename, but it does not clearly state what the tool does (e.g., retrieves received invoice metadata and optionally file content). It is better than tautology but still vague and does not differentiate from sibling tools like aruba_get_received_invoice_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like aruba_get_received_invoice_by_id or aruba_get_received_invoice_zip_by_filename. The description lacks context on prerequisites or conditions for use.
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, destructiveHint=false, idempotentHint=true, so the agent knows it's safe. Description adds that the output is Base64-encoded. No contradiction, but no mention of what confirm_read does or any side effects beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks clarity and substance. It uses fragmentary language ('Sensitive notification Base64 read') and does not follow a clear structure. Important details like parameter explanations are omitted, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (per context) and only two simple parameters, the description fails to explain return format, how confirm_read affects behavior, or how this tool relates to similar tools. This is insufficient for an agent to use it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not explain any parameter. It only mentions invoiceId in the URL path without defining it, and ignores confirm_read entirely. This leaves the agent without understanding what values to provide or the effect of the boolean parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description mentions HTTP method, path, and 'Sensitive notification Base64 read', indicating it retrieves a Base64-encoded notification. However, it does not explicitly state that it reads received notifications by invoice ID, and it fails to distinguish from siblings like aruba_get_received_notifications_by_invoice_filename or aruba_get_sent_notifications_by_invoice_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many sibling tools for notifications or invoices. No context about prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool is clearly safe. However, the description adds no additional behavioral context such as performance characteristics, data scope, or any warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it lacks necessary detail. It is not overly verbose, but the brevity sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is insufficient. It does not clarify the output, how parameters affect the summary, or distinguish it from similar tools. The tool requires more context for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters ('year', 'direction', 'limit'). The agent must infer meaning solely from parameter names, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'Yearly invoice status summary', giving a general verb and resource, but it is vague about what exactly it summarizes. It does not differentiate from sibling 'aruba_monthly_summary' or other report tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'aruba_monthly_summary' or other invoice reports. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate readOnly, non-destructive, and idempotent behavior, the description adds a valuable warning about sensitivity when requesting file/PDF Base64, which exceeds the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the endpoint path, which is not particularly helpful. It is concise but lacks substantial content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having annotations and an output schema, the description fails to explain that the tool retrieves a sent invoice by SDI ID, nor does it describe the parameters or return value. It is incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain parameters. It only hints at sensitivity related to includePdf/includeFile but does not define any parameter, including the required 'idSdi' or 'confirm_read'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states the HTTP method and path, which is not a clear statement of what the tool does. It relies on the tool name to imply retrieval of a sent invoice by SDI ID, but fails to explicitly describe the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus its many siblings, such as 'aruba_get_sent_invoice_by_filename' or 'aruba_get_sent_invoice_by_id'. There are no alternative suggestions or context for usage.
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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description merely repeats 'Read-only' without adding behavioral context like pagination behavior, data freshness, or any side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one line), but at the cost of omitting essential information. The brevity leads to under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 undocumented parameters and no output description, the description is severely incomplete. Even though an output schema exists, the description fails to explain what a 'multicedente' is, how filtering works, or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no explanation for the five parameters (countryCode, vatCode, status, size, page). An agent cannot infer meanings or correct usage from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Read-only multiseller listing' and the HTTP method GET, clearly indicating a read operation to list multiple entities. It distinguishes from sibling 'aruba_get_multicedente_by_id' (singular). However, 'multiseller listing' may be slightly vague without domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like aruba_get_multicedente_by_id. It does not mention filtering or pagination use cases. The description lacks any contextual hint for appropriate invocation.
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 indicate read-only, idempotent, and open-world behavior. The description adds no further behavioral context, such as what type of consistency is checked or if the document must be normalized beforehand. It misses an opportunity to add value 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence) but omits essential information. This is under-specification, not genuine conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no enum constraints, and a likely non-trivial output schema, the description is severely incomplete. It does not explain what the tool does beyond 'technical consistency checks', nor does it mention outcomes or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters but fails to do so. 'documentId' and 'direction' are not explained, and 'confirm_read' is mentioned only in schema. The description adds no meaning to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs 'technical consistency checks' on 'one normalized fiscal document', specifying the verb and resource. However, it lacks details on what exactly these checks entail, which could help distinguish it from similar tools like validate_invoice_xml_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusion criteria. The user is left uninformed about the appropriate context for invoking this tool.
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 idempotentHint=true, so the description adds limited behavioral context beyond these. The disclaimer 'without providing definitive tax advice' is useful but does not describe other behaviors like input constraints or output format. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but sacrifices necessary information. It lacks structure and fails to convey how or when the tool should be used. Conciseness is not valuable when it omits critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five optional parameters with zero schema descriptions, many sibling tools, and an output schema available, the description is woefully incomplete. It does not explain what anomalies are detected, how parameters affect results, or how to interpret the output. Minimal viable completeness would require at least parameter explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions. The tool description does not explain any of the five parameters (direction, date_from, date_to, limit, confirm_read). This provides no added value over the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects data-quality anomalies, indicating a specific verb and resource (invoice data quality). However, it does not distinguish itself from sibling tools like aruba_find_duplicate_invoices or aruba_validate_invoice_xml_structure, which also detect specific quality issues. The disclaimer about tax advice adds clarity on scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclude other tools. The only hint is the disclaimer, which is not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds minimal behavioral context beyond stating 'read-only' and mentioning the HTTP GET method. It does not disclose pagination behavior, authentication requirements, or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, but it omits important structural elements. While brevity is valued, the lack of parameter details and usage notes makes it inadequate for a tool with many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (11) and zero schema coverage, the description is severely incomplete. It does not explain how to construct searches or what each filter does. Even with an output schema, the input side is poorly documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, meaning no descriptions exist for any of the 11 parameters. The description fails to explain the purpose or format of parameters like 'username', 'page', 'size', and various date and code fields. This leaves the agent without necessary guidance to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a read-only search for sent invoices. The tool name and description distinguish it from sibling tools like 'aruba_find_received_invoices'. However, it could be more specific about what a sent invoice constitutes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any usage context or guidance on when to prefer this tool over alternatives like 'aruba_search_invoices' or 'aruba_find_received_invoices'. It only states it is a 'read-only sent invoice search', leaving the agent to infer applicability.
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 description adds no behavioral information beyond what annotations already declare (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). It doesn't mention side effects, required permissions, or output characteristics. The description carries a low burden due to rich annotations but fails to add any context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. However, it is too terse to be informative; it sacrifices necessary detail for brevity. It earns a middle score because it is not verbose but is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with no schema descriptions, no explanation of the output timeline, and a rich set of sibling tools, the description is severely incomplete. It does not tell the agent what the timeline contains, how parameters affect it, or how it compares to other invoice tools. The presence of an output schema is noted, but without any context, the agent cannot use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (direction, filename, confirm_read). No semantic meaning is added beyond the parameter names themselves, which are ambiguous (e.g., direction could mean 'ascending/descending' or 'sent/received'). The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a timeline from invoice metadata and SDI notifications, which is a specific verb and resource. It distinguishes from siblings as no other sibling mentions 'timeline'. However, it doesn't explain what the timeline represents or its format, so clarity is slightly reduced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about typical use cases, prerequisites, or scenarios where this tool is preferable to others. This forces the agent to infer usage from the tool name 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 provide readOnlyHint, idempotentHint, etc. The description adds that the notification is 'sensitive' and involves 'Base64 read', which adds some behavioral context beyond annotations. However, it does not explain the effect of the 'confirm_read' parameter or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), but it is not well-structured. It starts with the endpoint path, which is useful, but the remainder 'Sensitive notification Base64 read' is cryptic and not front-loaded with the core action. It could be more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of many similar sibling tools and the existence of an output schema (not shown), the description is incomplete. It does not explain the return value, how the 'confirm_read' parameter affects behavior, or how this tool differs from 'aruba_get_received_notification_by_filename' or others. The description lacks sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not mention any parameter (invoiceFilename or confirm_read). The parameter names are somewhat self-explanatory, but confirm_read's purpose and default behavior remain unclear. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates a GET endpoint to read a notification by invoice filename, and mentions 'Sensitive notification Base64 read'. However, it is vague about whether it returns one or multiple notifications, and does not clearly distinguish from sibling tools like 'aruba_get_received_notification_by_filename' (singular) or 'aruba_get_sent_notifications_by_invoice_filename'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The annotations hint at safety, but no explicit when-to-use or when-not-to-use context 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 indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds that the notification content is sensitive and Base64 encoded, which provides additional behavioral context beyond the annotations. However, it does not describe pagination, limits, or the exact nature of the data returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of two sentences. While concise, it sacrifices necessary detail about parameters and usage. The structure is acceptable but lacks completeness for a tool with no parameter documentation in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, an output schema, and numerous sibling tools, the description is insufficient. It fails to explain the purpose of the parameters, when to use the confirm_read flag, or how the output relates to the input. The output schema exists, but the description should still provide context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage with no explanations for the two parameters (invoiceFilename and confirm_read). The tool description does not add any meaning to these parameters, leaving the agent without guidance on how to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes the endpoint URL and states 'Sensitive notification Base64 read,' indicating it retrieves sent notifications in Base64 format. However, it does not specify whether it returns a single notification or multiple, and it fails to distinguish from similar sibling tools like aruba_get_sent_notification_by_filename or aruba_get_sent_notifications_by_invoice_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention any prerequisites, conditions, or scenarios where this tool is preferred over other tools that get sent notifications.
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, destructiveHint=false, idempotentHint=true, which covers safety. The description adds minimal behavioral context ('translate' implies transformation but not mutation). It does not discuss side effects like marking notifications as read if confirm_read is true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence makes it highly concise, but it sacrifices necessary detail. No structure or front-loading beyond the one line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and 3 parameters with no schema descriptions, the description is extremely terse. It fails to explain return value, parameter semantics, or any procedural context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no clarification for any of the three parameters (direction, invoice_filename, confirm_read). The tool name hints at invoice context, but meaning of parameters is left entirely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool translates SDI notifications into human-oriented status information, specifying the action (translate) and resource (SDI notifications). It distinguishes from siblings like aruba_get_received_notification_by_filename or aruba_parse_notification_xml which retrieve or parse raw data, but 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus related tools. The description does not mention prerequisites, context, or when to avoid using it.
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 read-only, non-destructive, idempotent, and open-world behavior. The description adds minimal behavioral context: it notes the data is 'Sensitive' and in 'Base64 ZIP' format, but it does not disclose what happens if both parameters are omitted, whether authentication is required, or any other behavioral nuances 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences. The first sentence states the HTTP method and endpoint. The second adds context about content and a note about a documentation typo. The typo note is marginally helpful but slightly off-topic for an agent. Overall, it is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, an output schema, and operates in a context with many sibling tools, the description is insufficient. It lacks parameter explanations, usage examples, clarification of what a PDD is, and guidance on when to use it. The existence of an output schema is not mentioned, and the description does not help the agent understand the full scope of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with no descriptions (0% schema coverage), and the description provides no information about them. It does not explain the meaning of 'invoiceFilename', 'invoiceId', or 'confirm_read', nor does it clarify how they relate to the operation. The description completely fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies it as a GET request to read a 'Sensitive Base64 ZIP PDD' for a received invoice, clearly distinguishing it from its sent counterpart (sibling tool 'aruba_get_sent_invoice_pdd'). However, it does not explicitly state that it retrieves a received invoice's PDD attachment, and the purpose is somewhat implied by the endpoint path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over alternatives like 'aruba_find_invoices_without_pdd' or 'aruba_get_received_invoice_by_id'. There is no mention of prerequisites, typical use cases, or when to avoid it.
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, non-destructive, idempotent, and open-world. The description adds value by noting the content is 'Sensitive' and the file is 'Base64 read', providing additional behavioral context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two fragments), missing critical details about parameters and usage. While concise, it is underspecified for effective tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter complexity and lack of schema descriptions, the description is severely incomplete. It does not explain what 'unsigned file' means, what the output contains (though output schema exists), or how the parameters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (invoiceId, filename, includeFile, confirm_read). The agent must guess their meaning from names and defaults, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving an unsigned invoice file via GET, and notes that the file is Base64-encoded. It distinguishes itself from sibling tools that retrieve invoice metadata or signed files by specifying 'unsignedFile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives like aruba_get_received_invoice_by_id or aruba_parse_invoice_xml. The description does not mention prerequisites, typical use cases, or when to avoid it.
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, destructiveHint, idempotentHint, and openWorldHint, indicating a safe, read-only operation. The description adds no further behavioral details beyond 'aggregate', which is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is overly terse given 4 parameters and no parameter explanations. It lacks necessary detail and structure, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and 0% schema coverage, the description fails to provide sufficient context for correct invocation. The output schema exists but is not leveraged in the description. The tool's purpose is clear but parameter usage is not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description provides no explanation of parameters. Parameters like 'direction' are ambiguous, and the agent must rely solely on schema field names, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates invoice status counts, which is a specific verb-resource pair. It distinguishes from sibling tools that focus on individual invoice retrieval or specific queries, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling tools, the agent receives no help in selecting this aggregate report over other invoice-related 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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description simply says 'aggregate', which is consistent with read-only behavior. It adds no new behavioral context beyond the annotations, which 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks necessary detail. It is minimally viable but not efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what the report returns. With 6 parameters and no parameter explanations, the description is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 6 parameters (e.g., direction, group_by, confirm_read). The description must compensate for low schema coverage but fails entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Aggregate invoices by supplier or customer' clearly states the tool's purpose with a specific verb ('aggregate') and resource ('invoices'), but it does not differentiate from many sibling invoice report tools like 'aruba_invoice_status_report' or 'aruba_monthly_summary'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the large number of sibling tools (e.g., aruba_invoice_status_report, aruba_monthly_summary), the lack of usage context is a significant omission.
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=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which convey safety and idempotency. The description adds no behavioral context beyond the purpose, such as what constitutes a duplicate or how results are returned. It neither contradicts nor significantly augments 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core functionality. However, it could be more informative without losing conciseness, e.g., by adding a brief note about parameters or results.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with no explanations and an output schema that is present but not described, the description is highly incomplete. An agent cannot determine correct parameter usage or interpret results without additional context from the schema or external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage in the schema itself. The tool description provides no explanation of parameters like 'direction', 'date_from', 'date_to', 'limit', or 'confirm_read', leaving the agent to rely solely on parameter names and defaults, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find possible duplicate invoices' clearly states the tool's purpose with a specific verb and resource, distinguishing it from generic invoice search tools like 'aruba_find_received_invoices'. However, it does not explicitly exclude other search or detection tools, so a perfect score is not warranted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'aruba_detect_invoice_anomalies' or 'aruba_search_invoices'. There is no mention of prerequisites, exclusions, or typical scenarios.
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, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the nuance 'appear to lack' indicating a heuristic filter rather than a definitive check. No contradictions with annotations. The description does not disclose further behavioral details like pagination or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently states the core purpose but omits important details about parameters and usage, striking a balance between brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 undocumented parameters and an output schema, the description is incomplete. It fails to explain how to use the parameters, what the output represents, or any example usage. The agent would need to rely on other signals (e.g., tool name) to fill gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions exist in the schema. The description does not mention any of the four parameters (direction, date_from, date_to, limit) or explain how they affect results. This forces the agent to guess parameter usage, which is a critical gap for a read-only tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'invoice list entries' with the specific criterion 'lack PDD references', distinguishing it from sibling tools like aruba_find_invoices_without_pdf_or_xml. However, 'PDD references' is not explained, so the purpose is clear but somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its many siblings (e.g., aruba_search_invoices, aruba_find_duplicate_invoices). There is no mention of prerequisites or when not to use it, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds that the search is heuristic ('appear to lack'), which is useful context, but doesn't detail how the determination is made or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, and front-loaded with the core action. However, it is arguably too concise given the lack of parameter and output context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 optional parameters and an output schema (presumed), the description does not explain parameter usage, return values, or pagination behavior. The tool is under-documented for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but provides no explanation of parameters (direction, date_from, date_to, limit). The agent cannot infer how to set these for desired results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds invoice entries lacking PDF/XML references, using a specific verb and resource. It distinguishes itself from siblings like 'aruba_find_invoices_without_pdd' by specifying the missing file types, though 'appear to' introduces slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'aruba_find_duplicate_invoices' or 'aruba_find_missing_notifications'. No context on prerequisites or exclusion criteria.
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, idempotentHint=true, and destructiveHint=false, so the description's 'Read-only' adds minimal value. It includes the HTTP method and endpoint path, but does not describe pagination, filtering behavior, or return format 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with only two sentences, but it sacrifices necessary detail. It is front-loaded with the endpoint and read-only nature, but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema visible, and many sibling tools, the description is severely incomplete. It fails to explain the search's scope, results, or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no parameter details. The endpoint name hints at username, but the 11 parameters (including page, size, date range, sender/receiver codes) are completely undocumented, leaving the agent uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it is a read-only search for received invoices, clearly identifying the verb and resource. It implicitly distinguishes from sent invoice searches via the name, but does not specify the search criteria (username) explicitly in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like aruba_find_sent_invoices or aruba_get_received_invoice_by_id. The description lacks context on use cases 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 and idempotentHint=true. The description adds the detail that the response is a Base64 ZIP and is sensitive, which is helpful but does not cover error conditions or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it omits crucial parameter details, making it too brief to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks information about parameter semantics and behavior, leaving significant gaps for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters, and schema description coverage is 0%. The required 'filename' and optional 'confirm_read' are left undocumented, offering no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the HTTP GET method and resource, indicating retrieval of a received invoice ZIP file in Base64. However, it does not explicitly distinguish from sibling tools like aruba_get_received_invoice_by_filename or aruba_get_sent_invoice_zip_by_filename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or use-case 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 destructiveHint=false, so the tool is safe. The description adds that the notification is 'sensitive' and the output is Base64, which is useful context beyond annotations. However, it does not disclose potential side effects, rate limits, or any constraints on the filename parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with no wasted words, but it is too brief to be fully effective. It front-loads the HTTP method and path but lacks detail. Conciseness is positive, but the brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, it still lacks parameter semantics and usage context. With many sibling tools, the description should better differentiate and guide selection. It answers the basic purpose but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'filename' implicitly via the URL path and omits any explanation of the 'confirm_read' parameter. The description fails to add meaning beyond the schema definition, leaving both parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the HTTP method, path, and action ('read'). It indicates the resource is a sensitive notification and the output is Base64, which distinguishes it from invoice or sent notification tools. However, it could be more explicit about what the tool does (e.g., retrieve a received notification by filename).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'aruba_get_received_notifications_by_invoice_filename' or 'aruba_get_sent_notification_by_filename'. There is no mention of context, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that the response is a sensitive Base64 ZIP PDD read, providing some behavioral context beyond annotations, such as the format and sensitivity, but does not elaborate on potential side effects or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), front-loading the HTTP method and resource. While it is efficient, it sacrifices informational depth. It earns its place but could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters undocumented and no explanation of return structure (though an output schema exists), the description is incomplete. It does not clarify which identifier to use, the role of confirm_read, or what PDD entails. Given the tool's positioning among many invoice-related siblings, more detail is needed for safe selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The description does not mention any of the three parameters (invoiceFilename, invoiceId, confirm_read), so it adds zero meaning beyond the bare schema. This is a critical gap for the agent to understand how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the HTTP method (GET) and resource path (invoice/out/pdd) and mentions it's a read operation for sensitive Base64 ZIP PDD. This clearly indicates it retrieves a PDD file for a sent invoice, distinguishing it from siblings like aruba_get_received_invoice_pdd. However, it lacks plain-language explanation of what PDD stands for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., aruba_get_sent_invoice_by_filename or aruba_get_sent_invoice_by_id). There is no mention of prerequisites or context, leaving the agent to infer usage.
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 description only states 'parse,' which aligns with readOnlyHint annotations, but adds no additional behavioral context such as decoding, validation, or redaction behavior. Does not mention what happens with invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no redundant information. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks context about error handling, prerequisites (e.g., document must be valid FatturaPA), or how this parsing differs from other invoice tools. Insufficient for an agent to select correctly among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but it only implies xml_base64 is Base64-encoded. The redact_sensitive parameter is completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses Base64 FatturaPA XML into structured fields, specifying the verb and resource. However, it does not distinguish from siblings like aruba_extract_invoice_fields or aruba_validate_invoice_xml_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as aruba_extract_invoice_fields or aruba_validate_invoice_xml_structure. Lacks indications of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, indicating safe read operation. Description adds no extra behavioral context (e.g., error behavior, validation, or data format specifics).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single concise sentence but lacks critical detail. It is front-loaded but too minimal to serve an effective purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though output schema exists, the description fails to explain return structure, possible errors, or input validation. For a parsing tool, such context is essential but missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning parameters are undocumented in schema. Description does not elaborate on the single parameter 'xml_base64' – no format, encoding, or usage details beyond its name. This is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Parse'), the input ('Base64 SDI notification XML'), and the output ('structured fields'). It distinguishes from sibling tool 'aruba_parse_invoice_xml' by specifying notification XML.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like aruba_parse_invoice_xml. No prerequisites or when-not-to-use instructions provided, leaving the agent uncertain about appropriate 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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the 'local SQLite' aspect, which implies a local cache but does not contradict annotations. It lacks further behavioral details like what happens if the index is not synced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. However, it is too brief to be informative, which slightly reduces effectiveness for selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, many sibling tools, and an output schema, the description is incomplete. It does not explain return values, parameter usage, or how this search differs from others, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the five parameters (text, direction, vat_code, party_name_contains, limit). The description fails to add meaning beyond the schema property names, which are vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource 'local SQLite invoice index', conveying the basic action. However, it does not differentiate from sibling tools like aruba_search_invoices, which likely performs a similar function on a broader scope, reducing clarity for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as aruba_search_invoices or various get_invoice_by_* tools. There is no mention of context, exclusions, or preferred use cases.
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 indicate read-only, non-destructive behavior. The description adds minimal behavioral context beyond the grouping aspect. It does not describe pagination, data scope, or other traits. With annotations covering safety, the description provides little extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence without extraneous words. It efficiently conveys the core purpose, though additional brief details could improve completeness without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 0 required, and many sibling report tools, the description is incomplete. It fails to clarify parameter usage or differentiate from similar tools like vat_summary or monthly_summary. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only mentions grouping by VAT rate/nature, which relates to the 'group_by' parameter. It does not explain 'direction', 'date_from', 'date_to', 'limit', or 'confirm_read' parameters, leaving most parameters semantically empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a tax breakdown report grouped by VAT rate/nature. It uses specific resource ('tax breakdown report') and grouping dimension, distinguishing it from general VAT summary or invoice reports among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; no exclusions or prerequisites mentioned. The description only states what it does, not when to prefer it.
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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds no additional behavioral context (e.g., what happens if XML is unparseable, return format), so it adds minimal value 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure and fails to present key information prominently. It earns its place but is too terse for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no descriptions, the description is insufficient for an agent to use the tool correctly. Even though an output schema exists, the lack of parameter guidance and usage context makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters, the description must explain parameter semantics but does not. It omits any mention of 'direction', 'date_from', 'date_to', 'group_by', 'limit', or 'confirm_read', leaving the agent with no understanding of how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes VAT totals from invoice XML, which is a specific resource and action. Among many sibling tools focused on invoices, it distinguishes itself by targeting VAT totals specifically, though it could be more precise about whether it requires already parsed XML.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like aruba_tax_breakdown_report or aruba_summarize_invoice. There are no prerequisites or exclusions mentioned, leaving the agent to infer 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 specify read-only, idempotent, non-destructive behavior. The description adds no additional behavioral context beyond the intended action of aggregation, but it does not contradict 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, but it is under-specified for a tool with multiple parameters. Conciseness trades off against completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, a nested object, and many sibling tools, the description is too brief. It omits parameter details and usage context, though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but fails to explain any of the 5 parameters. It only implies the counterparty parameter, ignoring date range, direction, and limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates document history for a counterparty, using a specific verb and resource. It distinguishes from sibling tools which are mainly invoice-focused, though it could be more precise about the document type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool over alternatives or any prerequisites, leaving the agent without context for selection.
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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety traits. The description adds mild context by specifying 'fiscal/SDI lifecycle status', but does not discuss side effects, permissions, or output behavior beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it sacrifices detail. For a tool with 4 parameters and specific context, slightly more structured information would improve usability without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 2 required) and lack of parameter descriptions, the description is insufficient. It omits output behavior, optional parameter effects, and any domain-specific constraints, making it hard for an agent to use correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are completely undocumented. The description does not explain the meaning or roles of 'documentId', 'direction', 'asOfDate', or 'confirm_read', leaving the agent with no semantic understanding of required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'explain' and the resource 'one document's fiscal/SDI lifecycle status', indicating a specific read operation. It distinguishes implicitly from sibling tools like 'aruba_explain_invoice_type' or 'fiscal_document_summary' by focusing on lifecycle status, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or context. The description lacks any indication of suitable scenarios or exclusions, leaving the agent without direction.
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=true, destructiveHint=false, and idempotentHint=true, so safety is clear. The description adds that output is Markdown, but does not disclose how the report is generated, what 'generic' means, or any other behavioral traits like date range handling or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it is too brief to be adequately informative. It sacrifices necessary detail for brevity, resulting in under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, a required nested object, and an output schema, the description is incomplete. It does not cover filtering, output content, or parameter constraints, leaving significant gaps in understanding for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain parameters. It does not mention any parameter details, such as the structure of 'counterparty', date formats, 'direction' options, or 'limit' meaning. This leaves agents without critical input information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a counterparty fiscal document report as Markdown. The verb 'export' and resource are specific, and the Markdown format distinguishes it from sibling tools like aruba_counterparty_report. However, it does not explicitly differentiate from other export tools like export_document_markdown or export_period_markdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks information about prerequisites, context, or exclusions, leaving the agent without decision support for tool selection.
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 provide strong behavioral hints (readOnly, idempotent, non-destructive). The description adds minimal context (export as Markdown) but does not contradict annotations. It does not explain output format details or any limitations, but the annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it underspecifies the tool. It earns points for brevity but lacks necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (2 required) and an output schema, the description is incomplete. It fails to explain parameter semantics or usage context, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain parameters, but it only mentions 'one fiscal document', leaving undocumented parameters like direction, includeLineItems, includeNotifications, includeRawRefs, and confirm_read completely unexplained. The agent cannot understand their purpose or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports one fiscal document as generic Markdown, using a specific verb and resource. However, it does not differentiate from sibling tools like 'export_counterparty_markdown' or 'export_period_markdown', which also export Markdown for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites or context. The description only states what it does, leaving the agent to infer appropriate 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=true, destructiveHint=false, idempotentHint=true. The description adds 'read-only' and 'complete' context, aligning with annotations and adding minimal value but not contradicting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key action. It is concise, though it could afford a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (none described in schema), a complex output schema, and many sibling tools, the description fails to explain what 'context' includes, the role of direction or confirm_read, or how this tool differs from others. It is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description does not explain any of the three parameters (documentId, direction, confirm_read) beyond mentioning 'one Aruba fiscal document' which only hints at documentId. This is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'complete read-only context for one Aruba fiscal document', but it does not distinguish this tool from siblings like aruba_get_invoice_full_context or other get_* tools, which may serve similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or context. The description is too minimal to help an agent decide between this and similar 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 destructiveHint=false, so the description adds no behavioral context. It does not conflict with annotations but also does not elaborate on what 'need attention' means or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks necessary details about parameters and usage. It earns its place but could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and many siblings, the description is incomplete. It does not explain the criteria for 'need attention', the role of parameters, or how it differs from similar listing tools. The presence of an output schema partially mitigates, but the description still falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (parameters have no descriptions). The tool description does not mention any parameters, leaving the agent to rely solely on parameter names and types, which is insufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists fiscal documents needing attention, which is a clear verb-resource pair. However, 'need attention' is vague and does not explicitly differentiate from sibling tools like aruba_search_invoices or specific filters, though the name helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., aruba_search_invoices, aruba_find_received_invoices). The description does not specify context 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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, providing a clear behavioral profile. The description adds 'clean JSON table' but does not contribute further behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but under-specified. It is appropriately front-loaded but could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters with zero descriptions, many sibling tools, and an output schema, the description is too sparse. It lacks essential context for effective use, such as parameter explanations or result format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 6 parameters (direction, date_from, date_to, format, columns, limit). The parameter titles provide minimal clues, but the description fails to add meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and output: 'Return a clean JSON table for invoices.' However, it does not differentiate from sibling tools like aruba_search_invoices or aruba_find_received_invoices, which likely return invoice data in different formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are many invoice-related sibling tools with overlapping functionality, and the description offers no context for selection.
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 destructiveHint=false, establishing safety. The description adds an important behavioral note about sensitivity when file/PDF Base64 is requested, which is not covered by annotations and alerts the agent to potential data exposure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loaded with the endpoint. However, it sacrifices essential parameter details, making it insufficiently informative for an agent. It meets conciseness but not completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0% schema coverage, many siblings), the description is severely incomplete. It fails to explain parameters, return values (though output schema exists), or usage context. No differentiation from similar tools is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description entirely omits parameter explanations. Parameters like includePdf, includeFile, and confirm_read are left undefined. The brief mention of 'file/PDF Base64' hints at includePdf/includeFile but offers no clarity, forcing the agent to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes the HTTP GET method and endpoint path, clearly indicating retrieval of a sent invoice by ID. The verb 'GET' and path '/services/invoice/out/{invoiceId}' make the action explicit, distinguishing it from sibling tools that retrieve by filename or SDI ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Among many siblings (e.g., by filename, by SDI ID), no contextual hints are given. The agent must infer usage solely from the endpoint name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds only 'informational' and 'not accounting advice', which aligns with annotations but doesn't disclose additional behavioral traits such as data freshness, pagination, or rate limits. No 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence. Front-loads purpose and includes a critical disclaimer. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no descriptions, and many sibling tools, the description is too minimal. It doesn't explain return value shape (though output schema exists), date format expectations, or how direction/limit affect results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only vaguely references 'for a period', hinting at fromDate/toDate but not explaining direction or limit. No additional meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns an informational tax summary for a period, with a disclaimer that it's not accounting advice. This gives a good sense of the tool's purpose, though it doesn't explicitly differentiate from sibling tools like tax_breakdown_report or vat_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. The description only mentions 'not accounting advice', which is a disclaimer but not usage context. Sibling tools like aruba_tax_breakdown_report and vat_summary exist, but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's phrase 'Collect structured context' implies a read-only operation, which aligns with annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true). However, it adds no behavioral details beyond what the annotations already convey, such as side effects or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action. It is concise and free of superfluous words. However, it sacrifices essential detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, many siblings, no parameter descriptions) and the existence of an output schema (not provided), the description is incomplete. It omits what the structured context looks like, how the question is used, and does not guide the agent on expected inputs or outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The description fails to explain any parameters, including the crucial 'question' parameter and filters like date_from, date_to, direction, and limit. It does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Collect structured context for an LLM to answer a natural-language invoice question,' which clearly indicates the tool's purpose of gathering context for answering invoice questions. However, it does not differentiate from sibling tools like aruba_get_invoice_full_context or aruba_search_invoices that also retrieve invoice data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention when not to use it or any prerequisites. With many sibling tools performing similar retrieval tasks, an agent lacks direction for choosing this tool.
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 read-only, non-destructive, and idempotent behavior. The description adds only the phrase 'Read-only customer result status', which aligns with annotations but provides no additional behavioral context beyond what is structured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the endpoint, using only two sentences. No fluff, but it could be slightly more efficient by omitting the redundant URL line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks sufficient context for an agent to understand what 'customer result status' represents, especially given the large set of sibling tools. Parameter documentation is missing, and the purpose is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no description for the 'filename' parameter. The description merely echoes the path template without explaining what filename format is expected (e.g., full path, ID, or URL). For a single parameter, the description should clarify its semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a GET request for customer result status and specifies 'read-only', which distinguishes it from write tools. However, it doesn't fully clarify what 'customer result status' means or how it differs from other get tools like get_received_invoice_by_filename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling get tools. It does not explain the context or prerequisites for retrieving customer result status, leaving the agent to guess among similar options.
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 read-only, idempotent, and open-world. The description adds that it is sensitive when file/PDF Base64 is requested, which is useful beyond annotations, but doesn't elaborate on implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loads the endpoint. It is concise but could be structured better with a clear statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema description coverage, the description is incomplete. It does not explain return structure or parameter behaviors, though the output schema exists to cover returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter details beyond noting sensitivity of file/PDF. The parameter names are somewhat self-explanatory, but confirm_read and includeFile behavior remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the HTTP endpoint and implies retrieval of an invoice by SDI ID. It distinguishes from sibling tools like aruba_get_received_invoice_by_filename and aruba_get_sent_invoice_by_sdi_id, but does not explicitly state the verb 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like aruba_get_received_invoice_by_id. With many sibling tools, explicit usage context is missing.
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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds no behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, but could be more structured by front-loading key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description omits details on parameters, prerequisites (e.g., need invoice file), and output format, leaving significant gaps for a tool with 5 parameters and many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 5 parameters (direction, date_from, date_to, limit, confirm_read), failing to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'extract' and resource 'payment terms from invoice XML', clearly distinguishing it from broader tools like aruba_extract_invoice_fields or aruba_parse_invoice_xml.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., aruba_extract_invoice_fields for all fields), no exclusions or context 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 idempotentHint, indicating safe, read-only behavior. The description adds that the tool 'fetches' and 'summarizes', implying a read operation returning a summary. While not contradictory, it does not provide significant new behavioral information beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence that conveys the core purpose without unnecessary words. It is front-loaded and efficient, scoring highly on brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has required parameters and an output schema, the description should explain the parameters and any prerequisites. It fails to do so, leaving the agent to infer. The presence of many sibling tools also demands clearer context for selection. The description is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters with zero description coverage. The tool description does not explain what 'direction', 'filename', or 'confirm_read' mean or how to use them. For an agent to invoke the tool correctly, it needs to know that direction likely indicates invoice direction (sent/received) and filename is the invoice's filename. The lack of parameter clarification severely hinders correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches and summarizes one invoice into a compact structured form. It specifies the resource (one invoice) and the action (fetch and summarize), which distinguishes it from many sibling tools that list or search. However, it lacks explicit differentiation from tools like 'aruba_get_safe_invoice_summary' or 'aruba_get_invoice_full_context'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many alternative invoice-related tools. The description does not mention prerequisites, limitations, or scenarios where this tool is preferred. The agent has no context to decide between this and similar 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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, read-only operation. The description adds a disclaimer about not giving legal/tax advice, which is useful context but does not describe what happens during evaluation (e.g., what checks are performed, what the output looks like). 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant information. It efficiently conveys the core purpose and a key disclaimer. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (but not provided), the description could rely on it for return structure, but it fails to explain the evaluation criteria, expected input constraints, or how results are presented. The tool name suggests risk assessment, but the description lacks details on scope or behavior, leaving the agent underspecified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (documentId, direction, confirm_read) with no descriptions, and the tool description does not mention or clarify any parameter purpose. Schema description coverage is 0%, and the description provides no guidance on parameter values or usage. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates fiscal/technical document risks, with a disclaimer about not providing legal or tax advice. It uses a specific verb and resource, distinguishing it from sibling tools that focus on parsing, validation, or summaries. However, it does not elaborate on what types of risks are assessed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only includes a disclaimer about legal/tax advice, but does not specify context, prerequisites, or exclusions. The agent lacks direction on when this tool is appropriate compared to sibling tools like 'validate_fiscal_document_consistency' or 'document_lifecycle_status'.
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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, non-mutating operation. The description adds no further behavioral context beyond 'Export', which aligns with these annotations. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence. It is front-loaded with the key action, but it could include more detail without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no schema descriptions, and no parameter information in the description, the description is insufficient for an agent to understand what events are exported or how filtering works. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the five parameters (fromDate, toDate, direction, eventTypes, limit) despite 0% schema description coverage. The agent gains no insight into how to use these parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and the resource 'standardized generic fiscal document events', making the primary purpose unambiguous. However, it does not differentiate from sibling tools that also deal with fiscal documents or exports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as other export or search tools in the sibling list. No context on prerequisites or scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering basic safety and behavioral traits. The description adds no further behavioral context but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's purpose. It is appropriately front-loaded with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 6 parameters with no descriptions. The description omits what the period report contains (e.g., which data fields, aggregation level). It feels incomplete for a tool with this parameter count and sibling complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. While parameter names (fromDate, toDate, direction, etc.) provide some clues, 'direction' as a free string without allowed values is unclear. The description fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Export a generic period report as Markdown,' which clearly identifies the verb (export), resource (period report), and format (Markdown). It distinguishes from sibling reporting tools like export_counterparty_markdown and fiscal_period_summary. However, 'generic period report' is somewhat vague, lacking specifics on what data the report includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as aruba_monthly_summary or fiscal_period_summary. There is no indication of prerequisites, when not to use it, or which scenario it best fits.
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 idempotentHint=true, so the description adds minimal value by stating 'compact LLM-friendly summary', which hints at concise output but does not contradict annotations. No additional behavioral insights (e.g., rate limits, side effects) are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly minimal. It states the purpose without any additional context or structure, leaving out important details that could be included in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for an agent to correctly invoke the tool. It lacks parameter semantics and usage guidelines, which are essential given the tool's context among many sibling invoice tools. The description relies entirely on the schema and annotations, which are insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain the meaning of the three parameters (documentId, direction, confirm_read). For example, 'direction' could mean input/output or another concept, but the description offers no clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a clear resource ('compact LLM-friendly summary for one fiscal document'). It distinguishes the tool from siblings like aruba_get_safe_invoice_summary by emphasizing 'compact LLM-friendly', which implies a tailored output for AI consumption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as aruba_summarize_invoice or aruba_get_safe_invoice_summary. There is no mention of prerequisites, exclusions, or comparison with similar 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, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the description's burden is lighter. It adds that the tool is read-only and uses existing wrappers, but does not disclose behavior like error handling, idempotency details, or whether the document is cached/modified. Overall, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no wasted words, and directly states the core function. It is appropriately concise for a tool with annotations, though it could include parameter hints without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (2 required), no schema descriptions, and an output schema, the description lacks essential context. It fails to explain parameter semantics, handling of optional fields, or what the output JSON shape looks like. The agent cannot fully understand the tool's behavior from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must explain parameter meanings to compensate. It does not mention any parameters (documentId, direction, documentType, confirm_read) at all. The agent receives no guidance on what these mean or how to set them, making the tool hard to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'normalize' and the resource 'Aruba fiscal document' into a 'stable JSON shape'. It distinguishes the tool as a normalization step, but does not explicitly differentiate from siblings like parse_invoice_xml or get_invoice_by_id, which have overlapping 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is read-only and uses existing download wrappers, giving some context for when to use it. However, it does not specify when to prefer this over alternatives (e.g., parse_invoice_xml) nor mention any prerequisites or exclusions, leaving the agent with limited 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?
Annotations already declare the tool as read-only, idempotent, and nondestructive. The description adds no further behavioral details, such as whether it returns definitions, context, or usage rules. While consistent with annotations, it misses an opportunity to provide extra transparency about the explanation format or sources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 8 words, which is very concise. However, the brevity sacrifices necessary detail for the parameters. It is front-loaded with the key action and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description fails to explain the tool's behavior for two required parameters. It does not address how the explanation is returned or any prerequisites. For a tool with no schema descriptions, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (code_type, code) with 0% description coverage. The description only gives examples of codes but does not explain what each parameter means or how they relate. An agent cannot infer the correct values for code_type from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to explain common FatturaPA codes, like TD01, N2.2, MP05, or RF19. The verb 'explain' combined with specific examples makes the purpose unambiguous. Among many sibling invoice tools, this one is distinct by focusing on code explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like aruba_explain_sdi_notifications. The description does not mention exclusions or conditions. An agent might not know if this tool is limited to the listed code types or covers all FatturaPA codes.
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, destructiveHint=false, idempotentHint=true, so the tool is clearly safe and non-destructive. The description adds no further behavioral context beyond the one-line purpose, but given the annotations, it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that conveys the main purpose efficiently. It is front-loaded and contains no filler, though it could benefit from additional details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 paramers and no descriptions, the description is insufficient for proper tool usage. It does not hint at parameter roles or expected output, leaving a significant gap, especially given the number of siblings and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The tool description does not explain any of the 6 parameters (direction, date_from, date_to, expected_final_status, limit, confirm_read), so the agent has no idea what they do or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds invoices missing expected final SDI notifications, which is a specific verb and resource. It differentiates from sibling tools like aruba_find_duplicate_invoices or aruba_find_invoices_without_pdd by focusing on missing notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not specify under what conditions to use it or what the prerequisites are, leaving the agent without context for decision-making.
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, destructiveHint, idempotentHint, openWorldHint. The description adds that the tool is 'Sensitive when XML/PDF/notifications/PDD are requested', which is useful beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with core purpose and key extras. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description lacks guidance on required parameters (direction, filename) and fails to explain when to use this over sibling tools. For a complex tool with 7 parameters and many siblings, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description only hints at parameter meanings through terms like 'XML/PDF/notifications/PDD'. It does not describe 'direction', 'filename', or 'confirm_read', leaving the agent to infer. The composite nature is noted but not mapped to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it aggregates invoice payload, parsed XML, notifications, timeline, and optional PDD, indicating a composite 'get full context' function. However, it does not explicitly differentiate from sibling tools like aruba_get_received_invoice_by_filename, which is similar but more granular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this composite tool versus individual get tools. The description mentions 'read-only endpoints' but doesn't specify prerequisites or scenarios where this tool is preferred over 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, destructiveHint, idempotentHint, and openWorldHint. The description adds 'read-only' aligning with annotations but does not disclose additional behavioral traits like pagination, date ranges, or aggregation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and waste-free, conveying the core purpose without superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and four parameters, the description does not explain what the reconciliation summary comprises, how parameters affect it, or how it compares to siblings. It only gives a high-level overview, leaving the agent to infer details from schema and tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no information about the four parameters. Their titles (Date From, Date To, Group By, Limit) are minimally informative, but the tool's description does not clarify expected formats, valid values for group_by, or behavior of limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only reconciliation summary between sent and received Aruba invoices, distinguishing it from many sibling tools that focus on individual invoices or other reports. However, it could be more specific about the nature of the reconciliation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like aruba_compare_invoice_totals or aruba_monthly_summary. The description does not include when to use or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent, and open-world hints. The description adds 'for external consumers' but does not provide additional behavioral context beyond what annotations already offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose. It is front-loaded but could be slightly expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (2 required), no parameter descriptions, and an output schema present, the description fails to explain how to use the tool effectively. The agent lacks context on parameter meaning and expected output, despite the output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameters, but it does not. The three parameters (documentId, direction, confirm_read) are left entirely undefined, leaving the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'return' and the resource 'matching hints', and specifies it's for external consumers. It distinguishes from siblings by focusing on generic matching hints, which is a unique function among many invoice and counterparty tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. It only states the basic 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 provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the description adds no further behavioral context. It could have mentioned that the tool relies on previously retrieved XML files, but it doesn't. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. It efficiently conveys the core purpose and avoids irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, required fields) and the availability of an output schema, the description is insufficient. It omits crucial context about the meaning of direction, how to specify fields, and the role of confirm_read. This forces heavy reliance on parameter names and external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, and the description does not explain any parameter. The meaning of direction, filename, fields, or confirm_read is entirely left unspecified, forcing the agent to infer from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (extract), the resource (precise fields from a FatturaPA XML), and the context (returned by Aruba). It is specific and distinguishes from siblings like aruba_parse_invoice_xml which returns the entire parsed XML.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as aruba_summarize_invoice or aruba_parse_invoice_xml. The description does not include any selection criteria or when-not-to-use advice.
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, destructiveHint, idempotentHint, and openWorldHint, which cover safety and read-only nature. The description adds that it's a GET and returns multiseller details, aligning with annotations but not adding beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) with no unnecessary words, effectively communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ID lookup with one parameter and good annotations, the description is adequate but not rich. It does not explain what 'multiseller details' include, and given the presence of an output schema, the description could add more context about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only implies the 'id' parameter is a path parameter for the multiseller ID. No additional details on format, range, or validation rules are provided, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the HTTP method and path, and indicates it returns read-only multiseller details. It distinguishes from the sibling tool aruba_list_multicedenti by focusing on a specific ID lookup. However, it could be more explicit about what a 'multicedente' is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like aruba_list_multicedenti or other invoice tools. The agent is left to infer from the tool name and path that it retrieves a single entity by ID.
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 idempotentHint=true. The description adds value by noting that the tool is 'sensitive when file/PDF Base64 is requested,' warning about data sensitivity beyond what annotations capture. This is useful behavioral context. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence) but lacks critical information such as purpose statement and parameter explanations. It is concise but incomplete, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return value details are not needed. However, the description does not cover basic behavior like what happens with different parameter combinations (e.g., includeFile=false), error conditions, or the purpose of confirm_read. Given the complexity of 4 parameters, more context is needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The only parameter-related note is about file/PDF sensitivity, which hints at includePdf/includeFile behavior but does not explain any parameter meaning. 'confirm_read' remains ambiguous, and no value constraints or usage patterns are described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name and description together indicate the tool retrieves a sent invoice by filename. The description includes the HTTP verb and resource path, giving specific action and resource. However, it does not distinguish from siblings like aruba_get_sent_invoice_by_id or aruba_get_received_invoice_by_filename, missing a differentiation statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as by-ID or by-SDI-ID tools. No context about prerequisites, when to select this tool, or when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, indicating safe, repeatable execution. The description adds no behavioral context beyond the core action, such as what happens on mismatch (error vs. warning) or if totals are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundancy. It could be slightly improved by adding a brief second sentence on output, but remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description should hint at what the comparison returns (e.g., a boolean, a discrepancy report). It lacks this context, leaving the agent unsure what to expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the 'xml_base64' parameter. It only generically implies the input is an XML document containing totals, failing to specify that it must be base64-encoded or the expected structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Compare' and the specific resources 'document total with line and VAT totals.' It distinguishes this tool from siblings like 'aruba_extract_invoice_fields' or 'aruba_detect_invoice_anomalies' by focusing on a specific consistency check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives (e.g., 'aruba_validate_invoice_xml_structure'). It does not mention prerequisites, such as needing to have extracted invoice fields first, or whether it should be used after parsing.
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, destructiveHint, idempotentHint, and openWorldHint. The description adds the endpoint and basic purpose but does not elaborate on behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence, but could be more informative while remaining brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and an output schema, the description is minimally adequate but does not explain the scope of 'account information' or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description mentions 'account information' but is vague about what fields are returned. Baseline 3 is appropriate as the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves account information via GET /auth/userInfo. It is distinct from sibling tools that focus on invoices or documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It is a simple read operation, but context about authentication or prerequisite steps is missing.
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, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds the behavioral trait 'Sensitive when file/PDF Base64 is requested,' which alerts to potential data sensitivity beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the HTTP method and path, which is unnecessary for MCP. The sensitivity note is valuable but lacks structure. It is concise but could better organize information about parameters and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, many siblings, and a provided output schema, the description is incomplete. It does not explain the return value, parameter functions, or how this tool fits into the broader workflow. The minimal text leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at the includePdf and includeFile parameters via the sensitivity note but does not explain them or the confirm_read parameter. Most parameters remain undefined in meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the HTTP method and path, indicating it retrieves a received invoice by ID. The mention of sensitivity when file/PDF Base64 is requested adds specificity. It distinguishes from siblings like aruba_get_received_invoice_by_filename and aruba_get_sent_invoice_by_id by focusing on invoice ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many siblings for retrieving invoices by different identifiers (e.g., filename, SDI ID), the description fails to provide context for appropriate selection.
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, etc. Description adds that sensitive values are redacted, which is a behavioral trait not covered by annotations. However, it doesn't mention how redaction works or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero wasted words, front-loaded with purpose and key trait. Ideal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite output schema existing and annotations covering safety, the absence of parameter descriptions and usage context leaves the tool under-specified for correct invocation. Agent needs parameter hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description provides no explanation for the three parameters (direction, filename, confirm_read). Agent has no clue what these mean or how to set them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (summarize), resource (one invoice), and key differentiator (sensitive values redacted). This distinguishes it from sibling tools like aruba_summarize_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like aruba_summarize_invoice or aruba_redact_invoice. The description does not mention usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description 'Return ... statistics' is consistent but adds no additional behavioral context beyond what is already conveyed by annotations. For a tool with such thorough annotations, this is adequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Return local invoice index statistics.' It is maximally concise with no wasted words, and every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, good annotations, and an output schema), the description is mostly complete. The term 'local' could be ambiguous, but the sibling tools and output schema likely provide sufficient context. It does not elaborate on what constitutes 'index statistics', but that is reasonable for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is trivially 100% covered. The description adds the phrase 'local invoice index statistics', which provides context about the return value but is not necessary for parameter understanding. The baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Return' and specifies the resource 'local invoice index statistics'. This clearly indicates the tool's purpose: to retrieve statistical data about the invoice index, distinct from sibling tools like 'aruba_search_invoice_index' which focus on searching. However, it does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites or scenarios where this tool is preferred, leaving the agent to infer usage from the resource name.
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 'sensitive' and 'Base64 read' context beyond annotations (readOnlyHint, etc.), informing the agent about data sensitivity and encoding. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it sacrifices important parameter details. It is front-loaded and efficient for purpose, but could be restructured to include parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description minimally covers the tool's behavior. However, it omits operational context (e.g., what 'sensitive' means for handling) and does not explain the response format beyond 'Base64 read'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the 'filename' or 'confirm_read' parameters. The tool purpose is clear, but parameter meanings are left to the schema titles, which are insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the resource ('sent notification'), action ('read'), and encoding ('Base64'), distinguishing it from sibling tools like 'get_received_notification_by_filename'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., 'get_received_notification_by_filename' or 'get_sent_notifications_by_invoice_filename'). The description only hints at sensitivity but lacks decision criteria.
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 that it 'writes only to ARUBA_INDEX_DB_PATH and never modifies Aruba,' which clarifies the non-destructive nature beyond annotations (idempotentHint=true, destructiveHint=false). However, no information about authentication, rate limits, or exact write behavior is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the main purpose front-loaded in the first sentence. Every word contributes value, and there is no redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no schema descriptions, and an output schema not explained), the description is insufficient. It does not explain return values, what 'sync' entails (full or incremental), or how parameters affect behavior. Annotations partially cover safety, but parameter guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation for the 7 parameters (direction, date_from, date_to, etc.). Schema description coverage is 0%, so the description must compensate, but it fails to do so. Parameters remain opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build/update a local SQLite index from read-only Aruba GET data.' This is a specific verb-resource combination and distinguishes it from siblings, which are mostly query or retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for indexing data locally, but it does not explicitly state when to use it versus alternatives like aruba_search_invoices or aruba_get_index_stats. No guidance on when not to use or prerequisites is provided.
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, destructiveHint=false, and idempotentHint=true. The description adds 'Sensitive Base64 ZIP read', which warns about sensitive data being read and the output format (Base64). This provides useful context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line stating the endpoint and a brief note. It is front-loaded with the most essential information. However, it could be slightly improved by adding a brief explanation of parameters without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the number of similar sibling tools, the missing parameter guidance, and the sensitive nature of the operation (Base64 ZIP), the description lacks completeness. It does not explain when to use confirm_read, what the ZIP contains, or any prerequisite conditions. An agent would have to guess or rely on external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (filename, confirm_read) but the description provides no explanation of their meaning or usage. Schema description coverage is 0%. The agent must infer parameter semantics from names alone. For a required string parameter like filename, guidance on the expected format is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the HTTP method (GET), endpoint path, and that it retrieves a sent invoice ZIP. It specifies 'Sensitive Base64 ZIP read', which adds valuable context. This clearly distinguishes it from sibling tools like aruba_get_received_invoice_zip_by_filename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs. alternatives. The sibling tools indicate many related invoice retrieval functions (by filename, by ID, received vs. sent), but the description does not differentiate usage scenarios. Usage is implied by the endpoint name and tool name.
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, destructiveHint, idempotentHint, and openWorldHint as true, indicating safe, non-destructive, idempotent behavior. The description adds context: the tool redacts the payload for safety. No contradictions exist, and the description aligns 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, clear and front-loaded. It could include brief parameter descriptions without losing brevity, but overall it is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) which may explain return values, so the description need not cover that. However, with 2 parameters and numerous sibling tools, more context on when to redact versus other safety-related tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate, but it does not describe the 'invoice' object or 'redaction_level' string. The schema provides no details beyond types and a default. Without parameter semantics in the description, an agent lacks guidance on how to use these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return a redacted invoice payload for safer LLM analysis.' It specifies the verb ('return'), the resource ('redacted invoice payload'), and the goal ('safer LLM analysis'). Among all sibling tools, this is the only one focused on redaction, making it easily distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use before LLM analysis but provides no explicit guidance on when to prefer this over alternatives like aruba_get_safe_invoice_summary or aruba_extract_invoice_fields. No when-not or exclusion criteria are given.
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, destructiveHint=false, idempotentHint=true. The description adds the key behavioral trait that these are 'non-official' checks, which implies they may not be authoritative and complements the safe-read nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler words. Every term adds value: 'Run', 'non-official', 'sanity checks', 'Base64 FatturaPA XML'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema exists, so the description need not detail return values. However, the term 'sanity checks' is vague; the description could briefly mention what kind of checks (e.g., schema compliance, required fields) to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (xml_base64) with 0% schema description coverage. The description clarifies it is a Base64-encoded FatturaPA XML, which adds significant meaning beyond the schema's generic title 'Xml Base64'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Run'), the resource ('Base64 FatturaPA XML'), and the nature ('non-official sanity checks'). This distinguishes it from sibling tools like aruba_parse_invoice_xml or aruba_extract_invoice_fields which have different 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for quick, non-official structural checks, but it does not explicitly state when to use it over alternatives or when not to use it. No usage exclusions or context are provided.
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 provide readOnlyHint, idempotentHint, etc. The description adds value by stating what is NOT returned (access_token, refresh_token), which is useful behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb 'Return' and clearly communicates the tool's function without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, rich annotations, and an output schema, the description is fully adequate. It tells the agent exactly what the tool does and what it does not return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% trivially. The description appropriately doesn't need to add parameter info. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns local auth cache status and explicitly notes it does not include access_token or refresh_token, which is a unique and specific purpose. It distinguishes itself from sibling tools that focus on invoice operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose is simple, and annotations indicate it's safe, but the description does not mention context or exclusions.
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

aruba-fatturazione-elettronica-mcp MCP server

Copy to your README.md:

[![aruba-fatturazione-elettronica-mcp MCP server](https://glama.ai/mcp/servers/mnbro/aruba-fatturazione-elettronica-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mnbro/aruba-fatturazione-elettronica-mcp)

Score Badge

Copy to your README.md:

[![aruba-fatturazione-elettronica-mcp MCP server](https://glama.ai/mcp/servers/mnbro/aruba-fatturazione-elettronica-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mnbro/aruba-fatturazione-elettronica-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mnbro/aruba-fatturazione-elettronica-mcp'

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