moneybird-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each resource has a clear list/get pair, and document types are explicitly named, so most tools are easy to tell apart. The main ambiguity is between get_sales_invoice and the two find_sales_invoice_by_* lookup tools, plus a few similarly filtered list_* document tools, but descriptions resolve these.
Naming Consistency4/5
The dominant verb_noun pattern is consistent: list_*, get_*, find_*_by_*, download_*_pdf. A few deviations exist, most notably moneybird_connection_status which is a noun phrase rather than a verb-led action, but the naming is generally predictable.
Tool Count2/5
52 tools is well beyond the 25+ threshold and feels heavy for an MCP surface, even for a broad domain like Moneybird. Many tools are mechanical list/get pairs that could be consolidated without losing clarity.
Completeness2/5
The server is almost entirely read-only: it lists and retrieves many entities but offers no way to create, update, delete, send, or pay invoices, contacts, purchases, or time entries. This leaves common Moneybird workflows dead-ended despite the wide read coverage.
Average 4/5 across 52 of 52 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds only the single-result qualifier and says nothing about not-found behavior, scoping, or response shape, which is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler or structural waste. It could be slightly more informative without becoming bloated, but it is appropriately concise for a simple get operation.
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 read-only getter with two parameters and no output schema, the description is minimally viable. However, it does not mention how to discover valid ledger_account_ids, what happens when the ID is not found, or that list_ledger_accounts should be used for enumeration, leaving some operational context implicit.
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 only 50% because ledger_account_id has no schema-level description. The tool description does not explain the identifier's meaning or relationship to administration_id, so it fails to compensate for the low coverage. The administration_id parameter is already well-described in 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, 'Retrieve', and resource, 'a single ledger account', which clearly states what the tool does. The word 'single' distinguishes it from the sibling list_ledger_accounts tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus list_ledger_accounts or other get_* tools. An agent must infer from the name that this is for fetching one known account, and no alternative or exclusion is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds one piece of behavioral context: the response includes lines and payments. This is useful but does not cover auth, error, or response-shape details; there is 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?
A single sentence with no filler. The core action, resource scope, and included content are front-loaded and every word earns its place.
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?
For a low-complexity read-only retrieval with strong annotations, the description is nearly sufficient: it names the resource and key included content (lines, payments). The only meaningful omission is richer return/error context, but no output schema exists to fill that gap and the tool is simple enough that this is a minor deficiency.
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 50%; external_sales_invoice_id has no schema description and the tool description does not clarify it beyond its self-explanatory name. administration_id is already described in the schema, so the description contributes no additional parameter 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 states a specific verb and resource: 'Retrieve one external sales invoice, including its lines and payments.' It clearly differentiates from siblings like list_external_sales_invoices (by 'one') and get_sales_invoice (by 'external').
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 choose this tool over list_external_sales_invoices or alternative lookup tools like find_sales_invoice_by_invoice_id. The singular 'one' weakly implies a direct-id lookup, but no explicit when/when-not or alternative routing exists.
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 cover the safety profile: readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful return-content context (includes lines and next invoice date), but it does not disclose error behavior, permissions, or any side effects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: it leads with the action and resource, then gives the most useful returned details. Every word earns its place, with no repetition of the tool name or filler.
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?
For a simple read-only get-by-id tool, the description plus annotations and schema are mostly sufficient. It would be more complete with a pointer to list_recurring_sales_invoices or explicit not-found behavior, but those are minor gaps given the low complexity of the operation.
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 only 50%: the required recurring_sales_invoice_id has no schema description, and the tool description does not clarify how to obtain or format it. The description adds no parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Retrieve), a specific resource (recurring invoice schedule), and a singular scope that distinguishes it from list_recurring_sales_invoices. It also names key returned content (lines, next invoice date), so an agent can identify what this tool does at a glance.
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 about when to use this tool versus list_recurring_sales_invoices, nor how to discover a valid recurring_sales_invoice_id before calling. The description simply says what the tool does, leaving usage context to be inferred from sibling tool names.
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 non-destructive behavior, so the safety profile is established. The description adds a meaningful behavioral detail: calling without an id retrieves the administration default. It does not go beyond that, but for a simple read operation this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the action and resource, then states the key default behavior. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, two optional parameters, and full schema coverage, the description plus annotations provide enough context to call the tool correctly. The absence of an output schema is not a gap for this simple retrieval tool, though a bit more context about the return shape would rounded it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both identity_id and administration_id. The description adds no paramater-specific meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Retrieve one identity.' It also clarifies the important default behavior when no id is given, which distinguishes it from list-style tools like list_identities. The purpose is immediately understandable.
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 about when to use this tool versus alternatives such as list_identities or get_contact. The description implies a single-identity use case but does not state exclusions or alternative selection 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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's safety burden is reduced. It adds useful return-field context, but it does not disclose behavior for unknown ids, response envelope, or administration scoping beyond what the schema already says.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the action and object front-loaded, followed by the key returned fields. There is no filler or redundant restatement of schema or annotation data.
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 read-by-id tool, the description covers the core operation and return fields, and the annotations cover safety. However, there is no output schema and no guidance on not-found/error behavior or multi-administration use, so the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: administration_id is described in the schema, but project_id has no description. The tool description adds little beyond restating 'by id' and does not compensate by explaining the project_id format or when administration_id is needed.
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 names a specific verb ('Retrieve'), a clear resource ('a single project'), and an unambiguous selector ('by id'), which distinguishes it from list_projects and other get_* siblings. It also states the returned fields ('name, state and budget'), removing ambiguity about the operation's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Retrieve a single project by id' implies the appropriate use case: when the caller already knows a project id and wants one project. However, it does not explicitly say when to prefer this over list_projects or how administration_id should be chosen when multiple administrations exist.
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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds context about the relationship between ledger accounts and bookings/invoice lines, but says nothing about pagination, ordering, filtering, or response contents. With annotations covering the core behavior, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The first sentence states the core operation, and the second provides relevant context about how ledger_account_id is used elsewhere. Every word earns its place.
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 a single optional parameter, a simple list operation, and annotations that cover safety and idempotency, the description is sufficient for basic invocation. It does not mention how to fetch a single ledger account or how this differs from related list tools, but those are not essential for a straightforward listing endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, administration_id, is fully documented in the input schema with 100% coverage. The description does not need to add parameter details, and the baseline of 3 applies.
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 specific action and resource: 'List the chart of accounts.' It adds useful context by noting that bookings and invoice lines reference these accounts by ledger_account_id. However, it does not differentiate this tool from the sibling list_financial_accounts or get_ledger_account, so it stops short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case: use this tool to find ledger accounts referenced by bookings and invoice lines. There is no explicit when-to-use guidance and no mention of alternatives such as get_ledger_account for a single account or list_financial_accounts for a different account type.
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 readOnly, idempotent, and non-destructive. The description adds the nuance that linked payments and ledger bookings are 'currently' linked, implying they may change over time, but it does not cover error behavior, authorization, or data freshness. 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?
One tight sentence that front-loads the core action and immediately specifies the return scope. No filler or redundant phrasing.
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?
For a read-only get-by-id tool, the description tells the agent what it will receive and annotations cover safety. It does not describe not-found behavior or the output structure, but no output schema is declared and this is a minor gap for a simple fetch.
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 50%; financial_mutation_id has no schema description and the description only restates 'by id' without format or semantics. administration_id is documented in the schema but not reinforced in the description. The description fails to compensate for the undocumented id parameter.
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?
States it retrieves one bank transaction by id, a specific verb and object, and specifies that linked payments and ledger bookings are included. This clearly distinguishes it from list_financial_mutations and from get_payment.
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 when you have a financial_mutation_id and need a single transaction with its current links, but it does not explicitly contrast this with list_financial_mutations or get_payment. No alternatives or exclusion conditions are named.
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 carry the safety profile (readOnlyHint: true, idempotentHint: true, destructiveHint: false), so the bar is lower. The description adds the two-mode lookup distinction but discloses nothing about parameter precedence, mutual exclusivity, or return behavior. Modest added context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 12-word sentence with the verb front-loaded. No filler, no repetition of the title, and every word adds information. Ideal for a simple get-style tool.
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?
For a 3-parameter, zero-required read tool with a rich annotation set, the description covers the core invocation adequately. The remaining gaps — no output schema so the return value is unspecified, and the product_id/identifier relationship not fully disambiguated — are minor for a simple get 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?
Schema description coverage is only 33%, leaving product_id and identifier undocumented in the schema. The description compensates by decoding both: 'Moneybird id' maps to product_id and 'identifier' is the custom identifier field. It stops short of clarifying whether the two are mutually exclusive or which takes precedence when both are supplied.
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 specific verb ("Retrieve"), resource ("product"), and the two lookup keys ("Moneybird id" or "identifier"). It clearly implies single-item retrieval, which distinguishes it from the list_products sibling, though it does not explicitly name that alternative.
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?
Usage context is implied: call this when you already have a product's Moneybird id or its custom identifier, rather than listing products. However, there is no explicit when/when-not language and no alternative tool is named, leaving the routing decision to inference.
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 convey readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds useful return-field context but does not disclose behavior for missing ids, administration scoping, or any edge-case handling. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the operation and resource, no filler or redundant content. Every word earns its place.
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?
For a simple read-only fetch with one required parameter and annotations covering the safety profile, the description is nearly complete. It names the return fields in lieu of an output schema. The main missing context is explicit routing to the list sibling and error/not-found behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; administration_id is documented in the schema, but purchase_transaction_id is not. The description's 'by id' adds little beyond the parameter name and does not clarify the id's format, type constraints, or how administration_id relates to the lookup.
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 states a specific verb and resource: 'Retrieve one purchase transaction by id,' and also names the returned attributes (amount, state, document it pays). This clearly differentiates it from the sibling list_purchase_transactions by emphasizing singular retrieval 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a specific purchase transaction is needed by id, but it does not explicitly state exclusions or direct the agent to list_purchase_transactions when the id is unknown. Some usage context is conveyed, but alternatives are not named.
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 cover readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is well established. The description adds useful context about the returned contents, but does not disclose behavior for missing subscriptions or error conditions. 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 concise sentence, front-loaded with the action and resource, and includes the most relevant detail about the returned data. There is no filler, repetition, or unnecessary background.
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?
For a simple read-only retrieval with rich annotations and a documented optional administration_id, the description covers what is retrieved and the key return contents. It lacks an explicit pointer to list_subscriptions or error behavior, but these are minor given the tool's low 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 only 50%, so the description was expected to add parameter meaning, but it only describes the output contents, not the parameters. subscription_id is self-explanatory and administration_id is already documented in the schema, leaving the description with no added parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieve'), a precise resource ('one subscription'), and the key contents (product, billing cycle, recurring invoice). The singular 'one' clearly differentiates it from list_subscriptions among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one subscription' implies this is for fetching a single record versus listing, but the description does not explicitly mention when to prefer this tool over list_subscriptions or any other alternative. Usage context is left to inference rather than being stated directly.
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, idempotentHint=true, and destructiveHint=false, so the description only needs to add extra behavior. It does by noting the response includes attachments, a non-obvious detail not inferable from the name or schema. There is 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?
A single ten-word sentence with no filler. The subject, verb, resource, and key qualifier (attachments) are all front-loaded, making it easy to scan.
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?
For a simple get-by-id tool with safety annotations and one required parameter, the description covers the core behavior and return characteristic (attachments). However, it omites a pointer to list_typeless_documents for id discovery and any detail on how attachments are represented, leaving minor 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 only 50%; typeless_document_id has no description. The tool description merely says 'by id,' which does not add meaning beyond the parameter name and does not point to list_typeless_documents as the source of valid ids. administration_id is already well documented in 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 the specific verb 'retrieve' with the resource 'typeless document' and adds the scoping qualifiers 'by id, with its attachments.' This clearly distinguishes it from list_typeless_documents and other get_* 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 gives no guidance on when to use this tool versus alternatives. It does not mention list_typeless_documents for discoverying ids or contrast with get_general_document/get_general_ournal_document, so usage must be inferred from the tool name and standard get-by-id pattern.
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?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description adds a meaningful non-obvious behavior: only active schedules are returned unless the filter overrides this default. This is useful context that is not present in the annotations or visible from the tool name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action and resource are front-loded, and the only additional sentence adds a meaningful default-behavior caveat. Nothing in the description is redundant or wasteful.
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 read-only list action, the description is mostly sufficient: it identifies the resource and the active-only default, and the schema documents parameters. However, with no output schema and no guidance on how to choose this over sibling list/get tools, the description is only minimally complete rather than fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not discuss parameters, but the input schema covers all 4 parameters with 100% description coverage, including detailed guidance on filter behavior. The one behavioral note about active-only schedules is reflected even more precisely in the filter parameter's schema description, so the description adds no extra parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the specific resource ('recurring invoice schedules'), which distinguishes it from regular sales invoice lists and from the singular get_recurring_sales_invoice tool. The phrase 'schedules' also clarifies that this returns schedule definitions, not generated invoices.
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 explicit guidance about when to use this tool versus the many sibling tools such as list_sales_invoices or get_recurring_sales_invoice. The only usage-related note is the default active-only behavior, which is more of a behavior disclosure than a selection guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description does not contradict them. Its added context — that matching is on a user-set reference such as a PO/project code — is useful, but it discloses nothing about result shape, multiple matches, or not-found behavior, which are the primary behavioral unknowns for a look-up tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 18-word sentence that fronts the verb and resource before the clarifying example. There is no repetition of the title, no restating of annotations, and every word earns its place.
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?
Adequate for a simple two-parameter read operation, but there is no output schema and no statement of what the call returns (single invoice vs list) or what happens when the reference is unknown or duplicated across invoices. That is the one material gap an agent would hit when deciding to call this tool or parsing its response.
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?
Schema coverage is 50%: administration_id is fully documented (default behavior plus discovery hint), but reference has no schema description. The tool description compensates by defining reference as the value the user set and giving two concrete examples (PO, project code), adding real meaning to the parameter that needed it.
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 names a specific verb, resource, and lookup key: 'Look up a sales invoice by the `reference` you set on it.' The phrase 'the reference you set on it' signals a user-defined key, which clearly differentiates this from siblings like get_sales_invoice and find_sales_invoice_by_invoice_id that search by system identifiers. An agent can select this tool without opening any schema.
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 example 'e.g. a PO or project code' implies the natural use case: the agent has a customer-supplied reference rather than an invoice ID. However, the description never states when not to use it or names the ID-based alternatives, so the routing decision is left to inference rather than stated explicitly.
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 communicate that this is read-only, idempotent, and non-destructive. The description adds useful behavioral context by stating the response includes attachments and notes, which is especially valuable given there is no output schema. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, the target resource, the lookup method, and what is included in the result. There is no fluff or unnecessary repetition.
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?
For a simple read-only operation with only two parameters, the combination of schema, annotations, and description is sufficient to call the tool correctly. The description names the expected contents of the result, partially compensating for the missing output schema. More sibling differentiation would improve completeness, but the core invocation context is clear.
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 required general_document_id has no schema description, and the description's phrase 'by id' only weakly confirms it is the lookup key. The administration_id parameter is well-described in the schema, but the description does not add any meaning to it. With only 50% schema description coverage, the description does not sufficiently compensate for the undocumented required parameter.
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 names a specific verb and resource: 'Retrieve one general document by id'. It also clarifies the scope by saying the result includes attachments and notes, which helps distinguish it from broader list tools and other document-type getters like get_typeless_document.
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 appropriate use case: the agent has a specific general_document_id and wants that single document. However, it does not explicitly explain when to prefer this over list_general_documents, get_typeless_document, or other sibling retrieval tools, and it gives no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only, idempotent, non-destructive behavior. The description adds no behavioral details beyond listing/searching, and does not mention pagination, archived handling, or open-world result semantics. This is acceptable given the annotations but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence front-loads the tool's purpose and then explains the two search modes. There is no fluff; every clause earns its place.
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?
For a list tool with strong annotations and a fairly detailed schema, the description plus schema cover the main parameters well. The only minor gap is include_archived, which has no schema description and is not addressed in the description, though its name is self-explanatory.
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?
Schema description coverage is high (83%), and the description enriches the query parameter by listing the specific fields searched (name, email, phone, customer id, tax number, address) and characterizes filter as structured narrowing. This adds meaning beyond the bare schema text.
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?
States a specific action ('List or search') and resource ('contacts') and clarifies the scope as customers and suppliers. This is clear but does not explicitly distinguish itself from the sibling get_contact, so it falls just short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use query (free-text search across specified fields) vs filter (structured narrowing). It does not explicitly state when to prefer list_contacts over get_contact or other sibling tools, but the general usage context is clear.
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 operation as read-only, idempotent, non-destructive, and open-world. The description adds useful context by clarifying that 'document styles' means invoice and estimate layouts and scoping the operation to an administration, but it adds no details about pagination, response shape, or default behavior beyond what the schema already states.
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 clear sentence that front-loads the action and resource, then adds the useful clarifying parenthetical. Every word earns its place, and there is no redundant filler given the title and schema already present.
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?
For a simple, read-only list tool with one optional parameter, the description is sufficient. It names the resource, clarifies what counts as document styles, and scopes the operation to an administration. The schema handles parameter defaults, and the annotations handle safety behavior, so nothing critical is missing for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents the optional administration_id parameter, including its default value and how to discover available ids. The description only restates the administration scope ('of the administration') without adding new parameter semantics, so it does not go beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') on a specific resource ('document styles') and adds the clarifying parenthetical that these are invoice and estimate layouts. This distinguishes the tool from sibling list/get tools by the exact resource it targets.
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 this tool is for retrieving layout/style definitions for invoices and estimates, but it does not explicitly state when to use it instead of related tools like list_sales_invoices or list_estimates. No alternative tools or exclusion conditions are mentioned, so the agent must infer the appropriate 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, idempotentHint=true, and destructiveHint=false, so the safe read-only profile is covered. The description adds the optional narrowing behavior but doesn't disclose pagination behavior, default ordering, or whether inactive products are included by default. The per_page field hints at pagination, but the description itself doesn't say how pages behave.
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?
One sentence, front-loaded with the primary action and resource, followed by concise optional qualifiers. Every word earns its place; no restating of the title or redundant detail.
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 read-only list tool with annotations covering safety and schema covering half the parameters, the description is adequate but not complete. It doesn't mention pagination behavior, default listing scope (active only or all), or how query and currency interact. An agent could call it correctly, but might not know whether to expect all products or only active ones by default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the schema already documents page, per_page, and administration_id. The description adds only that query and currency are free-text/currency narrowing options, which is modest value beyond the schema parameter names. It doesn't clarify the format of currency (e.g., ISO 4217) or what query matches against, so it doesn't fully compensate for the two undocumented 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 uses a specific verb ('List') with a clear resource ('the product catalogue') and explicitly names the two optional narrowing dimensions (free-text query, currency). 'List products' alone would have been tautological, but the full sentence adds real operational scope and distinguishes it from sibling get_product (which retrieves a single product).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when to use the tool ('List the product catalogue, optionally narrowed by free-text query or currency'). It implies this is the collection-level counterpart to get_product, though it does not explicitly name get_product or state when not to use it. Sibling context makes the collection vs. single-item distinction clear enough.
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?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses concrete behaviors: results are returned newest first, filtering supports a defined set of keys, and certain `state` values only apply to purchase invoices and receipts. This adds useful operational context without contradicting any annotation.
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 front-loads the core action and ordering, then compactly lists the filter keys. It is dense but not wasteful; the only minor inefficiency is that it duplicates filter syntax already present in the schema.
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?
With zero required parameters, full schema coverage, and rich annotations, the tool can be invoked correctly using the description plus schema. The description covers ordering and filter semantics, while the schema covers pagination and administration defaults. It does not describe the return payload, but that is a minor omission for a list operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of all parameters, including a detailed explanation of the `filter` syntax, defaults, and valid values. The description repeats the filter keys but does not add meaning beyond what the schema already provides, so the baseline of 3 applies.
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 opens with 'List purchase invoices' and clarifies the resource as 'bills received from suppliers', distinguishing it from sales invoices. It also specifies 'newest first', giving the operation clear scope and a distinct, non-tautological purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys how to narrow results via the `filter` parameter and lists the supported keys. However, it never explicitly tells the agent when to use this tool over siblings like `get_purchase_invoice` or `list_receipts`, so usage routing is implied rather than explicit.
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 safety profile is covered. The description adds the scoping detail that exactly one contact is returned and that either identifier can be used, but it does not disclose return format or error behavior. This is acceptable but not richly transparent.
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?
One clear sentence with no filler. The core lookup behavior and both identifier options are front-loaded and immediately actionable.
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?
For a simple read-only lookup, the description plus fully annotated schema covers the essential invocation details. There is no output schema, so a brief note about the returned contact object would have been helpful, but the absence is not a major gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; contact_id and customer_id are already documented in the schema. The description restates the distinction between the Moneybird id and the customer's own reference, which adds minor clarity, but it contributes little 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 states a specific action ('Retrieve a single contact') and names the two lookup keys (Moneybird id and customer_id reference). This clearly distinguishes it from sibling tools like list_contacts, which retrieves multiple contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for fetching one known contact by identifier rather than for listing or searching contacts. It does not explicitly name list_contacts as the alternative for broad queries, but the single-contact framing plus identifier parameters gives adequate usage context.
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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the relevant behavioral context that the response includes debit and credit entries, which is useful beyond the annotations. No contradiction or misleading behavior is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant words. It front-loads the main action and the key return content, making it highly efficient for an agent to parse.
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?
For a simple read-only getter, the description is adequate: it states the purpose, the required id, and the returned entries. It does not mention error cases or how to discover the id from a list tool, but these are minor for a tool with strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with administration_id documented but general_journal_document_id not. The description's 'by id' adds little to the required parameter beyond its self-explanatory name, so it does not fully compensate for the missing schema documentation.
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 retrieves one general journal document by id and includes its debit and credit entries. This distinguishes it from list_general_journal_documents and get_general_document without requiring the agent to open any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single general journal document id is available, but it does not explicitly state when to prefer this tool over siblings or mention that ids can be obtained from list_general_journal_documents. No exclusions or alternatives are given, leaving usage somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds value by disclosing the scope (which record types the custom fields belong to) and the purpose of the returned ids, but it does not describe pagination, ordering, or response shape, and there is no output schema to fill that gap.
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 of roughly nineteen words that front-loads the verb and resource and packs scope and purpose without fluff. Every element earns its place and nothing is redundant with the schema or annotations.
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?
Adequate for a simple, read-only tool with one optional parameter: safety is covered by annotations, the parameter by the schema, and the resource/scope by the description. The only gap is the absence of any return-value description given that no output schema exists — a minor omission for a listing tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — administration_id is fully documented in the input schema, including its default and how to discover valid values. The description adds no parameter-level information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('custom fields'), and names the exact scopes: contacts, sales invoices, and identities. It is easily distinguished from sibling list tools, which target different resources, and the closing phrase gives the output a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with the ids needed to set them' signals the intended use case — retrieving ids before setting custom fields — providing clear contextual guidance. However, it names no alternative tool and states no explicit when-not-to-use condition, so the guidance is contextual rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context by clarifying that identities are sender profiles and that the default one is included in the result, going beyond what the annotations provide. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no filler. It leads with the verb and object, then clarifies scope and the inclusion of the default identity; every clause earns its place.
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?
For a simple list tool with one optional parameter, the description, annotations, and parameter schema together provide sufficient guidance. The explicit mention that the default identity is included is a helpful behavioral detail, though the description does not address pagination or exact response fields, which is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for administration_id is complete (100% coverage) and already explains the default and how to discover ids. The tool description adds no further parameter meaning, so the baseline of 3 for high schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'List' and the resource 'identities (sender profiles)' with a clear scope: an administration can invoice under them, including the default one. This distinctly separates the tool from sibling list_* tools and from get_identity without needing to open the schema.
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 this tool is for enumerating invoice-ready identities for an administration, but it does not explicitly say when to prefer it over get_identity or other list_* tools, nor does it mention exclusions. The parameter description recommends calling list_administrations first, but that guidance is about parameter discovery rather than tool 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 cover readOnly, idempotence, non-destructiveness, and open-world behavior, so the description's additional contribution is its authentication scope requirement. This is a concrete behavioral constraint not present in the annotations, which meaningfully helps the agent anticipate authorization failures. No contradiction exists between description and 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 two sentences with zero fluff. The action is front-loaded, and the authorization note is concise and directly useful. Every word earns its place.
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?
For a simple list operation with no required parameters and annotations covering safety and idempotence, the description is nearly complete. It omits details about the return shape, but no output schema exists and the scope requirement plus clear resource name provide enough context for correct invocation. A small note clarifying how subscription templates differ from subscriptions would improve completeness, but is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all three parameters with complete coverage, including defaults and maximums. The description does not add any parameter-specific meaning beyond what the schema already states, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List the subscription templates of the administration.' This clearly identifies the exact action and target, and the resource name distinguishes it from related siblings like list_subscriptions. It is not a tautology and there is no ambiguity about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a useful prerequisite by noting the required `settings` scope versus `sales_invoices`, which helps the agent understand when the tool is accessible. However, it does not explicitly state when to choose this tool over alternatives such as list_subscriptions or list_recurring_sales_invoices, leaving the usage context mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, with destructiveHintfalse, so the base safety profile is covered. The description adds meaningful behavior: it explains the scope of typeless documents and mentions that paid/late/pending_payment states only apply to purchase invoices and receipts. It stops short of describing pagination or response format, but with annotations covering read-only behavior, this is a solid addition.
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 purpose is front-loaded, but the long enumeration of filter keys duplicates information already in the input schema. The sentence is overloaded with semi-colon-separated keys, making it longer than necessary; more concise would be to point to filter keys in schema and highlight only non-obvious scope/ behavior.
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?
For a list tool with no output schema, the desciption explains what the documents are, how to narrow results via filter, and key behavioral quirks like state applicability. The schema covers pagination and administration_id, and annotations cover the read-only nature, so the description is sufficient for an agent to call this tool correctly in most 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?
The input schema has 100% parameter description coverage, so the baseline is 3. The description repeats the filter keys and state restrictions, but does not add meaning beyond what the schema already provides. It adds no new parameter-level guidance for page, per_page, or administration_id.
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 and resource ('List typeless documents') and defines the resource precisely: uploads parked in Moneybird that have not been classified as an invoice, receipt, or anything else. This distinguishes the tool from siblings like list_sales_invoices, list_receipts, and list_general_documents without requiring the agent to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool — to retrieve unclassified uploads — and gives filtering context. It does not explicitly state when not to use it or name alternatives like get_typeless_document for a single document, so it falls slightly short of a perfect exclusion-based usage guideline.
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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the scope ('with access to the administration') and the returned data ('ids and permissions').
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, front-loading the action and resource and immediately stating the response fields. Every word contributes.
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?
For a simple list tool with annotations and a fully documented optional parameter, the description is nearly complete. It states the main return fields, although it does not mention pagination or response shape, which would be useful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add parameter-specific semantics beyond what the schema already provides, but schema description coverage is 100% and the only parameter is thoroughly documented. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource ('users with access to the administration'), and the included data ('ids and permissions'). This distinguishes it from sibling tools like list_administrations and list_contacts.
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 and parameter schema make the tool's context clear, but there is no explicit guidance about when to use it versus alternatives. The reference to list_administrations for discovering ids is helpful for parameter usage, but not for tool 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 readOnly, idempotent, and non-destructive safety. The description adds meaningful behavioral context beyond those annotations: the URL is signed and expires after 30 seconds. This is critical operational knowledge that changes how the agent should handle the result. 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?
Two short sentences with no wasted words. The core purpose is front-loaded, and the actionable expiry warning is stated directly. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly explains the return value (a download URL) and its critical temporal constraint (signed, 30s expiry). The parameter information is handled by the schema, and annotations cover safety. Nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%; media and adminstration_id have descriptions, while sales_invoice_id is bare but self-explanatory. The tool description itself adds no paramter meaning beyond what the schema provides, and the 33% undocumented coverage is minor because the parameter name is clear. The description does not need to compensate much, but it also contributes nothing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Return a download URL for the invoice PDF.' This unambiguously identifies what the tool does and the resource type. The name itself clearly differentiates it from sibling PDF/download tools like download_estimate_pdf and download_document_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear post-invocation guidance ('use it immediately') but does not state when to choose this tool over alternatives such as get_sales_invoice or download_estimate_pdf. Usage context is only implied by the tool name and the resource type; no exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral context about the default financial-year scoping and how to override it, though it does not cover pagination or response format. This matches the pattern of a helpful but not deeply detailed description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core purpose is front-loaded, and the important default-behavior warning follows immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two fully documented optional parameters, the description plus schema covers the essential usage guidance. The default-period warning is exactly the kind of contextual detail an agent needs, and no critical call-time information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for both filter and administration_id. The description's mention of `period` adds no new semantic information beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List bank transactions,' a specific verb and resource that clearly identifies the tool's function. It also differentiates it from sibling tools like list_financial_accounts and get_financial_mutation by naming the resource as bank transactions/mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for a common pitfall: without a filter, only the current financial year is returned, and it tells the agent to pass an explicit period. It does not discuss alternatives, but the tool's purpose is clear enough that an agent can infer when to use it.
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 carry the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuine behavioral context beyond those flags: Moneybird defaults to `period:this_year`, meaning a bare call does not return all receipts but only those in the current financial year, and the note that paid/late/pending_payment states only apply to purchase invoices and receipts. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose sentence is front-loaded, precise, and self-contained, and the filter key enumeration is directly useful to an agent reading only the description. Small deduction because the filter enumeration duplicates the schema's `filter` description nearly verbatim rather than contributing distinct structure, adding minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is complete for a list operation with rich annotations and 100% schema coverage: purpose, resource definition, filter semantics, pagination, and the critical period default are all available to an agent. The only gap is the absence of return-shape guidance, since there is no output schema, but the resource is well-defined and a get_receipt sibling exists for single-object detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema's `filter` description is strictly more detailed than the description text, adding the pipe-combination rule and the Moneybird period default. The description merely enumerates the same filter keys without adding any new parameter meaning, so the baseline of 3 applies per the rubric.
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?
States a specific verb and resource ('List receipts') and immediately defines the resource in meaningful terms ('expenses paid on the spot, without a supplier invoice'). The parenthetical disambiguates receipts from purchase invoices, which matters given the sibling list_purchase_invoices. An agent can tell this tool apart without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The definition of a receipt as an expense 'without a supplier invoice' provides a clear selection condition: if the expense has a supplier invoice, an agent should look to purchase invoices instead. However, it never names an alternative tool explicitly (e.g., list_purchase_invoices) and contains no when-not statement, so it falls just short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the definition reveals several non-obvious behaviors: the current-financial-year default, that any filter replaces Moneybird's default entirely, and that drafts without an invoice_date are only matched by a period containing today. These are exactly the kinds of edge cases that prevent incorrect calls.
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 main description is two sentences with the purpose front-loaded and the behavioral caveat immediately after. The long filter description is warranted because the filter has many keys and special matching rules; it is organized and readable.
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?
For a read-only, idempotent list operation, the definition covers the default period, filter replacement behavior, draft edge case, pagination, and administration selection. No output schema is provided, but the return shape of a list endpoint is evident from the tool name and sibling patterns.
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?
All parameters are fully documented in the schema (100% coverage), including the complex `filter` syntax, keys, examples, and pagination bounds. The main description only adds the hint to pass an explicit `period`, which is already implied by the schema's filter documentation, so it contributes little semantic value 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 opens with the precise verb-resource pair 'List sales invoices' and adds a meaningful default-scope qualifier. It does not explicitly differentiate from sibling tools like get_sales_invoice or find_sales_invoice_by_invoice_id, though the list-vs-singular naming largely conveys that.
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 gives a clear within-tool rule: because it defaults to the current financial year, callers needing older data must pass an explicit `period`. However, it does not say when to prefer this tool over alternatives such as get_sales_invoice or find_sales_invoice_by_invoice_id, so cross-tool routing guidance 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?
The description adds useful behavior beyond the annotations: it opens the Moneybird token page and stores the created token. Annotations already provide idempotent/open-world/read-only context, so the added explanations are sufficient for this auth-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful sentences: purpose, usage trigger, and behavior. No redundant wording, and key information is front-loaded.
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 optional parameters and no output schema, the description covers the core flow and why to use it. It does not spell out the post-call success indicator, but the moneybird_connection_status sibling fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented. The description reinforces the interactive token flow but does not add significant semantic detail beyond what the schema provides.
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?
States a specific verb and resource: 'Authenticate this server against a Moneybird account.' This is clearly distinct from the data-reading sibling tools and leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit trigger: 'Call it when other tools report missing or rejected credentials.' It does not name alternatives or exclusions, but the condition is specific enough for an agent to know when to invoke it.
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, idempotentHint=true, destructiveHint=false. The description adds meaningful behavioral context beyond annotations: the link is signed and expires after 30 seconds. This is critical for correct invocation, though it could have elaborated on what happens if the link expires.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no wasted words. The purpose is front-loaded, and the critical expiry warning follows immediately. Every sentence earns its place.
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?
The description explains the return value (a download URL) and its key caveat (signed, 30-second expiry), which is sufficient for a read-only download tool with no output schema. The only minor gap is the lack of explicit guidance on the estimate_id parameter, but the name and tool context make it inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, leaving estimate_id without documentation, and the tool description does not add parameter semantics. The parameter name is self-explanatory, but the description doesn't compensate for the missing schema coverage or explain how the estimate_id should be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Return a download URL for the estimate PDF.' This clearly identifies the tool's function and distinguishes it from sibling PDF-related tools like download_sales_invoice_pdf by specifying 'estimate PDF'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool via 'use it immediately' and the expiry constraint, but does not explicitly contrast it with sibling download tools. It implies the scope (estimate PDFs) and the timing constraint, but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Retrieve' aligns with those safety guarantees. The description adds only the two lookup modes and does not describe error handling or return behavior, so it provides modest extra transparency 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?
The description is a single sentence with no wasted words. The verb and resource are front-loaded, and the example is integrated naturally.
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?
For a simple single-resource getter with no output schema, the description covers the core selection logic. The only notable gap is that it does not explicitly state that at least one of estimate_id or estimate_number is required, nor describe the return payload.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds the alternative relationship between estimate_id and estimate_number and includes a concrete example format ('2025-0001'), which helps agents understand how to supply an identifier even though the schema shows no required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieve') and resource ('estimate') and specifies two lookup paths: Moneybird id or the printed estimate number. This makes it clearly distinguishable from list_estimates and other single-resource getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool: you have a known estimate id or the estimate number printed on the document. It does not explicitly name alternatives or exclusion conditions, so agents must infer 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context by explaining that payments are not tied to a single document type and that their ids surface across multiple document kinds, which is not obvious from the tool name or schema alone. There is 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?
Two short sentences are tightly written, with the core retrieval action and identifier front-loaded. The second sentence provides useful context without fluff. Every word contributes to understanding the tool's scope.
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?
For a simple get-by-id tool with only two parameters and no nested objects, the description plus schema provides enough information to call it correctly. The lack of an output schema is not a major gap because the purpose is straightforward. A note about what fields the returned payment object contains would be optional but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: administration_id is well described in the schema, while payment_id has no schema description. The tool description only says 'by id' and does not add detail about the expected format of payment_id, but the parameter name and the surrounding description make its purpose clear. This is adequate but not enhanced 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 states a specific verb ('Retrieve'), a specific resource ('a payment'), and the lookup key ('by id'). It also clarifies the cross-document nature of payments, distinguishing this from the many document-specific get_* sibling tools. An agent can clearly understand what this tool returns and how it is identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you have a payment id that appears on invoices, receipts, or financial mutation bookings, rather than using document-specific getters. It does not explicitly name alternatives or list exclusions, but the context is clear enough for an agent to route correctly among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds value beyond those by revealing the response includes lines, payments, attachments, and notes, which is useful behavioral context about the returned payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes information: the action, the target resource, the scope, and the included subresources.
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?
For a read-only, idempotent get tool with no output schema, describing the main resource and its included associated data is largely sufficient. It doesn't cover not-found behavior or error cases, but those are secondary for such a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; receipt_id lacks any schema description. The prose 'by id' adds minimal meaning beyond the parameter name, and administration_id is already fully documented in the schema. The description doesn't substantially compensate for the missing receipt_id documentation.
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 ('Retrieve') and resource ('one receipt by id'), and explicitly enumerates the included data (lines, payments, attachments, notes). This clearly distinguishes it from list_receipts and related single-resource getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one receipt by id' gives clear context for when to invoke this tool: when a specific receipt identifier is known. However, it doesn't explicitiy state exclusions or name alternatives like list_receipts for retrieving multiple receipts, though it is implied.
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 cover readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond that: the response will include lines, payments, and notes, which helps set expectations for what is returned. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that delivers the action, the identifier type, and the expected payload without wasted words. Every phrase earns its place.
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?
For a simple read tool backed by strong annotations and only two parameters, the description is nearly complete. It gives the lookup key, the selected scope, and important return content. A brief sibling-routing note would round it out, but nothing essential for a correct call is missing.
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?
Schema coverage is only 50% because sales_invoice_id has no schema description. The description fills this gap by clarifying that the id is a Moneybird id, which is essential for selecting this tool over the invoice-id/reference lookup siblings. The optional administration_id is already described in 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 clearly states a specific verb and resource: 'Retrieve one sales invoice by its Moneybird id.' It also distinguishes itself from list/find/download siblings by making the id namespace explicit and by specifying the returned content (lines, payments, notes).
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 correct use case—you have a Moneybird sales_invoice_id and want the full invoice—but it never explicitly names alternatives like find_sales_invoice_by_invoice_id or find_sales_invoice_by_reference, nor gives conditions for when to choose them instead.
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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying what is included in the response ('with its contact, project, user and billable state'), which is information not present in the annotations or schema.
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?
One sentence with no filler: it front-loads the core action and resource, then lists the returned associations. Every word contributes useful meaning.
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?
For a simple two-parameter read tool with no output schema, the description covers the return shape at a useful level and the schema covers the optional administration parameter. It does not describe error/not-found behavior or fully enumerate all returned fields, but annotations plus the concise description are sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; the administration_id param is well-described in the schema with defaults and discovery guidance, while time_entry_id has no schema description. The tool description's 'by id' clarifies the role of time_entry_id but does not compensate for the low coverage or add details about id format/type or the optional administration parameter beyond what the schema already provides.
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, 'Retrieve', names the resource 'a single time entry by id', and states the included associations (contact, project, user, billable state). This clearly distinguishes it from list_time_entries and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by id' clearly implies this tool is for fetching one specific time entry when its identifier is known, as opposed to listing entries. It does not explicitly name the alternative list_time_entries or provide when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive traits. The description adds non-obvious behavior: estimates are scoped to the current financial year unless overridden, which materially affects results and is not visible from annotations alone.
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, front-loaded sentence that communicates purpose, synonym, and a critical default behavior with no wasted words.
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 rich schema, safety annotations, and straightforward list semantics, the description is sufficient for selecting and invoking the tool. A minor gap is that it does not describe the response shape, but no output schema exists and the tool name makes this predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the filter keys, page, per_page, and administration_id. The description reinforces the period default, but does not add meaning beyond what the schema already provides.
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?
States a specific verb and resource ('List estimates') and clarifies that estimates are quotes, which removes domain ambiguity. The collection-level 'list' framing clearly separates it from sibling tools like get_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete usage context: the tool defaults to the current financial year and tells the caller to pass an explicit period to reach older data. It does not explicitly name alternatives like get_estimate, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is already known. The description adds meaningful selection context by explaining the returned ids' role as `financial_account_id` in other entities, and indicates the per-administration scoping of the account list. This goes beyond what the annotations convey without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler. It front-loads the core purpose (list accounts) and immediately provides the most decision-relevant detail (what the ids are used for). Every clause earns its place.
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?
The description is complete for a simple, read-only, single-parameter listing tool with rich annotations. It could have named the likely sibling list_ledger_accounts for disambiguation, but the description's scoping is tight enough that an agent is unlikely to confuse the two. No output schema exists, but the tool's output is inherently simple and discoverable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation covers the single parameter 100% with a clear description of the administration_id and a pointer to list_administrations. The description itself does not add parameter details, but since schema coverage is complete, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('List'), a precise resource ('bank and payment provider accounts of the administration'), and adds the key linkage that the returned ids are referenced as `financial_account_id` by financial mutations and statements. It fully distinguishes this tool from siblings like list_ledger_accounts and list_financial_mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool lists and the context of use (accounts referenced by financial mutations/statements). It gives no explicit exclusions or when-not-to-use guidance, but the strong scope statement plus the exception-free sibling set makes correct selection likely without further guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, and non-destructive nature, so the description does not need to repeat that. It adds valuable context beyond annotations by explaining the platform limitation (no administration-wide subscription list) and why `contact_id` is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no waste: the main action is stated first, followed by the key constraint and rationale. It is front-loaded and easy for an agent to parse.
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?
For a simple list operation with one required parameter, one optional parameter, and robust annotations, the description is complete enough for correct invocation. Minor details like pagination or ordering are not mentioned, but they are not essential for selecting or calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description reinforces that `contact_id` is required and explains why, but it does not add substantially new semantic detail 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 states the specific operation ('List the subscriptions') and the required scope ('of one contact'), which clearly identifies what the tool does. It also distinguishes itself from an administration-wide list by explicitly noting Moneybird has none, so an agent understands the contact-scoped nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that subscriptions must always be scoped to a contact and that `contact_id` is mandatory because no administration-wide list exists. It could additionally name alternatives such as `get_subscription` or `list_subscription_templates`, but the boundary for using this tool is nonetheless clear.
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 readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context by revealing that the result is a temporary download URL rather than file content, and that it targets one specific attachment. 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?
Two sentences with no wasted words. The primary purpose is front-loaded, and the prerequisite about fetching attachment ids is placed directly after. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool whose safety profile is already covered by annotations, the description provides the essential operational details: what is returned, for which object, and how to find the needed attachment_id. The lack of an output schema is mitigated by explicitly saying the output is a temporary download URL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate. It does clarify the source of attachment_id, and the document_type enum is self-explanatory, but document_id and the relationship between parameters are left mostly to inference. The compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb and resource: 'Return a temporary download URL for one attachment of a document.' This clearly communicates the tool's function and distinguishes it from list/get tools and the PDF-download siblings by focusing on individual attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives actionable usage context: obtain attachment ids from the document via get_purchase_invoice, get_receipt, or the matching get tool. It does not explicitly name alternatives for downloading full documents, so it stops short of full when-to-use-versus-alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnly, idempotent, and non-destructive hints, so the description does not need to re-state those. It adds useful behavior beyond annotations: drafts have no invoice number and will never be returned by this lookup, which is valuable for expectation setting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the key information is front-loaded: what the tool looks up and by which key. The example is compact and the caveat about drafts is placed at the end without diluting the core message.
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?
For a simple read-only lookup tool, the description together with the annotated hints and well-covered schema is fully sufficient. The absence of an output schema is acceptable because the tool's purpose is straightforward and no return-value description is required when the output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that invoice_id is the printed document number and provides an example format ('2025-0001'), which adds slight value, but the schema already clearly defines the parameter. No significant compensation is needed.
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 identifies the exact resource (sales invoice) and the lookup key (printed invoice number), with a concrete example. The 'Drafts have no invoice number and are never found this way' qualifier distinguishes this from tools that work with drafts or internal IDs, so it differentiates from sibling lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you have the printed invoice number. It also states a clear exclusion, drafts are never found this way. It does not explicitly name alternative tools or conditions that would route to get_sales_invoice vs find_sales_invoice_by_reference, so it misses the top tier but provides solid context.
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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral nuance beyond the annotations, such as which state filter values are restricted to purchase invoices and receipts and how period ranges are expressed. This gives the agent a more accurate model of how the filter behaves.
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 front-loaded with the purpose and then moves directly into filtering details in a single dense sentence. There is no filler, and every clause adds usable information for selecting and invoking the tool correctly.
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?
Between the description and the fully documented schema, an agent has all call-time information: filter keys, value domains, period format, pagination controls, administration override, and exclusion behavior. The annotations cover the read-only, idempotent nature, so no critical safety or side-effect information is missing. The lack of an output schema is acceptable for a simple list endpoint where the return shape is predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so every parameter including page, per_page, administration_id, exclude_new_general_journal_documents, and the full filter grammar is already documented structurally. The main description essentially restates the filter keys without introducing new parameter-level semantics, so it meets the high-coverage baseline of 3.
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 opens with a specific verb and resource: "List general journal documents" and immediately clarifies the resource as "manual journal entries," which distinguishes it from sibling tools like list_general_documents and get_general_journal_document. There is no ambiguity about what operation this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage guidance by explaining that results are narrowed with a `filter`, enumerating the valid filter keys and value domains, and noting that certain state values only apply to purchase invoices and receipts. It stops short of explicitly naming alternatives or saying when to prefer this over get_general_journal_document, but the context is clear enough for an agent to decide.
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, idempotentHint, and destructiveHint=false. The description adds valuable non-obvious behavior: Moneybird returns only active projects unless the filter says otherwise. It also notes the relational link to time entries, which helps the agent understand the data model. This exceeds the annotation baseline without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The core action is front-loaded, and the second sentence adds essential behavioral context without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only list tool with fully documented parameters, annotations covering safety, and no output schema, the description is complete. It conveys the default-filter behavior and the practical relationship to time entries, which are the key non-obvious aspects an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (page, filter, per_page, administration_id) are documented in the schema itself. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List projects', a specific verb plus resource, and immediately clarifies the default scope (active projects only). This clearly distinguishes list_projects from the singular get_project sibling and other list_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case: time entries reference projects by `project_id`, so an agent working with time entries can use this tool to resolve project references. It implies when to use this tool without explicitly naming alternatives, which is acceptable given the strong naming convention and sibling context.
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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that by scoping the list to the administration's configured VAT rates and explaining their relationship to invoice lines. It does not need to repeat pagination or filter behavior since the schema fully covers those parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The purpose is stated first, and the relationship to invoice lines is communicated in a single useful clause. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, this description is complete for tool selection and invocation: it names the resource, scopes it to the administration, explains the main use case, and the schema covers all parameters. Annotations cover the safety profile, so no further behavioral disclosure is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters individually described, so the schema carries the parameter documentation burden. The description adds no direct parameter details, but the line about invoice lines referencing tax_rate_id provides indirect context for the filter/tax_rate_type semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List the VAT rates configured for the administration') and adds a clear domain tie-in: invoice lines reference these rates by tax_rate_id. This differentiates it from the many sibling list/get tools, even though tax rates have no direct sibling equivalent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Invoice lines reference these by tax_rate_id' tells an agent when this tool is relevant: when resolving or validating tax_rate_id values for invoice-related operations. It does not name an alternative, but no sibling targets tax rates, so an exclusion is not necessary; the administration scoping is also clear.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the three concrete pieces of state it reports: credential validity, selected administration, and token-reachable administrations, giving agents a clear sense of the tool's behavior beyond generic 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 concise sentence that front-loads the core action ('Report whether...') and packs the full behavioral scope into three coordinated clauses. There is no filler, repetition, or unnecessary detail.
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?
For a zero-parameter, read-only status tool, the description completely captures the relevant information an agent needs: what the tool checks, what state it reveals, and the selection/reach scope. With no input schema and no output schema, this is sufficient for correct invocation.
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 takes zero parameters and the schema coverage is 100%, so there is nothing for the description to add beyond what the schema already expresses. The baseline of 4 applies because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Report') and a clear resource (Moneybird connection status), and enumerates exactly what the tool reports: credential validity, selected administration, and reachable administrations. This distinguishes it from siblings like connect_moneybird, select_administration, and list_administrations by framing it as a read-only status check rather than an action or listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for diagnosing the Moneybird connection and checking the currently selected administration, giving clear context for when an agent would call it. However, it does not explicitly state when to prefer it over alternatives such as connect_moneybird or list_administrations, nor does it mention any exclusion 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 annotations already provide readOnly, idempotent, and non-destructive hints. The description adds the key behavioral fact that the change is session-scoped and affects subsequent tool calls, which goes beyond the structured annotations. 'Change' sits slightly awkwardly with readOnlyHint if interpreted strictly, but no external data mutation is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences. The first names the action and the condition, the second gives the persistence scope. No filler or redundancy.
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?
For a one-parameter session-state setter with full schema coverage, the description tells the agent what it does, when it matters, and how long it lasts. An output schema is unnecessary because the outcome is a session setting rather than a returned resource.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter and even references list_administrations as the source. The description adds no additional parameter meaning, so the baseline of 3 applies.
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?
States a precise action ('change the administration that tools use'), the condition ('when they are not given an explicit administration_id'), and the session scope. This clearly distinguishes it from list_administrations and other resource-specific sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when the effect applies (when no explicit administration_id is passed) and that it lasts for the rest of the session. It doesn't explicitly name alternatives, but the session-default behavior is self-contained and the parameter schema points to list_administrations as the id source.
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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds meaningful behavioral context beyond annotations by disclosing that the response includes lines, payments, attachments, and notes, which helps the agent predict return content.
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 efficient sentence that front-loads the core behavior ('Retrieve one purchase invoice by id') and then lists the included data. No redundant words or unsupported detail.
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?
For a simple read-only get-by-id tool, the description, schema, and annotations together cover the essential operation, parameters, and return scope. It does not explain not-found behavior or error conditions, but these are minor for a safe idempotent read with strong annotation coverage.
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 purchase_invoice_id parameter has no schema description, and the tool description's 'by id' clarifies its role. The other parameter, administration_id, is already well documented in the schema with defaults and discovery guidance. Description and schema together cover both parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Retrieve one purchase invoice by id') on a specific resource, with an explicit scope and a list of included sub-data (lines, payments, attachments, notes). This clearly distinguishes it from listing tools like list_purchase_invoices and from getters of other document types (e.g., get_sales_invoice, get_receipt).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'One purchase invoice by id' gives clear context: use this when you have a specific purchase_invoice_id. However, it does not explicitly name the alternative for bulk retrieval (list_purchase_invoices) or state when not to use the tool, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds non-obvious behavioral context: the default period is the current financial year and older data requires an explicit filter period. 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?
Two sentences with no filler. The purpose is front-loaded and the second sentence delivers the most decision-relevant behavioral detail about the default period.
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?
For a read-only list tool with four optional, fully documented parameters and rich annotations, the description covers the main non-obvious behavior. It could have explicitly routed regular invoices to list_sales_invoices, but the external scope is already unambiguous.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning to the filter parameter by explaining the period default and how to override it with an explicit period. It does not discuss page, per_page, or administration_id, but those are already fully documented in 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 and resource: 'List revenue invoiced outside Moneybird'. The 'outside Moneybird' qualifier clearly distinguishes this tool from siblings like list_sales_invoices and aligns with get_external_sales_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context by mentioning webshops/POS and explicitly warns about the current-financial-year default with an instruction to pass an explicit period. It does not explicitly name alternatives or exclusion rules, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds the non-obvious default behavior (`unbatched:true`) and the fact that filters replace Moneybird's defaults entirely, which is critical behavioral context beyond what annotations convey. It could go to 5 with explicit return-format or pagination disclosure, but the default-behavior disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines the resource, second discloses a hidden default and a specific call instruction. Front-loaded purpose, no filler, every sentence earns its place.
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?
For a read-only list tool with full schema coverage, annotations carrying safety, and idempotency, the description is nearly sufficient. It doesn't describe pagination or return shape, but with no output schema, that's still a minor gap—most of what an agent needs to call it correctly is present.
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?
Schema coverage is 100%, and every parameter has a description. The tool description adds context about the `filter` parameter's functional role (replacing defaults, the unbatched default). The description doesn't repeat schema details, which is proper. A 4 is appropriate because the description enriches the parameter semantics without needing to compensate for missing schema coverage.
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?
States a specific verb (list) and resource (outgoing payment instructions / purchase transactions), and the first sentence clearly differentiates this tool from siblings like list_purchase_invoices and list_financial_mutations. The description even includes the domain-specific Moneybird term 'purchase transactions' and explains the batch distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent about Moneybird's default `unbatched:true` and instructs it to pass an explicit filter to see batched transactions. It doesn't explicitly name sibling alternatives, but the context signals show many sibling list tools; the behavioral note about batching provides clear usage context. It could improve by saying 'use get_purchase_transaction for a single purchase transaction', but the guidance given is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds behavioral insight beyond annotations by explaining the default financial-year scoping and the need for explicit filter overrides, which is valuable for correct invocation. No contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states purpose, and the second provides two important behavioral caveats. Every clause earns its place and the key default behavior is front-loaded.
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?
With zero required parameters and schema already covering all five parameters, the description addresses the main non-obvious traps: default time scope and active timers. The lack of an output schema is not a gap for a list tool, though an explicit pointer to get_time_entry for single entries would make it fully 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?
Schema coverage is 100%, so parameters are already documented, but the description enriches the filter semantics by explaining the default behavior and how to use period and include_active to alter it. This goes beyond raw syntax and helps an agent understand practical 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 opens with a specific verb and resource, 'List tracked time,' which exactly matches the tool's purpose and clearly differentiates it from the sibling get_time_entry. It adds a useful scoping note about the default financial year, further clarifying what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete operational guidance: without a filter the API returns the current financial year, so users should pass an explicit period to look further back, and include_active:true to include running timers. It does not explicitly mention get_time_entry as the alternative for retrieving a single entry, but the context for choosing this tool and its filters is clear.
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, idempotentHint, and non-destructive behavior. The description adds value by stating the result scope (every administration the token can access) and enumerating the returned fields. Pagination or ordering are not mentioned, but this is minor for the tool's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first states the action and scope; the second gives immediate actionable guidance. No wasted words.
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?
For a no-parameter discovery tool, the description is complete: it names the output fields, clarifies scope, and explains why the agent should call it first. No output schema exists, but the description supplies enough return information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the baseline is 4. No parameter description is needed.
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 and resource: 'List every Moneybird administration this token can access' with the returned fields itemized. It also positions this as the discovery entry point, distinguishing it from siblings like select_administration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this first to discover the administration id other tools need,' which gives clear when-to-use guidance. It does not name alternatives or exclusions, but for a zero-parameter read-only list this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations by documenting the default filter behavior (period:this_year), the piped-value combination syntax for certain state fields, and the fact that some states are only applicable to purchase invoices/receipts. It does not describe pagination behavior beyond the param schema, but the annotations plus description are solid.
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, dense sentence that front-loads the resource definition, then packs the filter syntax and key constraints into a compact list. Every clause earns its place — the default period warning and the state applicability caveat are both high-value and not repeated elsewhere. No fluff, no redundant restatement of the tool name.
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?
For a read-only list tool with 100% schema coverage, no output schema, and four optional parameters, the description covers the critical decisions: what counts as a general document, how to narrow via filter, and the crucial default-period gotcha. The absence of an output schema means return-shape documentation isn't required, and the annotations cover safety. An agent has everything needed to call this correctly on the first attempt.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the default behavior ('Moneybird defaults to period:this_year'), demonstrating the filter syntax with concrete examples ('20260101..20260131', 'state:open|paid'), and clarifying which filter values only apply to other document types. It still doesn't fully explain the 'reference' or 'contact_id' matching semantics, but the added examples and default disclosure elevate it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a resource ('general documents'), and defines what that resource is ('filed paperwork such as contracts and correspondence that carries a date and reference but no amounts'). It also distinguishes this from sibling tools like list_typeless_documents, list_purchase_invoices, and list_receipts by clarifying what counts as a general document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the default behavior ('Moneybird defaults to period:this_year') and tells the user to pass an explicit period to look outside the current financial year. It also explains the state filter's limitation ('paid, late and pending_payment only apply to purchase invoices and receipts'), which prevents an agent from misusing the tool. The sibling list includes get_general_document for retrieval, but the core usage guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![moneybird-mcp MCP server](https://glama.ai/mcp/servers/HalloSouf/moneybird-mcp/badges/score.svg)](https://glama.ai/mcp/servers/HalloSouf/moneybird-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/HalloSouf/moneybird-mcp'

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