Read invoices, offers, payment status and the product catalog in Solo.
Scored across 7 tools
Each tool targets a distinct resource and action: invoice vs. offer vs. catalog, and list vs. get vs. status. The descriptions explicitly clarify the relationship between list and get tools, leaving no meaningful overlap.
All seven tools follow a consistent solo_verb_noun pattern with snake_case. The invoice and offer families mirror each other predictably, making selection easy.
Seven tools is well-scoped for a focused invoicing/offers/catalog integration. Each tool earns its place by covering a distinct resource or status view.
Read coverage is solid for invoices, offers, and the catalog, including status and PDF links. However, the surface is entirely read-only: there are no create, update, delete, send, or payment-recording operations, which are notable gaps for an invoicing domain.
Get one invoice with buyer, line items, taxes, totals, payment method, dates, IBAN, currency and a PDF link. The id is the long hash from solo_list_invoices. Solo API: GET /racun?id=.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes | Invoice id (hash) from solo_list_invoices. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read, so the description's main job is to add context. It does so by listing the returned data (buyer, line items, taxes, totals, payment method, dates, IBAN, currency, PDF link) and naming the underlying API endpoint, though it omits error behavior for invalid IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, first stating what is returned and then explaining the ID source. The API endpoint note is useful context but is slightly tacked on rather than integrated, keeping it just below a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining return contents, and it does so thoroughly by enumerating the invoice fields. With one simple parameter and its source documented, an agent has everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already says the parameter is the invoice hash from solo_list_invoices. The description adds 'long hash' as a slight emphasis but largely repeats 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Get one invoice') and enumerates the returned fields, so its purpose is unmistakable. It does not explicitly distinguish itself from the sibling solo_get_invoice_status, which is the main gap keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent where the invoice_id comes from ('the long hash from solo_list_invoices'), which is a useful workflow prerequisite. However, it gives no explicit when-to-use versus solo_get_invoice_status or solo_list_invoices, leaving usage to be inferred from the field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the payment status of one invoice: status code, colour and the payment date (datum_uplate, empty if unpaid). Solo API: GET /status?id=.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes | Invoice id (hash) from solo_list_invoices. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds useful return semantics ('datum_uplate, empty if unpaid'), but says nothing about failure modes for an invalid or unknown invoice id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: the purpose and return fields come first, with the trailing endpoint hint as a minor cost. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read with no output schema, the description does the necessary work by naming the returned fields and explaining the empty-unpaid case. Only error/not-found behavior is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter is already documented as an invoice hash from solo_list_invoices. The description's 'GET /status?id=' merely restates the parameter without adding format or validation meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('Get the payment status of one invoice') and enumerates the returned fields (status code, colour, datum_uplate). It implicitly differentiates from solo_get_invoice by being status-only, but never names the sibling, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the lightweight status check versus solo_get_invoice or solo_get_offer_status, but no explicit when/when-not or alternative is stated. The 'Solo API: GET /status?id=' line adds endpoint context but not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one offer with buyer, line items, taxes, totals, dates, currency and a PDF link. The id is the long hash from solo_list_offers. Solo API: GET /ponuda?id=.
| Name | Required | Description | Default |
|---|---|---|---|
| offer_id | Yes | Offer id (hash) from solo_list_offers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, so the description's added value is in disclosing the returned payload (buyer, line items, taxes, totals, dates, currency, PDF link) and the underlying endpoint GET /ponuda?id=. That is genuinely useful given there is no output schema. It omits error behavior for an invalid or missing offer, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with what the tool returns and followed by the id-provenance hint. No filler. The endpoint string is low value for an agent but cheap and occasionally useful for debugging.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, no output schema, and readOnlyHint covering safety, the description supplies exactly the missing piece: the shape of the returned offer. Only the absence of any failure-mode or not-found context keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema field already says "Offer id (hash) from solo_list_offers", so the description's "long hash from solo_list_offers" largely restates it. The only marginal addition is the word "long" hinting at the id format. Baseline 3 is appropriate when the schema carries the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb + resource ("Get one offer") plus an enumeration of the payload (buyer, line items, taxes, totals, dates, currency, PDF link), which makes it clearly a single-record fetch. It distinguishes itself from solo_list_offers by referencing it as the source of the id, but never contrasts with solo_get_offer_status, the sibling an agent could plausibly confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through the workflow hint that the id comes from solo_list_offers. There is no explicit statement of when to call this versus solo_get_offer_status, nor any note about what happens when the id is unknown or stale. Adequate for a trivial single-id getter, but no real routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status code and colour of one offer. Solo API: GET /status?id=.
| Name | Required | Description | Default |
|---|---|---|---|
| offer_id | Yes | Offer id (hash) from solo_list_offers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares this is a safe read, and the description adds the underlying endpoint (GET /status?id=) and the shape of what comes back (status code and colour). It says nothing about error behavior for an unknown or expired offer id, which is the main remaining unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the outcome stated first and the endpoint mapping second; nothing is redundant. The trailing 'id=' fragment is slightly cryptic but costs almost nothing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read with no output schema, the description telling the agent it gets a status code and colour is the key missing piece and it is present. Only failure/edge-case behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter is already documented as the offer hash sourced from solo_list_offers. The description adds no format or validation detail beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (get status of one offer) plus the returned fields, which implicitly separates it from solo_get_offer and solo_get_invoice_status. It never names a sibling explicitly, so an agent must infer that this is the narrow status-only lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not guidance is given; the description doesn't say to prefer this over solo_get_offer, nor that it's a follow-up after solo_list_offers. Only the schema's parameter note hints at the listing prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the products and services in the Solo catalog: code (sifra), KPD code, description, unit, quantity, price, discount and tax rate. Solo API: GET /katalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the description's main additions are the underlying endpoint (GET /katalog) and the returned field set. It says nothing about result volume, ordering, pagination, or whether the whole catalog comes back in one call — meaningful gaps for a list operation against a catalog.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first front-loads the action and the payload contents, the second pins the backing endpoint. Every clause carries information and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description usefully compensates by enumerating the returned fields, which is exactly what an agent needs to plan post-call handling. The remaining gap is operational: no guidance on result size or paging for a catalog list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly signals a no-argument call rather than implying hidden filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') plus resource ('products and services in the Solo catalog') and even enumerates the fields returned (code/sifra, KPD code, description, unit, quantity, price, discount, tax rate). The resource is inherently disjoint from the sibling tools (invoices, offers), so no agent could confuse it with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the tool to reach for when it needs catalog items rather than invoices or offers, but the description never says so explicitly. There are no stated preconditions, no exclusions, and no mention of how to narrow or page a potentially large catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the last 1000 invoices (račun) of the Solo account: id, number, date, gross total, status and status colour. Use solo_get_invoice with an id for full details. Solo API: GET /racun.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (only needed when there are more than 1000 documents). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's job is to add context, and it does: a hard cap of the last 1000 invoices, the fields returned, and the underlying GET /racun endpoint. It stops short of stating ordering or what happens at the page boundary, but the safety profile is fully covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the resource and the 1000-document cap, followed by the sibling pointer and endpoint. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming every returned field, and it covers the retrieval limit, pagination implication, and the detail-lookup alternative. An agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single `page` parameter already documents the >1000-document case. The description's 'last 1000 invoices' framing corroborates but does not add syntax or semantics beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list invoices of the Solo account) and enumerates the exact fields returned: id, number, date, gross total, status, status colour. It also distinguishes itself from the sibling read tool by scoping itself to listing rather than detail retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes detail lookups to solo_get_invoice 'with an id', giving the agent a clear alternative. It does not spell out the inverse condition (when not to list), but the list-vs-detail split is unambiguous in practice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the last 1000 offers (ponuda) of the Solo account: id, number, date, gross total, status. Use solo_get_offer for full details. Solo API: GET /ponuda.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (only needed when there are more than 1000 documents). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds genuinely non-structured behavior: a hard 1000-record cap per listing and the underlying endpoint (GET /ponuda). It does not explain how to page past the cap beyond what the schema implies, so it stops short of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact clauses: what is returned, which sibling to use for detail, and the underlying endpoint. Scope and returned fields are front-loaded with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by listing the returned fields (id, number, date, gross total, status). Minor gap: no guidance on iterating pages or how many records remain, but for a simple paged list this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'page' parameter is already documented in the schema, so the description's mention of the 1000-document threshold only reinforces existing context. Baseline 3 applies since the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (List) + resource (offers) with explicit scope ('last 1000 offers of the Solo account') and an enumeration of returned fields. The final clause routes detail-seeking callers to solo_get_offer, so it is distinguishable from that sibling without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative ('Use solo_get_offer for full details') and makes the list-vs-detail tradeoff obvious. It does not state when-not to call this (e.g. no filtering is supported, so filtered lookups must go elsewhere), which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
solo_get_invoicesolo_get_invoice_statussolo_get_offersolo_get_offer_statussolo_list_catalogsolo_list_invoicessolo_list_offersRead invoices, bills, contacts, bank balances and financial reports in Kledo.
Read SaldeoSMART companies, contractors, documents, invoices, bank statements and employees.
Read Bsale products, documents and stock; manage customers, prices, receipts and payments.
Read SalesBinder customers, inventory, warehouse locations, invoices and sales orders.
Add one secure layer between your agents and this server.