bokio-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct entity or action (list vs get vs download) with clear hierarchical relationships (e.g., invoice → payments/settlements/attachments). No overlapping purposes that would cause misselection.
Naming Consistency5/5
All domain tools follow a strict 'bokio_verb_noun' pattern (list/get/download), with utility tools (ping, get_connection_status) clearly separated. The naming is highly predictable and consistent.
Tool Count4/5
With 40 tools, the count is on the heavier side but justified by the breadth of accounting entities (invoices, customers, journal entries, items, uploads, etc.). Each tool serves a specific resource, though some consolidation could reduce redundancy.
Completeness3/5
The tool surface comprehensively covers read operations across all major accounting entities, including downloads and SIE export. However, it lacks any create/update/delete tools, so the lifecycle is incomplete unless the server is intentionally read-only.
Average 3.6/5 across 40 of 40 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description 'Fetches one credit note' is consistent with the readOnlyHint and idempotentHint annotations but adds no extra behavioral context. It does not mention error handling, return format, or any operational nuances, and with annotations already conveying safety, the description fails to add value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero redundancy. It is appropriately concise for a simple get operation, though it lacks any supplementary structure such as examples or notes that could enhance clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the availability of sibling tools like bokio_download_credit_note and bokio_list_credit_notes, the description does not explain how this tool differs or what the response looks like in the absence of an output schema. It is too sparse to guide an agent confidently, especially without any behavioral or selection details beyond the bare minimum.
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% since the only parameter 'creditNoteId' is described, albeit minimally as 'Path parameter creditNoteId'. The description adds no additional meaning to the parameter, so 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 clear verb ('Fetches') and resource ('one credit note'), which precisely identifies the tool's primary action. However, it does not differentiate from sibling tools like bokio_get_invoice or bokio_download_credit_note, so it is clear but not distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as bokio_list_credit_notes or bokio_download_credit_note. There is no mention of prerequisites or selection criteria, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured metadata. The description makes no false claims, but it also adds nothing behavioral beyond this: no mention of return format, 404 behavior, or whether accounting periods are included. The description is neutral rather than harmful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero filler and is entirely devoted to the core behavior. It is efficiently front-loaded, though the spareness is a double-edged sword: there is no wasted prose, but also no room for the missed context noted in the other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema, read-only fetch tool, the definition is near the minimal acceptable bar. The main missing piece is a pointer to the sibling list endpoint or the return envelope, either of which would help an agent confidently invoke it without guessing. As-is, it will work, but a small amount of extra guidance would have made the difference.
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% — the only parameter, fiscalYearId, is defined as a path parameter. The description adds no extra semantic detail beyond 'one', which is a missed opportunity to clarify the ID format or that it must come from the list endpoint. Baseline of 3 applies given full schema coverage, but the description does not go the extra mile.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetches one fiscal year' states a specific verb and resource, and the 'one' qualifier hints at the single-record read versus a list. However, it barely rises above a sentence-form version of the tool name 'get_fiscal_year', and it never names or differentiates from its natural sibling bokio_list_fiscal_years. It is clear but provides minimal informational lift over the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus the obvious sibling bokio_list_fiscal_years, and no preconditions or reprs are mentioned. An agent must infer the get-vs-list convention from the tool names alone, which are not explicitly connected despite being directly relevant to the same resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the tool is clearly a safe read operation. The description adds minimal behavioral context: it says it downloads a file, but doesn't mention whether the file contents are returned as binary, whether it requires specific permissions, or if there are size limits. However, given that annotations already establish the safe read nature, the description's generic statement is acceptable but adds little beyond the annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no filler. It's front-loaded with the action verb. However, it might be slightly under-specified, but conciseness alone isn't penalized; it's effective in being short. The structure is fine for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, a simple output (the file download), and annotations already cover the read-only nature, the description is almost sufficient. But for an agent in a toolchain with many download siblings, it lacks guidance on how this differs from downloading invoice attachments or credit notes. The description is complete for a standalone tool but not fully contextualized within the sibling set. Since there's no output schema, the description could mention that it returns the file content, but that's implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, uploadId, which is 100% covered by the schema description 'Path parameter uploadId'. The description does not add any additional meaning (e.g., how to find the uploadId, what format it takes, whether it's a UUID or numeric). Since schema coverage is high (100%), the baseline is 3, and the description does not worsen or improve it. However, it could have added context like 'use the uploadId from bokio_list_uploads to download the original file', but it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Downloads an uploaded file' states a clear verb ('Downloads') and resource ('an uploaded file'), distinguishing it from operations like creating or updating. However, it lacks specificity about what type of uploaded file (e.g., does it correspond to an upload ID from a list endpoint?) and doesn't differentiate from sibling download tools like bokio_download_invoice_attachment, which download specific attachment types. The tool name is specific enough to hint at the upload context, but the description alone is somewhat generic.
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 implicitly suggests it should be used when the user wants to retrieve an uploaded file, but it provides no explicit guidance on when to use this tool versus alternatives like bokio_download_invoice_attachment or bokio_download_invoice. Given the list of siblings, an agent might struggle to know which download tool to select; the description doesn't clarify that this is for a generic upload (likely tied to an uploadId from bokio_list_uploads or bokio_get_upload) versus a specific attachment. This is a gap since the context signals show 40 sibling tools, and many are download variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read. The description adds nothing beyond 'Fetches one settlement' – no mention of error behavior, empty results, or what constitutes a settlement. It merely restates the operation without new context, and the annotation already covers the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero fluff. States the verb and object immediatelyais entirely concise and gets straight to the point.
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 tool with two path parameters, the description is adequate but minimal. It doesn't clarify what a 'settlement' refers to in this domain, nor what the response contains-semantics. Since there's no output schema, adding a hint about the shape or use of the returned data would help, but the core operation is clear enough for basic use.
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 both parameters are simple string IDs described only as 'Path parameter'. The description adds no additional parameter semantics, relying entirely on the schema. Since the schema descriptions are minimal and the IDs are self-explanatory in context, the baseline of 3 applies – the description doesn't hinder but also doesn't enrich.
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 ('fetches') and resource ('one settlement on an invoice'), clearly identifying what the tool does. While it doesn't explicitly distinguish it from sibling tools, the scope is precise and understandable. A slight deduction for not contrasting with a possible list-settlements sibling, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention that this is for fetching a single settlement, nor does it point to a sibling for listing settlements. The context that this is the read-single counterpart to a list operation is missing, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, the description adds no behavioral context beyond restating what the tool does — no mention of pagination limits, whether metadata or content is returned, or how this relates to the download/get siblings. For an operation with no output schema and no behavioral notes, the description leaves agents to guess at the return shape.
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?
Seven words, zero waste, and the key information is front-loaded. The description is exactly as long as it needs to be, a model of verbal economy. 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?
For a simple list tool with a single required parameter and the safety profile covered by annotations, the description is minimally adequate. The biggest gap is the absence of any statement about the return shape (metadata vs. content), which matters more because no output schema exists. An agent is left inferring that 'list' means metadata-only, which is reasonable but unstated.
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%, establishing a baseline of 3. The description itself adds no parameter-level detail, and oddly, the most critical parameter (invoiceId) has the least helpful schema description ('Path parameter invoiceId' — a tautology). Page, pageSize, and query have genuinely useful schema descriptions. The description could have clarified the relationship between the parameters and the listing behavior but doesn't.
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 verb ('Lists'), resource ('file attachments'), and scope ('on an invoice'). The description is clear and the naming convention differentiates it from siblings like bokio_get_invoice_attachment and bokio_download_invoice_attachment. However, the differentiation is implicit via the word 'Lists' rather than explicit, so it doesn't quite earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs. alternatives. There's no mention of the distinction between listing attachments, getting attachment metadata, or downloading content, even though all three siblings exist. With siblings like bokio_download_invoice_attachment and bokio_list_invoices, an agent gets zero help selecting among them. The usage context is purely implied by the verb, which is not enough.
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 known. The description adds no additional behavioral context such as pagination behavior, return format, or whether settlements differ from payments. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is efficient but minimal, lacking context that could make it more helpful. It earns its place but is not richly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what a settlement is and what the response contains, but it does not. It also fails to provide usage context or distinguish this listing from invoice payments. The tool is not fully specified for an agent to invoke correctly in ambiguous situations.
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, with each parameter documented. The description itself adds no extra meaning beyond the schema. The baseline of 3 applies because the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Lists settlements on an invoice.' This clearly identifies the operation. However, it does not explicitly differentiate from sibling tools like bokio_list_invoice_payments or bokio_get_invoice_settlement, relying on the tool name for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention bokio_get_invoice_settlement for retrieving a single settlement, nor does it clarify the relationship to bokio_list_invoice_payments. Usage is left entirely 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description only needs to add context. Describing the operation as 'fetches' is consistent with those annotations and adds the minor signal that this returns metadata rather than file content, but it adds no substantive behavioral context beyond that. 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?
Three words of front-loaded substance with zero waste — the purpose is understandable in under a second. Slightly more verbose than needed for a get-by-ID metadata fetch, and appropriate to the trivial complexity of the tool, though it borders on under-specified rather than efficient.
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 2-param, no-output-schema tool with comprehensive annotations covering safety, the description covers the essentials: it fetches attachment metadata. What's missing is an explicit note that this is distinct from downloading the binary content (the download sibling), but given the tool's simplicity, the gap is small.
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 documents both parameters. The description's mention of 'metadata' loosely implies attachmentId identifies the attachment and that the return is not a binary download, but it adds no actual meaning about what invoiceId/attachmentId are or what format they take. Baseline 3 according to the high-coverage rule.
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?
Uses a specific verb+object combo ('Fetches attachment metadata') that identifies both the resource and its scope. The word 'metadata' differentiates it from the near-named sibling bokio_download_invoice_attachment, though it doesn't explicitly name that sibling or state it returns a single record by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. In a list of ~40 siblings including the confusingly similar bokio_download_invoice_attachment and bokio_get_invoice, there's no when-to-use statement, no exclusions, and no mention of alternatives — the agent must infer intent entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Fetches' which aligns with readOnlyHint=true. Annotations already cover the read-only, non-destructive behavior. The description adds no new behavioral detail like error cases or side effects. Since annotations are present, a 3 is appropriate.
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 short sentence that clearly states the operation. Extremely concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a get-by-id operation, this is minimal. It doesn't explain what an 'item' is, whether the operation is idempotent (though read-only implies), or what the return value looks like. Given no output schema, the description should give more context, like 'Returns the full item object'. It's too terse to fully guide an agent.
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% for the single parameter itemId, and the schema already describes it as a path parameter. The description adds nothing about the parameter's meaning or expected format. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Fetches') and resource ('one item'), which clearly indicates a single-resource retrieval. It distinguishes from list operations by specifying 'one', but doesn't name the resource type beyond the generic 'item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention that you need an item ID, or that you should use list_items first to get IDs. There's no reference to sibling tools or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is clear. The description adds no additional behavioral context such as error behavior, permissions, or return shape, but it is consistent with the annotations and sufficient for a simple fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler and front-loads the core scope. It is minimal but appropriately sized for such a simple 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 one-parameter, read-only fetch with complete schema coverage and safety annotations, the description is mostly complete. It does not describe the return value, but the resource name and singular scope make the expected outcome 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 coverage is 100%, and the supplierInvoiceId parameter is already described as a required path parameter. The description adds no extra meaning about the ID format or how to obtain it, but for a single-parameter read tool the schema is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetches') and the resource ('one supplier invoice'), and the singular wording distinguishes it from list-style siblings such as bokio_list_supplier_invoices. It does not explicitly name the sibling alternatives, so it stops just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 alternatives like bokio_list_supplier_invoices or bokio_get_invoice. The intended use is implied by the name and parameter, but the description does not state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds no extra context beyond the generic verb. It doesn't mention return format, errors, or anything else, but given annotations cover the main traits, a 3 is baseline.
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?
A single, minimal sentence with no waste. It states the action and object precisely, though it could mention how it differs from list_tag_groups.
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 get operation, the description is minimal but sufficient for an agent to know it fetches one tag group. However, it gives no details about what is returned or any specific behavior, though output schema is absent. Given the simplicity reliable enough.
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% for the single parameter (tagGroupId). The description does not add any explanation beyond the schema, but because the schema fully documents the parameter, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Fetches') and resource ('tag group') with a scope ('one'), which distinguishes it from list_tag_groups. It's clear but doesn't add specificity about the returned fields or filter behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of list_tag_groups for fetching all groups, nor any conditions for selecting this one. The user must infer it's a singular fetch.
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, covering the safety profile. The description adds no extra behavioral context beyond what annotations and the verb 'fetches' imply—no mention of 404 behavior, return format, or any side effects. Since annotations carry the burden, a neutral score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, earning full marks for brevity. However, it lacks structural depth—no front-loading of key details beyond the core action. It is efficient but under-specified, so it does not reach a 5.
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 fetch operation with one parameter and annotations covering safety, the description is minimal but not entirely inadequate. However, it omits usage guidance (when to use vs. list_customers), return expectations, and any error handling, leaving the agent with some uncertainty. Given the low complexity, a 3 reflects that it is functional but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter (customerId) with a basic description 'Path parameter customerId'. The tool description adds nothing about the parameter—it does not explain that the ID must correspond to an existing customer or that it is the unique identifier. With high schema coverage, the baseline of 3 applies, and the description contributes no additional 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 'Fetches one customer' uses a specific verb and resource, and the word 'one' clearly distinguishes it from sibling tools like bokio_list_customers which fetch multiple customers. It is concise and unambiguous, making the tool's purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention that it should be used when a single customer ID is known, nor does it reference the sibling list tool as a fallback for multiple customers. The agent is left to infer the appropriate context from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat that this is a safe read operation. The description adds context about returning debit/credit items, which is useful but minimal. Without an output schema, the description could have mentioned the structure, but given the annotations, the baseline is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively summarizes the tool's purpose without unnecessary fluff. It is front-loaded with the main action ('Fetches one journal entry') and includes relevant detail (debit/credit items). No waste, but could be slightly more informative about usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool with one parameter and no output schema, the description is mostly complete. However, it does not explain what the debit/credit items format looks like or any potential edge cases. Since annotations cover safety, this is adequate but not rich. It could benefit from indicating that the journal entry ID must be a valid existing entry.
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% for the single parameter, which has a description in the schema ('Path parameter journalEntryId'). The tool description does not add any additional meaning beyond what the schema provides. According to the calibration, baseline is 3 when schema covers parameters fully, so this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches one journal entry and mentions the included debit/credit items, which is a specific verb (fetches) and resource (journal entry). It distinguishes from siblings like list_journal_entries by implying a single entry retrieval. However, it doesn't explicitly name the sibling it differs from, so a slight deduction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single journal entry, and the need for a journalEntryId is evident from required parameters. However, it does not explicitly state when to use this tool versus list_journal_entries or other related tools. There is no exclusion guidance or context on when not to use it, so it's only implicitly 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which is a strong safety profile. The description adds one behavioral nugget: 'created by this integration' (scope restriction) and 'limited read' which suggests it may not return all payments. However, 'limited read' is vague—does it limit by the integration filter or by pagination? The description doesn't add much beyond the annotation, but the scope qualifier is useful. No contradiction with annotations, so credit for that.
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?
One short sentence with no waste. It's front-loaded with the core action and scope. It earns its place. Could be slightly more specific but doesn't ramble. A 4 is fair—efficient and clear, though not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with no required parameters and a fully described schema. Annotations cover safety. The description covers the scope. What's missing: no mention of return format or pagination behavior, but given no output schema, the description doesn't need to explain that. However, 'limited read' is ambiguous—does it mean it only returns payments created by the integration, or that it's a restricted capability? That ambiguity leaves a small gap. Overall, adequate for a simple read 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 schema already explains all three parameters (page, query, pageSize). The description adds no additional parameter semantics—it doesn't clarify what 'query' filters on or how pagination works beyond the schema. Baseline is 3 given high coverage; the description doesn't compensate for any gaps, so 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lists') and resource ('bank payments') and adds a scope qualifier ('created by this integration') that distinguishes it from a generic fetch-all. It separates from sibling list tools like bokio_list_accounts by naming the specific entity. The 'limited read' phrase hints at restricted scope but could confuse—'limited' is vague. Still, the core purpose is unmistakable and the scope qualifier is meaningful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to list payments that this integration created, and implicitly not those created outside the integration. It doesn't explicitly state when to use this vs the sibling bokio_list_invoice_payments or bokio_get_bank_payment, though the entity name distinguishes it. There's no 'when not to use' guidance or alternatives named, but the scope qualifier gives some context. This is adequate but not 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 (readOnlyHint: true, idempotentHint: true, destructiveHint: false) already carry the safety profile, and the description aligns with them. The description adds no extra behavioral color beyond the annotations (e.g., no mention of pagination, empty results, or return shape), but it does not contradict them either. Adequate given annotations cover the essentials.
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, minimally expressed, with zero wasted words and the core action front-loaded. There is nothing in the description that should be cut, and for a tool this simple, more prose would be a liability.
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 tool this simple — one required param, full annotation coverage, no output schema and no nested objects — nothing essential is missing for an agent to call it correctly. It could potentially note list semantics or ordering, but the tool's simplicity makes the description effectively complete.
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?
With 100% schema description coverage and a single self-explanatory path parameter (journalEntryId), the schema carries all the parameter documentation burden. The description adds nothing about parameters, but nothing is missing either — baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Lists comments on a journal entry'), and the tool name contrasts with sibling get_* variants. It reads clearly and unambiguously, though it does not explicitly differentiate itself from similarly-named siblings like bokio_get_journal_entry_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives — for example, when to prefer this over bokio_list_journal_entries or bokio_get_journal_entry_comment. There is no when/when-not, no exclusions, and no mention of alternatives. The triviality of the tool mitigates the gap, but no usage guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it returns tag groups with their tags, which is useful context about the response structure. However, it doesn't disclose pagination behavior or any other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and includes a clarifying parenthetical. It's efficient with no wasted words, though it could arguably be slightly more specific about the response format.
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 list tool with no output schema and full schema coverage, the description is adequate. It covers the core purpose and the fact that tags are included. However, it doesn't mention pagination behavior or any filtering nuances beyond what the schema provides, which could be useful for an agent deciding how to call it.
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 all three parameters (page, query, pageSize) with descriptions. The description doesn't add any additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists') and resource ('tag groups'), and clarifies the scope by mentioning examples like cost centers and projects. It distinguishes itself from the sibling 'bokio_get_tag_group' by implying a list operation rather than a single-item fetch, though it doesn't explicitly name the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing tag groups but provides no explicit guidance on when to use this tool versus alternatives like 'bokio_get_tag_group'. The context of listing vs. getting is implied by the verb, but there's no explicit when/when-not guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not repeat that this is a safe, non-mutating operation. It adds useful context by indicating that the tool returns a paged list and specifies the file categories (receipts, documents). However, it does not clarify what fields are returned per item or how query filtering works beyond the schema's basic description. This is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the verb and resource. It wastes no words and covers the essential purpose, though it forgoes optional clarifications about response format. It is appropriately concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description would benefit from a hint about the structure of the returned list (e.g., metadata fields like id, name, type). However, an agent can reasonably infer that the response is a list of upload records, and the annotations cover the safety aspects. The description is adequate for basic invocation but lacks richer context that would help an agent anticipate the payload.
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 provides full descriptions for all three parameters (page, query, pageSize), so schema coverage is 100%. The description adds minimal parameter-level meaning—only the mention of 'paging' which mirrors the page/pageSize parameters. It does not elaborate on how these parameters combine or interpret the query text, but the schema already covers the basics, 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 clearly states the action ('Lists') and the resource ('uploaded files'), and adds specificity by enumerating example file types (receipts, documents) and the paging behavior. This differentiates it from sibling tools like list_invoices or list_credit_notes, which target different resources. It goes well beyond the terse title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is the appropriate choice for enumerating uploads, nor does it contrast with get_upload or download_upload for retrieving a single file. The only implicit signal is the word 'list', which is too weak for effective routing.
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 description need not repeat those. However, it does not clarify the response format (e.g., binary data, file content, or a URL) which would be useful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words or boilerplate, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description is the sole source of information about what the tool returns. It only states the action and resource, leaving the return type and any relevant context unspecified, which may hinder correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions that merely repeat the parameter names ('Path parameter invoiceId'), and the tool description adds no further explanation about what these IDs represent or how they relate to the attachment. The meaning is not clarified beyond the obvious.
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 (Downloads) and the resource (invoice attachment file), making it easy to distinguish from sibling tools like bokio_download_invoice or bokio_download_upload.
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 does not explicitly explain when to use this tool over alternatives, though the name and sibling list provide implicit context. No further guidance on invocation conditions or prerequisites is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is well covered. The description adds no extra behavioral context such as missing-supplier handling, authentication needs, or response shape; it merely restates the read operation.
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 three words, front-loaded, and contains no filler. Every word earns its place, and the core action and target resource are immediately visible.
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 one-parameter read-only getter, the description plus schema and annotations is almost sufficient, but it omits return/error expectations and any hint about how supplierId should be obtained, such as from list_suppliers. These gaps keep it from being fully complete.
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 single required parameter supplierId is already documented as a path parameter. The description adds no further meaning beyond the schema, so it stays at the baseline for fully covered 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 ('Fetches') and a specific resource ('supplier'), and explicitly says 'one supplier', which separates it from list_suppliers and other related getters. It is clear and unambiguous 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The singular wording implies the tool is for retrieving a specific supplier, likely by supplierId, but the description gives no explicit guidance on when to use this tool versus list_suppliers or other get_* tools. No alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the tool supports paging and free-text filtering, which is useful behavioral context beyond annotations, but does not disclose details like default page size, sorting, or filter scope.
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 with no extra words. It immediately states the core action and key capabilities.
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 list tool with optional parameters and annotations covering safety, the description is adequate but misses details such as what fields the free-text filter searches, default ordering, and pagination defaults. An agent may need to infer these from schema or examples.
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%: page, query, and pageSize all have descriptions. The description's mention of 'paging' and 'free-text filtering' aligns with parameters but adds no new meaning beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists') and resource ('customer invoices') and explicitly mentions paging and filtering, which clearly distinguishes it from sibling tools like list_accounts or list_credit_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as list_supplier_invoices or get_invoice. The description only states what it does without naming exclusions or alternate routing.
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 existing annotations already disclose that the operation is read-only, idempotent, and non-destructive. The description adds the file type, 'PDF', and the download intent, but does not explain any additional behavioral details such as response format, permissions, or potentially large file handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no redundant framing or filler. It states the action, resource, and output format efficiently and is 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 single-parameter download operation with rich annotations and no output schema, the description is sufficiently complete. It explains what happens and what output is provided, though it could slightly improve by clarifying the response file behavior beyond just saying 'as a PDF file.'
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, invoiceId, is fully described in the schema as a path parameter. The tool description does not add extra semantic context beyond what the schema already provides, which is acceptable since schema coverage is complete.
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 names a specific verb, 'downloads', the resource, 'invoice', and the format, 'PDF file', which makes the tool's core purpose clear. It is distinct from credit note and upload download tools, though it does not explicitly differentiate itself from the similarly named bokio_download_invoice_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?
Usage context is implied: an agent can infer that it should be used to fetch an invoice's PDF when a specific invoiceId is available. However, the description gives no explicit guidance about when to prefer this over the attachment or credit note download siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds value by stating the response includes line items, payments and status, which conveys scope beyond a bare resource name.
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 with zero waste. The verb, object, and response scope are stated immediately, and the listed contents are the only extra 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 single-parameter read tool with strong annotations, this description is nearly complete. It doesn't mention error cases or whether status includes status history, but those are minor gaps relative to 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 coverage is 100% and the only parameter, invoiceId, is self-explanatory from its name and description. The description doesn't add syntax details, but none are necessary; baseline 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 clear verb with a specific resource and lists what's included in the response ('line items, payments and status'). This distinguishes it from sibling list tools and the settlement/attachment/credit-note variants, although it doesn't explicitly name a sibling it differs from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage — it fetches a single invoice by ID, which naturally contrasts with list_invoices and download_invoice. However, it doesn't explicitly guide the agent on when to choose this over get_invoice_settlement or list_invoice_payments, leaving some inference needed.
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, covering safety and side-effect expectations. The description adds that it returns 'metadata' rather than content, which clarifies return type but lacks detail on what metadata fields to expect. Since the description carries a lighter burden due to strong annotations, a 3 is appropriate.
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, short sentence that is entirely on-topic. It is front-loaded with the core action and resource, and contains no filler or redundant phrasing. Perfectly concise for the tool's simplicity.
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 one parameter and strong annotations, the description is nearly sufficient. It clearly indicates the operation returns metadata, distinguishing it from content retrieval. While it does not enumerate possible metadata fields, that level of detail is not necessary given the tool's simplicity and the schema's explicit parameter documentation.
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 describes uploadId as 'Path parameter uploadId' with 100% coverage, so the parameter is fully documented. The description adds no extra meaning beyond 'one uploaded file', which aligns with the parameter. With high schema coverage, a baseline of 3 is justified.
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 ('fetches'), a resource ('metadata for one uploaded file'), and the singular nature distinguishes it from list operations. It does not explicitly name sibling tools, but the name 'get_upload' and the contrast with 'list_uploads' and 'download_upload' make the purpose clear. It is not tautological and adds resource specificity.
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 does not explicitly state when to use this tool versus alternatives like list_uploads or download_upload. However, the need for an uploadId in the schema and the phrase 'one uploaded file' imply it is for fetching metadata of a specific upload. No exclusions or alternative routes are given, so an agent must infer usage from 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 safety profile is covered. The description adds behavioral context by mentioning paging and filtering capabilities, but does not disclose response format, pagination behavior (e.g., how to navigate pages), or any rate limits. It adds some value beyond annotations but remains shallow.
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, concise sentence that front-loads the core purpose and mentions the main capabilities. No filler or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 operation with a well-documented schema and annotations, the description is largely sufficient. It covers the key features (paging, filtering, tagId) but omits any mention of the response structure or how pagination is handled beyond the page/pageSize parameters, which are already in the schema. The absence of an output schema makes this a minor gap, but not critical for 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 100%—every parameter (page, query, tagId, pageSize) has a description. The tool description simply paraphrases these ('paging, free-text filter and optional tagId') without adding deeper meaning, such as default values, relationships between parameters, or expected query syntax. It adheres to the baseline but adds no extra insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists journal entries (verifikationer) and mentions key capabilities (paging, free-text filter, tagId). It distinguishes from sibling get_* tools by the verb 'list', though it doesn't explicitly differentiate it from other list tools like bokio_list_invoices. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing journal entries but provides no explicit guidance on when to use this tool versus alternatives (e.g., bokio_get_journal_entry for a single entry). There are no exclusions or alternative tool references, leaving the agent to infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only, idempotent, and non-destructive behavior, so the description does not need to restate safety. It does add that paging and free-text filtering are supported, which is useful, but it adds no deeper behavioral context such as authentication, sorting, defaults, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action and immediately communicates the two key operational features, paging and free-text filtering. There is no wasted or redundant text.
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?
This is a low-complexity read-only list tool with fully documented parameters and annotations that already establish its safety profile. The description is sufficient for a typical agent to invoke it correctly, though it would benefit from a brief clarification relative to the similarly named sibling list_invoices.
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%: page, query, and pageSize are already described in the input schema. The description's mention of paging and free-text filtering maps to those parameters but does not add new 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource and action: listing supplier invoices, and mentions paging and free-text filtering. It does not explicitly distinguish this from sibling tools like bokio_list_invoices or bokio_get_supplier_invoice, leaving the reader to infer the difference from the name.
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 paginated, filterable list of supplier invoices is needed. However, it provides no explicit guidance about when to use this versus the regular invoices list or getting a single supplier invoice, and does not name any alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the PDF format detail, which is a minor behavioral clarification but does not describe the response body, file handling, or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, but it largely restates the title 'Download credit note PDF' rather than adding substantial new information. It is appropriately sized for such a simple operation.
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 one-parameter download operation with read-only and idempotent annotations, the description is nearly complete: it names the resource, the action, and the output format. It could be slightly more explicit about returning the raw PDF bytes, but this is strongly implied and the tool is low complexity.
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 single parameter creditNoteId is documented as a path parameter. The description adds no additional semantic meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (downloads), the resource (the credit note), and the output format (PDF). This distinguishes it from siblings like bokio_get_credit_note, which presumably returns structured data, and bokio_download_invoice, which targets a different resource.
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 PDF copy of a credit note is needed, but it does not explicitly state when to prefer this over alternatives such as bokio_get_credit_note. 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is disclosed. The description adds that it supports paging and free-text filtering, which is parameter behavior but not a new side-effect disclosure. It does not add extra behavioral context like authentication requirements or rate limits, but with annotations covering the read-only nature, a 3 is fair.
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: 'Lists inventory/product items with paging and free-text filtering.' Every word contributes, and there is no padding or redundancy. It efficiently conveys the core purpose and capabilities, making it exemplary in conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, annotations covering safety, and no output schema. The description explains the listing purpose and parameter behaviors, but it does not mention what the response contains (e.g., fields, structure, pagination metadata). Without an output schema, the description should at least hint at the return type or typical response shape. This missing information makes it incomplete for an agent preparing to parse the output, so a score of 3 is given.
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%, meaning all three parameters (page, query, pageSize) already have descriptive documentation. The description mentions 'paging and free-text filtering,' which maps to the parameters but does not provide additional meaning beyond what the schema already offers. Per the rubric, the baseline is 3 when schema coverage is high and the description adds no new parameter insight.
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 ('Lists'), a specific resource ('inventory/product items'), and key capabilities ('paging and free-text filtering'). This clearly distinguishes it from sibling list tools for other entities (e.g., customers, suppliers) and from the singular bokio_get_item, which fetches a single item. The purpose is unambiguous and immediately recognizable.
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 context: it lists items, and the name 'list_items' contrasts with 'get_item'. However, it does not explicitly state when to use this tool versus bokio_get_item, nor does it mention any exclusions or alternative conditions. The guidance is implied rather than explicit, so a score of 3 is appropriate.
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 only the SIE format context and fiscal-year scoping, but does not disclose further behavioral details like output encoding, file format specifics, or behavior when no export 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?
The description is a single efficient sentence that front-loads the action and resource, then provides the necessary format context. No wasted words or redundant restatements of the title.
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 one-parameter, read-only download with safety annotations already present, the description is largely sufficient. The only minor gap is that with no output schema, it does not specify the response format or that this returns a file rather than JSON, though the word 'Downloads' and 'SIE export' strongly imply it.
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 fiscalYearId as a path parameter. The description reinforces that the download is 'for a fiscal year' but adds no additional parameter syntax, constraints, or value semantics beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Downloads') and a specific resource ('SIE export'), and clarifies that resource by naming the Swedish standard accounting interchange format. This clearly differentiates it from the many sibling download tools by the unique resource type.
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 an accounting export for a fiscal year is needed, but it does not explicitly state when to prefer this over related tools such as get_fiscal_year or list_fiscal_years. No alternatives or exclusions are mentioned, leaving the usage context 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description's 'Fetches' is consistent. It adds only the one-result cardinality; no additional details about error behavior, auth, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence that is front-loaded and contains no filler. Every word adds value.
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 two-parameter read-only GET with annotations covering the safety profile, the description sufficiently identifies the resource and cardinality. It does not mention the response shape or that commentId must belong to journalEntryId, but those are largely inferable from sibling tools and parameter names.
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%, but both parameter descriptions are tautological ('Path parameter commentId' / 'Path parameter journalEntryId'). The tool description adds no semantic meaning beyond the schema, so baseline 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 and resource: 'Fetches one comment on a journal entry.' The singular 'one' clearly distinguishes it from siblings like bokio_list_journal_entry_comments and bokio_get_journal_entry.
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 singular phrasing implies this is for retrieving a specific comment, but it never explicitly says when to use it versus listing comments or when not to use it. No alternatives 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 declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the paging and filtering behavior, which provides operational context. However, it does not disclose any additional side effects, limitations, or return shape beyond what the annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the purpose and key capabilities. It is front-loaded and contains no filler, making it 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 list tool with all optional parameters and no output schema, the description is sufficient. It conveys the core functionality. However, it does not explicitly mention that the result is a paginated list or how the page parameters interact, though these are inferable from the schema and tool name.
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 documents all three parameters (page, query, pageSize) with descriptions, achieving 100% coverage. The description's mention of 'paging and free-text filtering' loosely maps to these params but adds no extra detail like defaults, constraints, or accepted formats 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?
The description clearly states the tool's action and resource: 'Lists credit notes'. It also mentions paging and free-text filtering, which are the key features. This distinguishes it from siblings like bokio_get_credit_note (which fetches a single note) and other list tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing credit notes with optional filters and pagination, but it does not explicitly contrast with alternatives or state when to prefer this over bokio_get_credit_note or other list tools. The usage context is inferred from the name and description rather than spelled out.
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 read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It does add the behavioral notes 'paging and free-text filtering,' but it does not disclose defaults, sort order, or response details, so the added transparency is moderate.
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 short, well-ordered sentence. It front-loads the core action ('Lists customers') and then adds the two most important modifiers. There is no wasted or redundant language.
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 list operation with no required parameters and full schema coverage, the description is mostly complete. It could add minor context like default page size or what the response includes, but the absence is not a serious gap given the annotations and 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?
Schema description coverage is 100%, so the schema already documents page, query, and pageSize. The description adds only the high-level mapping: 'paging' to page/pageSize and 'free-text filtering' to query. This meets the baseline but does not enrich parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Lists customers' with explicit capabilities ('paging and free-text filtering'). This clearly separates it from single-customer retrieval (bokio_get_customer) and from lists of other entities like bokio_list_suppliers.
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 retrieving a paged, filterable collection of customers, which gives usable context. However, it does not explicitly state when to prefer this over alternatives such as bokio_get_customer, nor does it include any 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 cover readOnlyHint, idempotentHint, and destructiveHint. The description adds no additional behavioral context (e.g., pagination, filtering behavior, or response format), which could be helpful but is not required given 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 with no unnecessary words. It is well-structured and front-loaded with the primary action and resource.
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 standard pagination parameters, the description is complete enough. It does not explicitly mention the return type, but that is implicitly understood. No critical missing information for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for all parameters with clear descriptions (page, query, pageSize). The description does not add any additional 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 clearly states the action ('Lists') and the resource ('fiscal years'), with implicit ownership by the company. It distinguishes from 'get_fiscal_year' (singular) and other list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives like 'get_fiscal_year' or other list tools. However, the plural 'fiscal years' strongly implies listing all, making the intended usage evident from context, but without explicit guidance it remains only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds the paging and filtering behaviors, but does not disclose any additional traits like pagination defaults, sorting, or potential side effects. It neither contradicts annotations nor adds rich behavioral context beyond the feature list.
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 primary action and key features are stated up front, making it easy to scan. 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 tool with three optional parameters and annotations covering safety, the description is largely sufficient. It lacks explicit mention of default pagination or response format, but these are not critical for correct invocation given the schema and the tool's straightforward nature.
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% for all three parameters, so they are well-documented in the schema. The description links 'paging' and 'free-text filtering' to the parameters implicitly, but does not add meaning beyond the schema's own descriptions. 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?
States a clear verb ('Lists'), a specific resource ('suppliers'), and the key modifiers 'with paging and free-text filtering'. This distinguishes it from sibling list tools like list_customers or list_invoices by the resource name and is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for listing suppliers but does not explicitly contrast with related tools such as bokio_get_supplier for single retrieval or mention when not to use it. There is no alternative guidance, leaving the agent to infer from 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, so the description adds the behavioral context that this is a health check verifying connection. However, it does not disclose details like return format or whether it performs a lightweight request. Given the simplicity and annotation coverage, it meets the baseline without adding significant extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key concept ('Health check') and states exactly what it does. There is no wasted wording, making it highly concise and scannable.
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 trivial tool with no parameters and no output schema, the description is sufficient to understand its function. It might benefit from stating what it returns (e.g., a status or boolean), but that is not essential for such a simple operation. Overall, it is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no extraneous parameter information and correctly implies no inputs are needed, which is consistent with the empty 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 the tool's purpose with a specific verb ('verifies') and resource ('MCP connection'), effectively distinguishing it as a health check. Even though a sibling tool 'get_connection_status' exists, the description makes its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the existence of a similar sibling tool like 'get_connection_status' or specify scenarios where a health check is appropriate, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation readOnly and idempotent, so the safety profile is covered. The description adds meaningful context: it only fetches payments created by this integration and returns a single object, which is not something the annotations express. It does not address not-found behavior, but that is a minor gap given the simple read operation.
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 redundant words. Every phrase ('Fetches', 'one', 'bank payment', 'created by this integration') contributes 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 get-by-ID operation with strong annotations and one required parameter, the description is sufficiently complete: it states what is fetched and the integration scope. It could mention how to find the ID (e.g., via list_bank_payments) and response error behavior, but these are not critical 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 coverage is 100% with a description for bankPaymentId ('Path parameter bankPaymentId'), so the baseline is 3. The description adds no further parameter semantics, such as how the ID is obtained or formatted, but none is needed beyond the schema for this simple path 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 uses a specific verb ('Fetches') with a precise resource ('one bank payment') and adds a scoping constraint ('created by this integration'). This distinguishes it from sibling list/get tools, particularly bokio_list_bank_payments, without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The singular 'one bank payment' and required bankPaymentId imply use when a specific ID is available, and a sibling list tool exists for discovery, but the description leaves this 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 cover readOnly, idempotent, and destructive hints. The description adds no extra behavioral details beyond 'fetches', which is consistent but not additional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource without any fluff or 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?
For a simple get operation with two parameters and no output schema, the description is adequate. It does not explain the return value, but for such a straightforward fetch, the context is likely 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?
Schema coverage is 100% with descriptions for both parameters, but they are tautological ('Path parameter invoiceId'). The tool description adds no semantic explanation beyond what the schema provides, keeping the score at the baseline for high 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?
The description clearly states the action ('Fetches') and the resource ('one payment on an invoice'), distinguishing it from sibling tools like get_invoice_settlement or get_invoice_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single payment, but does not explicitly contrast with alternatives or state when not to use it. The context from the tool name and sibling list provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the filtering capability but provides no additional behavioral details like pagination or return format. It is consistent with annotations, so a 3 is appropriate.
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, well-structured sentence that front-loads the primary purpose and immediately mentions the optional filter. 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?
For a simple list tool with one optional parameter, the description is sufficient. It clearly indicates the account listing and the free-text filter. It does not mention pagination or sorting, but these are not critical for a basic list operation and no output schema exists to elaborate on the return format.
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 schema has 100% coverage but the parameter description ('Query parameter query') is meaningless. The tool description clarifies that the query parameter is for free-text filtering, which is essential information that the schema fails to convey. This adds significant value 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 clearly states the tool lists the chart of accounts and optionally filters by free text. This distinguishes it from siblings like bokio_get_account (single account) and other list tools for different resources.
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 list of accounts is needed, and the optional filter clarifies how to narrow results. However, it does not explicitly mention when to use this tool over alternatives, such as bokio_get_account for a single account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only, idempotent behavior; the description confirms the listing operation but adds no extra transparency, hence a moderate score.
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 concise sentence that gets to the point without 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 description is adequate for the simple listing operation, though it doesn't mention pagination or filtering explicitly, which are implied by the parameters.
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 provides descriptions for all parameters, and the tool description adds no additional meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (lists) and the resource (payments on an invoice), distinguishing it from singular get operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to list all payments for an invoice) as opposed to getting a single payment, though it doesn't explicitly mention 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, covering the safety profile. The description adds minimal behavioral context beyond 'Fetches', which aligns with annotations but does not introduce new traits like return format or error behavior. No contradiction, but no additional transparency either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is efficient and to the point. The verb and resource are front-loaded, and the example is placed at the end without any filler. 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 get-by-ID tool with one parameter and no output schema, the description is largely complete. It explains what is fetched and gives an example. It doesn't describe the response format, but that is not critical given the simplicity, and no output schema exists to rely on. Slight gap in not mentioning what the response contains, but acceptable.
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 schema description for the parameter is minimal ('Path parameter account'), providing little semantic meaning. The tool description compensates by clarifying that the account is identified by a number (e.g. 1930), adding format context that the schema lacks. This exceeds the baseline 3 for high 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?
The description states a specific verb ('Fetches'), a specific resource ('one account'), and a clear identifier ('by its number'). It also gives an example (1930) that clarifies the format. This clearly distinguishes it from the sibling list tool.
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 need a single account by its number. It doesn't explicitly mention when not to use it or point to the list alternative, but the naming and phrasing make the conditional clear enough. The example adds practical 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 read-only, idempotent, and non-destructive behavior. The description adds useful context about what the status includes, but doesn't mention any side effects (though none are expected given 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 concise sentences with no filler. The usage guideline is front-loaded, making the purpose immediately clear.
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 no output schema, the description doesn't detail return values, but it provides sufficient context for when to invoke the tool and what it reports. Adequate for a simple status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is effectively complete. The description doesn't need to explain parameters, and the baseline score of 3 applies since there's nothing to add.
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?
Clearly states a specific action ('Shows') and the resource (connection status, token health, write operations). Distinguishes itself from sibling tools by being a diagnostic/status check.
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?
Explicitly instructs when to use it: 'Call this first if another tool reports an authentication problem.' Also implies it's for general status verification.
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 behavior, so the description is not required to reiterate those. It adds value by specifying the returned fields, but does not mention error scenarios or response format. Adequate for a simple read operation.
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 directly states the function and the data returned. No unnecessary words or elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and no output schema provided, the description sufficiently indicates what the tool returns. It is complete for a simple fetch operation without additional context needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema fully covers parameter semantics. The description correctly notes the absence of inputs, leaving nothing ambiguous.
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 'Fetches' and the resource 'company's registered information', listing specific fields (name, org number, type, address). This distinguishes it from sibling tools that fetch other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when company-level information is needed, but does not explicitly state when to prefer this over alternatives. Given the unambiguous resource scope, the intent is clear without explicit instructions.
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:

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

Score Badge

Copy to your README.md:

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

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