mcp-bigcapital

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Tools are generally named around distinct Bigcapital resources (vendor, customer, bill, invoice, expense, journal, receipt, payment, report), so an agent can usually tell them apart. The main ambiguities are between payments received and bill payments, and among status-changing actions like open_bill, publish_expense, and close_sale_receipt, but the descriptions are clear enough to resolve those.
Naming Consistency5/5
Tool names consistently follow a lower_snake verb_noun pattern: list_*, get_*, create_*, update_* across resources, with a few expected domain verbs like open, publish, and close. Even compound resources like get_attachment_presigned_url still follow a predictable action-first structure.
Tool Count1/5
With 57 tools, this is an extreme tool surface that will be costly for an agent to navigate and likely to cause misselection. Although the accounting domain is broad, this many operations should be split into focused server modules rather than exposed as one flat set.
Completeness3/5
The toolset covers a wide range of accounting lifecycles: customers, vendors, items, invoices, bills, expenses, receipts, payments, journals, attachments, and key financial reports. However, delete operations are almost entirely absent, and accounts are read-only (list/get but no create/update), leaving some workflows without full lifecycle support.
Average 2.7/5 across 57 of 57 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and offers only 'Open a bill,' with no consequences, state change, permissions, or return behavior. An agent cannot tell if this is a read, status transition, or side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified rather than concise. It omits essential context and does not use structure to clarify behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, a one-sentence definition leaves major gaps: what 'opening' does, whether the bill status changes, and what the response contains. Sibling tool names such as get_bill and update_bill only heighten the ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no explanation beyond the schema's id field. The id parameter is conventional enough to infer it identifies the bill, but the description provides zero semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely restates the tool name with a generic verb and no object scope. 'Open' is ambiguous between retrieving, marking as open, or updating a bill, and nothing distinguishes this from get_bill, update_bill, or list_due_bills.
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 information is provided about when to use this tool over siblings or when not to use it. The absence of alternatives and conditions leaves an agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing behavior, but it only states the obvious mutation. It does not mention required permissions, irreversibility, side effects on related bills, error cases, or the response format, and even the schema note that body is passed through to Bigcapital is not surfaced in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but that brevity comes from under-specification rather than efficient packaging. It contains no front-loaded scoping, caveats, or routing clues, so the single sentence does not earn its place as a useful definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with a free-form nested body, no output schema, no annotations, and many accounting siblings, this description omits nearly everything needed to safely invoke it. An agent cannot determine valid body payload, required state of the bill payment, or expected return.
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 schema already names id and body, where body is described as a pass-through object; the description adds no parameter-level meaning. With schema coverage at only 50% and no elaboration on what should go into the body, the definition falls short of helping an agent construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a bill payment.' restates the tool name almost verbatim and identifies the operation and object type, but offers no details on what fields can be updated or how it differs from update_bill or update_payment_received. It is a tautology rather than a functional definition.
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 the many sibling tools, such as create_bill_payment, get_bill_payment, or update_bill. The description provides no context cues, prerequisites, or exclusion criteria, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states the action without explaining whether the update is partial or full replacement, whether the body is passed through to Bigcapital, what side effects occur, or what the response will look like. There is no behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short, but that brevity reflects under-specification rather than deliberate conciseness. It has no front-loaded value beyond restating the tool name and leaves the agent with no actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, a nested passthrough body parameter, and many sibling tools, the description is completely inadequate. It fails to convey required context such as how the body should be structured, prerequisites like customer existence, or any behavior following the update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contributes no parameter-level meaning. The schema documents the 'body' parameter as a passthrough to Bigcapital and constrains 'id' as a positive integer, so some semantics exist structurally, but the description neither expands on these nor clarifies the expected shape of the body. With 50% schema description coverage and no support from the description, parameter understanding relies on inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a customer' simply restates the tool name 'update_customer' without adding any scope, nuance, or distinction from sibling tools such as create_customer, get_customer, or update_vendor. It identifies the verb and resource but provides nothing beyond what the name already communicates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. It does not mention that create_customer is for new records, get_customer is for retrieval, or update_vendor is for vendors. The description offers only the tautological implication that you should use it to update a customer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavioral implications, but it only states that the tool updates. It does not disclose whether the update is partial or full, what side effects occur, what permissions are required, or whether it is reversible. The agent is left without any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It is not meaningful conciseness; it is a restatement of the tool name that fails to use its sentence to convey any actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a required free-form body parameter, this description is far from complete. An agent cannot determine how to construct the request body, what the update affects, or what the expected result is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: id has no description, and body is an open object described only as 'Request body passed through to Bigcapital'. The tool description provides no additional meaning about either parameter, leaving the required request body structure completely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an item.' simply restates the tool name in natural language and adds no new information. It names the resource but does not distinguish update_item from the many other update_* siblings beyond the resource label already present in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as create_item, get_item, or list_items. No context, prerequisites, or exclusion conditions are provided, so an agent must infer usage entirely 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only repeats the update action implied by the name and provides no information about effects, idempotency, permissions, validation, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but that is under-specification, not conciseness. The single sentence contributes no information beyond the tool name and fails to explain anything about the update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an update tool with two required parameters, no annotations, and no output schema. The description provides none of the context an agent needs to invoke it correctly: what 'body' should contain, what 'id' refers to, or what happens after the update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: 'id' has no description, and 'body' is only described as a pass-through object. The description itself adds no meaning to either parameter, leaving the meaning of 'body' and its accepted structure entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology: 'Update a manual journal.' exactly restates the tool name without adding any detail about what an update involves or how it differs from related manual-journal tools like create_manual_journal or publish_manual_journal.
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 creating, publishing, or fetching a manual journal. The sibling list includes closely related operations, but the description provides no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides none. Publishing implies a state change or finalization, yet the description does not mention permissions, irreversibility, side effects, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of filler, but the brevity comes from omitting essential details rather than distilling useful information. It is concise in form but not appropriately sized for the content an agent needs.
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?
The tool is simple with one integer parameter, so the schema covers basic invocation. However, the description does not explain the publish operation's purpose or consequences, leaving the agent to guess what happens after the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the 'id' parameter beyond its raw name. It fails to state that the id identifies which expense to publish or how it should be obtained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Publish an expense' is essentially a direct restatement of the tool name, making it a tautology. It does not explain what 'publish' means in the accounting context—e.g., finalizing, posting, or submitting—nor does it distinguish the action from update_expense or create_expense.
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 about when to use this tool versus alternatives. The description gives no context about whether publishing happens after an expense is created, whether it is for approval workflows, or when it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects, required setup, posting behavior, or consequences of creating a journal. It discloses none of these, only stating the action itself. This is a significant gap for a mutating financial operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than usefully concise. A single sentence that merely restates the tool name does not earn credit for good structure because it omits essential operational and parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no annotations, no output schema, a pass-through nested body, and a manual journal is a domain-specific financial object, the description is far from complete. An agent has no way to know the required body structure, validation rules, financial implications, or success behavior.
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 one parameter, 'body', with a description that it is passed through to Bigcapital, so schema description coverage is 100%. The tool description adds no parameter semantics beyond the schema, but per the baseline for high coverage, a 3 is appropriate. Still, the schema's own description is quite limited and does not explain what fields the body should contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name as a sentence: 'Create a manual journal.' It names a verb and resource but adds no contextual detail about what a manual journal is or how this operation differs from related journal or create operations. This is effectively a tautology rather than a clarifying definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as update_manual_journal, publish_manual_journal, or create_invoice. The description provides no context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure, but it only restates the mutation ('Update') without describing side effects, required receipt state, idempotency, or response behavior. It does not misrepresent the operation, so it is not a 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short, but this is under-specification rather than efficient conciseness. There is no front-loaded detail beyond the name, so the sentence contributes no additional value.
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 mutation tool with no annotations, no output schema, and a free-form body parameter, the description is not complete enough to invoke correctly. It fails to explain what an update affects, what the body should contain, or any constraints around updating a sale receipt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter meaning; neither 'id' (which has no schema description) nor the opaque 'body' object is explained. The schema offers only 'Request body passed through to Bigcapital' for body, leaving the identifier semantics and expected payload unknown.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a sale receipt.' is an exact restatement of the tool name and adds no extra semantic detail about what updating entails. It identifies a verb and resource but does not distinguish this update from close_sale_receipt, create_sale_receipt, or the other update_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided: there are no scenarios, exclusions, or mentions of when to prefer close_sale_receipt/get_sale_receipt or the other update_* tools. The only usage signal is implicit in the word 'update'.
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?
No annotations are present, so the description carries the full burden of disclosing behavioral traits. It only says 'update,' which implies mutation, but it does not state whether the update is partial or full replacement, whether it is idempotent, what permissions are required, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and free of filler, but it achieves brevity by merely restating the tool name. It is structurally simple and front-loaded, yet it provides so little content that the conciseness is not a meaningful strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with no annotations and no output schema, this description is severely incomplete. An agent has no way to know what fields belong in the body, whether a full replacement is required, what the success or error responses are, or how this operation behaves in relation to other vendor operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description does not compensate. The 'id' parameter has no schema description and no explanation in the tool description, while the 'body' parameter is vaguely described as a pass-through request body without enumerating acceptable vendor fields or update semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a vendor' simply restates the tool name 'update_vendor' in sentence form, so it adds no information beyond the identifier. It nominally identifies the verb and resource, but because it is a direct tautology of the name, it does not meaningfully distinguish itself from siblings such as create_vendor or get_vendor beyond what the name already communicates.
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 offers no guidance about when to use this tool versus alternatives like create_vendor, get_vendor, or list_vendors. There is no context about prerequisites, common workflows, or cases where a different vendor-related tool should be preferred.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only conveys a read-like 'Get' operation. It does not explain that results differ by basis (cash vs accrual), that the date range is optional, how zero-balance accounts are handled given the noneZero/showZero flags, or what the report output looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short and front-loaded with zero waste. However, the brevity reflects under-specification rather than disciplined conciseness, since the sentence simply restates the tool's name and leaves all substantive content absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Treating this as a report-generation tool with 8 parameters, no annotations, no output schema, and a single-sentence description, it is far from complete. An agent cannot determine the report's structure, how the date filter behaves when omitted, or what the zero/transaction boolean flags mean — making correct invocation largely guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (just fromDate/toDate have descriptions), so the description must compensate for 8 under-documented parameters, but it mentions none of them. Notably confusing parameters such as noneZero vs showZero, noneTransactions, and accountIds receive zero explanation in either the schema or the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('receivable aging summary report'), and the word 'receivable' distinguishes it from its payable counterpart. However, it is essentially the tool name restated with 'report' appended; it adds no information about what an aging summary contains (e.g., bucketed overdue amounts) beyond the 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?
No guidance is given for when to use this report versus alternatives. A direct sibling, get_payable_aging_summary, exists, as do other report tools, but the description offers no selection criteria, no date-range prerequisites, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only repeats the fact that the tool creates a vendor. It does not explain side effects, required permissions, idempotency, validation behavior, or the passthrough to Bigcapital, leaving the agent without transparency into what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is under-specified rather than appropriately concise. It provides no more information than the tool name, so brevity comes at the cost of usefulness.
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 creation tool with an opaque nested body parameter and no output schema, the single sentence does not tell an agent what fields the Bigcapital API expects, whether a vendor account is created immediately, or what success/error responses look like. The context is incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the body parameter's description says it is 'passed through to Bigcapital', and additionalProperties allow arbitrary content. The main description adds no parameter semantics, but the schema is sufficiently explicit, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a vendor.' is a direct restatement of the tool name, so it names the verb and resource but adds no new information that would help disambiguate it beyond the name. It does not mention the Bigcapital integration, how it differs from update_vendor or create_customer, or any specifics of what constitutes a vendor.
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 for when to use this tool instead of update_vendor, get_vendor, or list_vendors, nor are any prerequisites or exclusion conditions mentioned. The only usage cue is the verb 'create', which is already present in the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not communicate whether updates are partial or full replacements, what side effects occur, whether status transitions or validations apply, or any permission/authtorization implications. The single word 'Update' merely indicates mutation with no added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it is under-specified rather than appropriately concise. It front-loads the core operation but fails to include the substance an agent needs, similar to a truncated placeholder rather than a deliberately concise definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, no annotations, and a free-form body, the description is drastically incomplete. The agent receives no information about expected body fields, how to obtain the invoice id, what responses look like, or any behavioral constraints. The description adds virtually no context beyond what the tool name already conveys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meanings. The schema already documents 'body' as a pass-through to Bigcapital and leaves 'id' without a description, so the description doesn't compensate for the 50% schema coverage gap. An agent is left unsure how to construct the body or what 'id' identifies.
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 clear verb ('Update') and a resource ('a sale invoice'), which clarifies this is a sales-side invoice operation and distinguishes it from sibling tools like update_bill and update_expense. However, it provides no detail about what fields or aspects can be updated, so it stops short of a fully informative purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as create_invoice, get_invoice, or update_bill. The only implied usage is that updating a sale invoice would go here, with no context on prerequisites, exclusions, or conditions favoring a sibling tool.
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?
With no annotations provided, the description carries the full burden. It only states the generic creation action and gives no information about side effects such as whether the invoice is posted, drafts vs delivered status, inventory impact, or accounting entries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is brief and front-loaded, but it is under-specification rather than conciseness. For a tool with 21 parameters and no output schema, this level of brevity fails to provide required context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is highly incomplete given the tool's complexity: no output schema, no annotations, no explanation of return values, required relationships, or error conditions. An agent cannot confidently construct a correct call from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 5% (one parameter has a description), and the tool description adds nothing about parameters. The agent is left with a large schema full of $refs and enum-only fields, with no explanation of what values mean or how they interrelate.
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 ('Create'), a specific resource ('a sale invoice'), and the system ('Bigcapital'). This is clear and distinguishable from related tools like create_bill or create_sale_receipt, though it doesn't explicitly call out those differences.
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 such as create_sale_receipt or update_invoice. It also omits prerequisites like the customer and items needing to exist, or when a sale invoice vs a receipt is appropriate.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but nothing is said about report contents, balance calculation, date interpretation, zero-balance handling, or default behavior. The description reveals no meaningful behavioral traits beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, but it is severely under-specified for a tool with 8 parameters and no output schema. It functions more like a stub than a carefully concise description, so it does not earn its place by carrying necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 25% schema description coverage, no annotations, and no output schema, this one-line description is inadequate. The agent lacks essential context about date handling, accounting basis, filtering, and return structure, leaving the definition incomplete for a report tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description itself mentions no parameters. It does not clarify ambiguous fields like noneZero, showZero, noneTransactions, basis, or accountIds, so an agent cannot make informed parameter decisions from this definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get the payable aging summary report.' This clearly identifies the deliverable and distinguishes it from the sibling get_receivable_aging_summary by the 'payable' qualifier. However, it does not explicitly call out that sibling or any scope boundaries, so it falls 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?
There is no guidance about when to use this tool over alternatives such as get_receivable_aging_summary, list_bills, or open_bill. The intended use is implied by the name, but the description provides no explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Get the report', providing no information about defaults, date-range handling, whether the operation is read-only, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is succinct but under-specified rather than concise. It omits essential operational context and does not earn its place as a sufficient descriptor for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 0 required, no output schema, and no annotations, the description is far too thin. It does not explain how to form a report request, what defaults apply, or what the result represents, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only ２０% and the description names no parameters. It does not explain basis, displayColumnsBy, noneZero, precision, accountIds, or other options, leaving the agent without meaningful guidance for the 10 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 states the specific verb 'Get' and the specific resource 'Bigcapital profit and loss report', which clearly distinguishes it from sibling report tools like get_balance_sheet and get_trial_balance. There is no ambiguity about which tool this is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this report versus alternative financial reports, nor does it mention any exclusions or conditions. The agent must infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only indicates a read operation via the verb 'get,' but does not explain report behavior such as how date ranges or zero-balance transactions are handled, whether the report is aggregated, or what data it returns. This leaves significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single near-tautological sentence that merely restates the tool name with the word 'report' appended. While it is short, it is under-specified rather than appropriately concise, failing to add value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, a one-line description is grossly inadequate. The agent has no context about behavior, parameters, or return values, making correct invocation nearly impossible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (fromDate and toDate), and the description provides no parameter information whatsoever. The many boolean parameters (noneZero, showZero, noneTransactions) and accountIds are entirely unexplained, so an agent cannot determine how to set them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the transactions by customers report.' It clarifies that the tool retrieves a report aggregating transactions by customer, which distinguishes it from list tools that return raw transactions. However, it does not differentiate from sibling report tools like get_general_ledger or get_receivable_aging_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_profit_loss or list_customers. The description only states what the tool does, leaving the agent to infer from the name. No exclusions, prerequisites, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it only says 'Get the report.' It does not mention that this is likely a read-only operation, how report defaults work, whether date ranges are enforced, or what the returned report structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and free of fluff, but it is under-specified for a tool with 9 parameters and no additional context. Conciseness is achieved at the cost of needed substance, so it is not appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description is the sole source of guidance. It fails to address parameter semantics, defaults, selection criteria, or return value expectations, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22%, and the description adds no parameter-level context. The tool has 9 parameters including accountIds, noneZero, showZero, onlyActive, and noneTransactions, but the description does not help the agent understand their meaning or combinations.
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 ('Get') and resource ('Bigcapital trial balance report'), making the core purpose unambiguous. It is clearly distinct from sibling report tools such as get_profit_loss, get_balance_sheet, or get_general_ledger, since 'trial balance' names a unique report type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternative report tools like get_general_ledger or get_balance_sheet. No use cases, exclusions, or conditions are provided, leaving the agent to infer when this report is appropriate.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it only implies a read-style report retrieval. It doesn't explain default date-range behavior, what the cash-vs-accrual basis changes, what the three boolean filters (noneZero, showZero, noneTransactions) do, or what the output contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is compact and front-loaded with the verb, but it is under-specified rather than genuinely concise. It states the core purpose without wasting words, yet fails to carry any of the operational detail the tool needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An 8-parameter report tool with no annotations, no output schema, and no sibling differentiation is completely underserved by a one-line description. An agent cannot determine the effect of the basis switch, the filters, or the accountIds, nor what the returned report looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (fromDate/toDate), and the description adds zero parameter meaning. Six of eight parameters, including the ambiguous noneZero/showZero/noneTransactions flags, are left entirely undocumented in both the schema and the description.
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 ('Get') and resource ('the cashflow statement report'), so an agent knows what action to expect. However, it does nothing to set the cash flow report apart from sibling report tools like get_profit_loss, get_balance_sheet, or get_trial_balance, so it cannot 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?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention that this report complements profit/loss, balance sheet, trial balance, or general ledger reports, and gives no exclusions or conditions.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says "Get the general ledger report" and does not mention read-only behavior, default basis, date filtering, zero-balance handling, precision defaults, or response characteristics. The word "Get" weakly implies retrieval, but this is not meaningful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than appropriately concise. One generic sentence does not earn its place for a report tool with eight parameters and several sibling reports.
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 annotations, no output schema, eight optional parameters, and many sibling report tools, this description is incomplete. An agent has no information about defaults, filtering semantics, or what differentiates this report from similar financial reports.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, yet the description adds no meaning for any parameter. It does not explain noneZero, showZero, noneTransactions, accountIds, basis, or precision, leaving an agent without enough information to choose or combine these filters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: "Get the general ledger report." This unambiguously identifies the action and object, but it does not distinguish this from sibling report tools like get_trial_balance or get_profit_loss, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_trial_balance, get_profit_loss, or get_balance_sheet. The description only states what the tool does, with no context, exclusions, or alternative routing.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Update' and does not state whether the operation patches or replaces, whether the record must already exist, what happens on failure, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single short sentence with no wasted words, so it is structurally easy to read. However, it is so terse that it under-specifies the tool's behavior, which moves it from genuine conciseness to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a required nested body, no output schema, and no annotations, an agent needs more context to call this tool correctly. The description does not explain the body structure, the update semantics, or the expected response, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: the id parameter has no semantic description, and body is only described as 'Request body passed through to Bigcapital'. The tool description adds nothing to explain what fields the body should contain or how the parameters relate to the update operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Update' and the resource 'payment received record', so the action is unambiguous. However, it is essentially a rephrasing of the tool name and adds no detail about what specific fields or effects an update involves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool instead of related tools like create_payment_received, get_payment_received, or list_payments_received. No conditions, prerequisites, or exclusions are mentioned, so an agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Update an expense' only confirms that this is a mutation operation, but it does not disclose whether the update is partial or full replacement, what happens if the expense does not exist, permission requirements, or any side effects. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no wasted words. However, it is under-specified rather than appropriately concise; given the nested body object and mutation semantics, more explanatory content is needed. It is not a tautology like 'Process,' but it borders on minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested body parameter, no annotations, no output schema, and only 50% schema parameter coverage, this description is woefully incomplete. It provides no guidance on constructing the body, interpreting the id, handling errors, or understanding the response. An agent would have almost no information beyond the name itself.
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 schema description coverage is only 50% — the body parameter has a description ('Request body passed through to Bigcapital'), but id has none. The tool description itself adds no parameter meaning beyond the schema; it does not clarify how id should be used or how the body should be structured, beyond the opaque note already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Update an expense.' This distinguishes it from siblings such as create_expense, get_expense, list_expenses, and publish_expense. However, it provides no additional scope or context beyond what the tool name already implies, so it does not reach the level of a fully informative 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?
There is no guidance about when to use this tool versus alternatives. The description does not mention when to prefer update_expense over create_expense or other update_* tools, nor does it address any prerequisites or exclusions. This leaves 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says 'Close a sale receipt' without explaining whether the operation is reversible, changes the receipt status, marks it finalized, or requires special permissions. It does not contradict annotations because no annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words and is appropriately front-loaded. However, it is so minimal that it borders on under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing operation with no annotations and no output schema, the description is incomplete. It does not explain what closing a sale receipt entails, any constraints on the receipt's current state, or what the caller should expect afterward. The single-parameter schema reduces complexity, but the absence of lifecycle context leaves a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the id parameter at all. The parameter is somewhat self-explanatory from its name and type, but the description adds no semantic value about which sale receipt to close or how the id is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Close') and a specific resource ('a sale receipt'), which distinguishes it from sibling tools like create_sale_receipt, update_sale_receipt, get_sale_receipt, and list_sale_receipts. It is not tautological and gives a reasonable sense of the operation's intent, though 'close' is not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as update_sale_receipt, or whether it is only appropriate for open receipts. The description gives no context about prerequisites, allowed states, or when closing should be invoked.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Create,' which implies a mutating operation, but it does not explain side effects, whether the bill starts open, validation behavior, or what a successful creation returns. The description adds minimal behavioral context beyond the operation name.
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 compact sentence with no filler, front-loading the action and resource. It is appropriately concise, though it is so terse that it may under-specify for a tool with 17 parameters, so it does not earn a perfect structure score.
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 17-parameter creation tool with no output schema and no annotations, this one-liner is incomplete. It omits prerequisites, how the created bill behaves, how required versus optional fields are determined, and what the caller should expect after creation. It provides only the most basic domain context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 12%, and the description names none of the 17 parameters. Required fields such as billDate, vendorId, and entries are left entirely to the schema, with no explanation of how they relate to creating a valid vendor bill. Given the low schema coverage, the description needed to compensate but does not.
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 a specific verb and resource: 'Create a vendor bill in Bigcapital.' It is distinguishable from sibling tools like update_bill, open_bill, and list_bills by the word 'Create,' and the phrase 'vendor bill' separates it from customer-facing creation tools like create_invoice. However, it does not explicitly differentiate itself from related creation tools or explain the vendor-bill concept, so it stops short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_bill, open_bill, list_bills, or create_invoice. It does not mention prerequisites like an existing vendor, when a bill should be created instead of an expense, or any conditions that would select this tool over its siblings.
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?
No annotations are present, so the description carries the full disclosure burden. It only discloses that an expense is created and that categories is typed as string[] in the SDK. It does not state whether the expense is created in draft or published state (critical given the publish parameter and the publish_expense sibling), what happens on validation failure, whether creation is idempotent, or any multi-currency exchange-rate 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?
Two sentences with no filler, and the purpose claim is front-loaded. The categories caveat is explicitly flagged as an 'Assumption' rather than asserted, which is the right framing for a typing uncertainty. The brevity reflects under-specification, but that is penalized under contextual completeness rather than here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial creation tool with 11 parameters (9 required), no annotations, no output schema, and a largely bare schema, the description leaves an agent unable to invoke it confidently. Key gaps: the publish parameter's effect, draft-vs-published workflow (especially given publish_expense exists as a sibling), how categories strings map to real category objects, and the required interplay between currencyCode and exchangeRate. The description explains the what but none of the how or when.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, covering just categories and paymentDate. The description's categories note largely repeats the schema text ('SDK currently types categories as string[]'), adding no new semantics, and the other nine parameters — publish, currencyCode, exchangeRate, payeeId, branchId, paymentAccountId, attachments, referenceNo, description — receive no added meaning. The publish boolean's effect is entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Create an expense in Bigcapital' — which clearly names the operation and the domain. The sibling set contains create_bill, create_invoice, create_payment_received, and create_manual_journal, and the resource name 'expense' partially distinguishes this tool from them. However, it does not clarify the accounting boundary between an 'expense' and a 'bill', so sibling differentiation is only surface-level.
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 when-to-use guidance or exclusions are provided. With siblings like create_bill, create_manual_journal, and create_payment_received representing distinct accounting workflows, an agent gets no criteria for choosing this tool over those. The second sentence is a type assumption about categories, not usage context.
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?
No annotations are provided, so the description must carry the full burden. 'List expenses' implies a read-only operation, but the description does not disclose whether filtering behavior, sorting, pagination, or view semantics are applied, nor what response shape to expect. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is concise. However, it is so minimal that it sacrifices substance; it is efficient but not appropriately informative for a tool with six parameters.
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 annotations, no output schema, six parameters, and a large set of sibling tools, the description is far too sparse. It does not explain listing behavior, filtering semantics, return structure, or how it differs from other list tools, leaving an agent without enough context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with sortBy and searchTerm documented but viewSlug, filterRoles, and customViewId left unexplained. The phrase 'Bigcapital list filters' is too generic and does not clarify the semantics of these parameters, so the description fails to compensate for the low schema coverage.
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 and resource: 'List expenses'. This distinguishes it from single-resource operations like get_expense, update_expense, and create_expense, and from list_invoices/list_bills. However, it does not differentiate itself further or explain what an expense listing entails, so it stops 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_expense for a single record or list_bills for a different resource. The description only says what it does, not when it should be chosen or when it should not be used.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It confirms a read/list operation and mentions Bigcapital filters, but it does not disclose pagination behavior, ordering defaults, response shape, or any side-effect or safety details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, so it is concise. However, it is under-specified for a six-parameter tool, and the brevity comes at the cost of needed usage and parameter guidance.
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?
The description leaves too much unstated: it does not explain how Bigcapital list filters map to the parameters, what output to expect, or when this tool should be chosen over get_manual_journal. For a tool with no output schema and no annotations, this is not enough contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 33%, four of six parameters (viewSlug, sortOrder, filterRoles, customViewId) remain undocumented in both the schema and the description. The phrase 'using Bigcapital list filters' is too generic to add meaningful semantic detail for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'manual journals', so an agent can tell this is a listing operation for manual journals. It is distinguishable from create/update/publish siblings by its verb, but it does not explicitly distinguish itself from get_manual_journal for single-record retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_manual_journal, and does not state any exclusions or conditions. The only usage hint is the generic phrase 'using Bigcapital list filters', which does not explain when list filters should be applied or when to prefer another endpoint.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Create a sale receipt.' It does not mention permissions, side effects, idempotency, downstream effects in Bigcapital, whether the operation is reversible, or what the response will contain. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action, but it is undersized relative to the tool's complexity. One sentence with no elaboration is economical, but it does not constitute an appropriately sized description for an opaque mutation operation with a nested body parameter and no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absent annotations, absent output schema, and opaque 'body' parameter that passes through to Bigcapital, the description is far too minimal to guide correct invocation. An agent has no way to know what fields a sale receipt requires, how it relates to customers or invoices, or what success looks like.
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 'body' parameter, which is described as a request body passed through to Bigcapital, so the schema already provides the baseline documentation. The tool description itself adds no parameter meaning, and the body allows arbitrary additional properties, but per the high-coverage baseline this warrants a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'Create', and a specific resource, 'a sale receipt', so it is not a bare tautology and is distinguishable from sibling tools like update_sale_receipt, close_sale_receipt, and get_sale_receipt. However, it adds no scope, context, or elaboration beyond the tool name, leaving some ambiguity about what a sale receipt entails.
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 about when to use this tool versus alternatives such as create_invoice, create_payment_received, or close_sale_receipt. The description does not state prerequisites, typical scenarios, or exclusions, so an agent must infer usage purely 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does (get a report) and does not disclose behavior such as default date ranges, filtering behavior, whether zero-balance accounts are included, or any required permissions. It is a read-only report operation, but that is not stated.
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 tool's purpose. It is appropriately brief, though it is arguably too short to carry necessary detail. No wasted words, but the brevity leaves gaps.
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 parameter-rich report tool (10 params) with no annotations and no output schema, the description is under-specified. It does not explain what the report contains, how parameters interact, what the default date range is, or what the returned data looks like. The sibling list shows related financial reports, but the description does not help an agent distinguish or correctly configure this one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description provides no parameter explanations. The schema has 10 parameters, mostly under-documented (e.g., noneZero, showZero, noneTransactions have no descriptions, and displayColumnsBy/displayColumnsType are unclear in meaning). The description adds nothing beyond the bare resource name to clarify parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the Bigcapital balance sheet report.' It clearly identifies the tool as retrieving a balance sheet report, which is distinct enough from the sibling financial report tools (get_profit_loss, get_trial_balance, etc.) by naming the exact report type. It does not explicitly contrast with siblings, but the resource name is specific and 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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention that it is for balance sheet reporting only, nor does it distinguish from similar financial report tools like get_trial_balance or get_general_ledger. Usage context must be inferred entirely 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only, non-mutating operation, but the description does not disclose pagination behavior, result limits, default sorting, how filters combine (AND/OR), or the response shape. For a list tool with zero annotation coverage, this is a significant gap.
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, front-loaded sentence with no wasted words; the verb-object structure is efficient. However, the brevity comes at the cost of omitting usage and parameter context that an agent would need, so it is concise but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, 33% schema coverage, no output schema, and no annotations, a one-sentence description is insufficient. The Bigcapital-specific concepts (viewSlug, customViewId, filterRoles) are unexplained, and the agent gets no description of the return value or filtering behavior, making it uncertain how to invoke the tool with the right filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (sortBy and searchTerm have descriptions), leaving viewSlug, filterRoles, customViewId, and sortOrder undocumented in the schema. The description adds no parameter-level meaning beyond the phrase 'Bigcapital list filters,' which merely labels the mechanism without explaining semantics. sortOrder's enum is self-explanatory, but the description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('chart-of-account records'), which inherently distinguishes it from sibling list_* tools covering other entities (customers, vendors, invoices) and from the singular get_account. However, the differentiation is implicit via the resource name rather than an explicit contrast, and the phrase 'Bigcapital list filters' is vague about what that entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The mention of 'Bigcapital list filters' weakly implies a filtering use case, but the description provides no exclusions, no contrast with get_account for single-record lookups, and no indication that this is the multi-record counterpart to that tool.
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?
With no annotations provided, the description carries the full burden of explaining behavior. It only says 'List ... using Bigcapital list filters' and says nothing about pagination, default sorting, whether an empty filter returns all items, permissions, or response shape. The read-only nature is weakly implied but not disclosed.
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 filler or repetition. However, it is so terse that it misses the opportunity to include key constraints, so it is efficient but not fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no output schema, and no annotations, this description is insufficiently complete. An agent cannot determine how filters combine, what a list response contains, or whether parameters like customViewId are required for certain views.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%; only sortBy and searchTerm have descriptions. The description adds no parameter-level meaning, and terms like filterRoles, customViewId, and viewSlug remain undocumented. The phrase 'Bigcapital list filters' provides only vague context and does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('List') and resource ('items'), which distinguishes it from sibling list_* tools like list_customers and list_vendors. It does not explicitly describe the scope of the list or clarify what 'items' means in Bigcapital, so it falls just 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.
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 such as get_item or update_item, nor any conditions under which one should use different filter parameters. The only usage hint is the generic phrase 'Bigcapital list filters'.
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?
With no annotations, the description carries the full burden of disclosing behavior. It only mentions that the tool uses 'Bigcapital list filters,' which hints at filtering support but does not explain pagination, default result size, whether all receipts are returned, or any other runtime behavior. A list operation that returns an unspecified set of records is not transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. There is no verbosity or wasted text, though the phrase 'Bigcapital list filters' is vague and could have been replaced with more useful detail without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six optional parameters, no output schema, and no annotations, the description leaves significant gaps. It does not specify how parameters combine, what the response shape looks like, or what the default behavior is when no arguments are provided. This is not enough context for an agent to confidently invoke the tool correctly in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description should compensate by explaining the less obvious parameters such as filterRoles, viewSlug, and customViewId. It does not. 'Bigcapital list filters' is too generic to add real meaning, and the only parameters with any clarity are already described in the schema (sortBy and searchTerm).
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 ('List') and a specific resource ('sale receipts'), and the qualifier 'using Bigcapital list filters' signals the tool's filtering behavior. It is clearly distinct from get_sale_receipt and from list_invoices/list_bills due to the explicit resource, but it does not explicitly differentiate itself from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as get_sale_receipt for a single receipt or list_invoices for other document types. There are no exclusions, prerequisites, or 'use X instead' hints. The intended usage is only implicitly derived from the name and description.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It implies a state-changing operation by using 'publish,' but it does not mention whether the action is reversible, whether the journal must be in a certain draft state first, or what consequences publishing has on downstream data.
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 directly states the action. There is no filler or redundancy, though the brevity leaves behavioral details unaddressed.
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 mutation tool with no annotations and no output schema, the description is too thin. An agent is not told what publishing entails, whether it can be undone, or what conditions must be true before calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, 'id', and the description adds no meaning to it. With 0% schema description coverage, the description should compensate by clarifying that the id identifies the manual journal to publish, but it does not.
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 ('Publish a manual journal') and is distinct from sibling tools such as create_manual_journal, update_manual_journal, and get_manual_journal. However, it does not clarify what 'publish' means in this accounting context, such as finalizing or posting the journal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like update_manual_journal or create_manual_journal. No preconditions, exclusions, or workflow context are provided.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. 'Update a bill' implies mutation but does not state whether the update is destructive, requires special permissions, replaces the entire bill, or has side effects on related records like bill payments. The agent is left without critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words and the core verb is front-loaded. However, it is so terse it borders on under-specification, though for sheer efficiency of expression it earns a high score.
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?
This is a mutation tool with no annotations, no output schema, and a nested object parameter that is undefined except as a passthrough. The description leaves unanswered crucial questions: what fields can be updated, what constraints apply to 'id', what the response looks like, and whether the update is partial or full replacement. The description is far from complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. The schema already documents the 'body' parameter as a passthrough to Bigcapital, but the 'id' parameter lacks description and the tool description does not clarify how the parameters relate to the update operation. With only 50% schema coverage, the description should compensate but does not.
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 ('Update') and resource ('a bill'), making the tool's core function evident. It distinguishes itself from sibling tools like create_bill, get_bill, and open_bill by the action it performs, though it lacks any explanation of what updating a bill entails.
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 offers no guidance on when to use this tool versus alternatives such as create_bill or open_bill. There is no mention of prerequisites, typical scenarios, or situations where other tools would be more appropriate. The usage context is entirely left to inference 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits itself. 'Create a bill payment' only conveys mutation; it says nothing about whether the bill's status changes, what side effects occur, required permissions, or error behavior. This is a significant gap for a write operation with zero 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, satisfying conciseness. It is under-specified, however, and mostly repeats the tool name, so it doesn't earn its place as a meaningful behavioral specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with an opaque body parameter, no output schema, and no annotations, the one-line description is insufficient. The agent cannot know what fields body requires, what valid values look like, or what a successful response contains.
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 documents the single body parameter as a request body passed through to Bigcapital, but it doesn't describe any fields or constraints. The tool description adds no parameter-level meaning beyond the name, though the baseline is 3 due to high schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Create') and resource ('bill payment'), making the basic operation obvious. However, it doesn't explain that bill payments settle vendor bills, leaving the distinction from sibling create_payment_received (customer payments) to be inferred from the tool name.
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 or when to choose a sibling such as create_payment_received, create_expense, or create_bill. The agent is left to infer context 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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Create an item' and does not mention side effects, required permissions, validation behavior, or what happens on success or failure. The mutation is implied but not contextualized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one short sentence, so it is maximally concise. However, it borders on under-specification: no context, no parameter guidance, and no mention of how the body should be structured. It reads as a label rather than a meaningful tool definition.
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 an open-body creation endpoint with no annotations and no output schema, the description is not complete enough. An agent cannot tell what fields an 'item' requires, what Bigcapital will accept, or what a successful creation returns. The single parameter's open additionalProperties makes this gap significant.
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% description coverage for the single 'body' parameter, stating it is the request body passed through to Bigcapital. The description adds no additional semantic value beyond the schema, so the 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?
States a specific verb and resource: 'Create an item.' It distinguishes from sibling tools like get_item, update_item, and list_items at a basic level. However, it lacks any detail about what an 'item' is in the Bigcapital context, so it does not fully 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 versus alternatives. The description does not mention any exclusions, prerequisites, or conditions that would route an agent to create_item instead of update_item or other create tools. Usage must be inferred solely from the name, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'List customers' and offers no information about pagination, result limits, default sorting, or whether any side effects occur. This is minimally transparent for a list 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 sentence with no filler and the main verb and resource are front-loaded. It is appropriately concise for a simple list tool, even though the filter phrase is somewhat generic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, this description is not complete enough for reliable invocation. It omits pagination behavior, filter semantics, default ordering, and return shape, leaving the agent dependent on parameter names and external Bigcapital knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes only sortBy and searchTerm, covering 2 of 6 parameters (~33%). The tool description does not explain viewSlug, sortOrder, filterRoles, or customViewId, and 'Bigcapital list filters' is too generic to add meaningful semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'customers', so an agent can identify the core action. It does not explicitly differentiate from get_customer or list_vendors, but the resource name makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 instead of related tools such as get_customer, create_customer, or list_vendors. The phrase 'using Bigcapital list filters' implies filtering is supported, but no conditions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'List vendors using Bigcapital list filters' and does not mention response shape, pagination, permissions, whether omitted filters return all vendors, or any other operational behavior. 'List' implies read-only, but that is not explicitly stated.
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 immediately front-loads the verb and resource: 'List vendors.' It contains no filler or redundancy, and it is appropriately sized for a straightforward list operation.
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 no annotations, no output schema, and a six-parameter input schema with only partial descriptions, a single generic sentence is far from complete. The agent cannot determine what filter values are valid, how multiple filters combine, or what the response will look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no parameter-level meaning beyond the generic phrase 'Bigcapital list filters.' Parameters like sortOrder, filterRoles, and customViewId remain undescribed in both the schema and the tool description, leaving the agent without enough context to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'List vendors' with the context of 'Bigcapital list filters.' This distinguishes it from read-one siblings like get_vendor and from other list tools like list_customers. It doesn't enumerate the filter capabilities, but the core 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 is given on when to use this tool versus alternatives such as get_vendor for a single vendor or list_customers for customers instead of vendors. The only implied usage is 'when you need to list vendors,' with no conditions, exclusions, or hints about when a different sibling would be more appropriate.
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?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the source file path and does not describe side effects, required permissions, overwrite behavior, file size limits, or return value. For a mutating upload operation this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to the basic action, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and two undocumented optional parameters, the description is too sparse. An agent cannot determine what the upload returns, where the attachment is sent, or how optional parameters like fileName and mimeType behave.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only filePath having a description. The tool description restates 'local file path' but adds no meaning for fileName or mimeType, and it does not clarify defaults, optionality, or how these parameters interact.
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 'upload' and the resource 'attachment', and specifies the source as a local file path. This distinguishes it from the sibling get_attachment_presigned_url, though it does not mention the target or destination of the upload.
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, nor any mention of prerequisites or related operations. An agent is left to infer usage from the tool name and sibling names.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that a customer is created, but does not mention that requests are passed through to Bigcapital, whether the operation is idempotent, what side effects occur, or whether special permissions are required.
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 and front-loaded, with no wasted words. It earns its place by clearly stating the core action, though it is sparse enough that some might see it as under-specified rather than elegantly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, plus the open-ended 'body' passthrough parameter, the description is not complete enough for an agent to understand how to construct a valid request or what the operation entails. Additional context about Bigcapital, required body fields, and typical usage would be necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single 'body' parameter as a pass-through object, giving 100% schema description coverage. The description adds no parameter-level meaning beyond this, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and target resource: 'Create a customer.' It is distinguishable from sibling tools like get_customer, update_customer, and list_customers, though it provides no additional context such as the underlying Bigcapital integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like update_customer or create_vendor. The implied usage is 'when you need a new customer,' but no explicit conditions, prerequisites, or exclusions are provided.
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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only states 'Create' and the resource; it does not mention permissions, idempotency, side effects, validation requirements, or what happens with the request body. The description is not misleading, but it is extremely thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is efficient, though it is so sparse that it borders on under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a create operation with an opaque nested body and no output schema, so the agent needs more context about required body fields, how payment received differs from similar entities, and what the effect or response is. The single sentence is materially incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter: the body is described as a request body passed through to Bigcapital. The tool description adds no additional field-level meaning, but with full coverage and only one parameter, 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 uses a specific verb ('Create') and names a clear resource ('payment received record'), so the agent understands the basic action. It does not, however, distinguish this tool from closely related creation tools such as create_sale_receipt or create_bill_payment.
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 this tool should be used instead of alternatives like create_sale_receipt or update_payment_received, and it gives no context about prerequisites or typical usage. This is effectively a no-guidance description.
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?
Without annotations, the description carries the burden of behavioral disclosure. 'List' clearly indicates a read operation and 'Bigcapital list filters' hints at a passthrough behavior. But it doesn't disclose pagination, result shape, or defaults, leaving significant behavioral ambiguity.
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 single sentence is front-loaded with the verb and object and contains no filler. It is concise, though it is also sparse given the number of parameters and missing guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, no annotations, and a close sibling list_due_bills, the one-line description is insufficient. It doesn't explain filter semantics, return data, or how it differs from similar listing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (sortBy and searchTerm have descriptions), and the tool description adds no parameter-specific meaning. The phrase 'Bigcapital list filters' is a generic umbrella rather than an explanation of filterRoles, viewSlug, customViewId, or sortOrder semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('vendor bills'), so the core function is clear. However, it doesn't differentiate this tool from the sibling list_due_bills or other listing tools, and 'Bigcapital list filters' is left undefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use list_bills versus list_due_bills, get_bill, or other list tools. The description merely restates the action implied by the name, with no exclusions, prerequisites, or alternative routing.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only implies a read-only listing operation and does not clarify whether 'due' means overdue, upcoming, or unpaid, nor does it mention ordering, pagination, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no filler, but it is under-specified. The three-word phrase is efficient yet omits the clarification needed to make it genuinely useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a domain-specific term like 'due bills', the description is incomplete. It does not explain the filter semantics or differentiate itself from list_bills, leaving an agent to guess about correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description has no parameter-semantics burden and the baseline 4 applies. The empty schema already fully documents the input, and no additional parameter meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a resource ('due bills'), so the basic action is clear. However, it does not distinguish 'due bills' from the sibling list_bills or explain what 'due' means.
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 list_bills or other bill-related tools. The description merely states the action without mentioning alternatives, prerequisites, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and 'List' clearly indicates a read operation without side effects. However, it does not disclose pagination, default scope, or the meaning of 'Bigcapital list filters', so some behavioral detail is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no redundant wording and the action is front-loaded. It is concise but perhaps too terse to fully support a six-parameter tool.
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 tool with six parameters, no annotations, and no output schema, a single generic sentence is not enough. It omits return value shape, pagination/filter behavior, and any explanation of Bigcapital-specific filter parameters, so the agent cannot reliably anticipate the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does not compensate: it merely says 'Bigcapital list filters' and leaves viewSlug, filterRoles, customViewId, and sortOrder largely undefined. Only sortBy and searchTerm have schema descriptions, so an agent has limited guidance for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('sale invoices'), which is enough to distinguish it from single-record retrieval tools like get_invoice and update_invoice. It is not as explicit as naming alternatives, but the verb+resource pairing is clearly non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus siblings such as list_bills, list_sale_receipts, or get_invoice. The description only states what the tool does, leaving the agent to infer selection criteria 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but 'List bill payments' only restates the action. It does not mention whether the operation is read-only, what fields or records are returned, pagination, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler, which is structurally efficient. It is minimally sized for a zero-parameter tool, though it lacks any additional contextual sections.
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 tool with no output schema and no annotations, the description should at least indicate what a bill payment is or what the list contains, but it does not. The minimal text leaves the agent without enough context to confidently distinguish this from similar list operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 applies because no parameter documentation is needed.
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 ('List') and resource ('bill payments'), clearly indicating a read operation for bill payments. However, it does not distinguish this from sibling tools like list_payments_received or list_bills, so it lacks explicit 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?
There is no guidance on when to use this tool versus alternatives. The description offers no context, exclusions, or references to siblings such as get_bill_payment or list_payments_received, 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?
No annotations are provided, and the description carries the full burden of behavioral disclosure. It only says 'Get a bill by ID' and does not mention return format, not-found behavior, permissions, or side effects, though the operation appears read-only.
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 five-word sentence with no filler or redundant content. It is front-loaded, immediately understandable, and appropriately sized for a one-parameter lookup operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple by-ID getter, the description is minimally sufficient to invoke the tool. However, with no annotations, no output schema, and no mention of error behavior or response shape, an agent still lacks some context about what to expect after the call.
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 required integer 'id' with zero description coverage. The phrase 'by ID' minimally compensates by indicating the parameter is the bill identifier, but it adds little beyond the schema's property name and provides no guidance on where the ID comes from or how to find it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get') and resource ('a bill') and identifies the retrieval method ('by ID'). It is clearly distinguished from list_bills and update_bills, though it does not explicitly differentiate from the sibling open_bill.
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 list_bills for browsing or open_bill for a different action, so an agent must infer usage entirely 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?
With no annotations, the description carries the burden of indicating the operation type. 'Get' clearly signals a non-destructive read operation. However, it does not disclose any other behavioral traits such as not-found behavior, authorization needs, or response shape, which leaves a modest gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: it states the action, the resource, and the access key in one short sentence. Every word contributes meaning, and there is no redundant or filler content.
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 single-record GET operation with one required parameter, the description is minimally sufficient. However, because there is no output schema and no annotations, an agent gets no explicit information about the return value, error cases, or how this tool relates to list_bill_payments, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required 'id' parameter with 0% schema description coverage. The description only says 'by ID', which adds little beyond what the schema already makes obvious. It does not clarify what kind of ID this is, where it comes from, or how it maps to a bill payment.
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 ('Get') and resource ('bill payment') and the retrieval method ('by ID'). It is identifiable as a single-record fetch, but it does not explicitly distinguish itself from sibling tools like list_bill_payments or get_bill, so it stops short of a full 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?
The description implies this tool is for retrieving a specific bill payment when an ID is known, but it gives no explicit guidance about when to use this versus list_bill_payments, create_bill_payment, or update_bill_payment. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The verb 'Get' implies a read-only operation, but the description says nothing about side effects, not-found behavior, permissions, or return format, leaving the agent with only the tool name as a clue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. For a simple get-by-ID operation, this level of conciseness is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and no output schema, so the description is almost usable on its own. However, it never defines what an 'item' is in this accounting domain, and the lack of an output schema leaves the agent without any expectation of the response shape.
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 0% description coverage, but the single parameter is named 'id' with an integer type and exclusiveMinimum 0, which is largely self-explanatory. The description reinforces that the ID identifies the item, though it adds no additional format or domain detail.
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 ('Get'), a resource ('item'), and a lookup key ('by ID'), which makes the tool's core action clear. It distinguishes this from sibling write and list tools like create_item and list_items, though it does not elaborate on what an 'item' is in this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like list_items, create_item, or update_item. The phrase 'by ID' implies a single-record lookup, but the description never states the condition, exclusions, or recommended alternative.
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?
With no annotations, the description carries the full behavioral disclosure burden. 'Get' implies read-only retrieval, but the description does not mention return shape, not-found/error behavior, permissions, or idempotence, and it adds nothing beyond the tool 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?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core meaning, making it optimally concise for the small amount of information it provides.
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-by-ID tool with one parameter, the description and schema are sufficient to attempt invocation. However, with no output schema and no mention of error behavior or how IDs should be obtained from list_sale_receipts, it remains minimally viable rather than 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?
The schema has one required integer id with zero property descriptions. The phrase 'by ID' confirms id identifies the sale receipt, which is the key semantic needed, but it offers no extra guidance on how to discover valid IDs or interpret the response.
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 'et' and resource 'sale receipt', with 'y ID' indicating singular retrieval. It is clearly distinguishhed from list/create/update/close sale receipt siblings, but it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 instead of list_sale_receipts or how to obtain a valid sale receipt ID. The only context comes from the tool name and sibling list, so the description itself provides no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only indicates a read-style operation; it does not mention response behavior, error cases, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. It is front-loaded with the action and resource, making it easy to scan.
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 one-parameter getter, this description is minimally viable: it identifies the operation and the required identifier. However, it leaves return value expectations, error behavior, and alternative tool routing to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds almost nothing beyond the property name 'id'. The phrase 'by ID' weakly reinforces that the parameter identifies the account, but it does not compensate for the missing schema-level parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('account'), and the lookup mechanism ('by ID'). It is immediately distinguishable from list_accounts and other get_* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies the tool should be used when the agent has an account identifier and needs a single account. However, it provides no explicit guidance about when not to use it or which sibling alternative to prefer.
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?
With no annotations, the description carries full behavioral disclosure burden. It does not mention that a presigned URL may expire, expose a file without further authentication, or require specific permissions. It only states the action without explaining behavioral implications.
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 with no redundant wording. It front-loads the action and resource, making it immediately scannable.
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 there is no output schema, the agent cannot know whether the response is a raw URL string or a JSON object containing the URL. The description also omits any note about the attachment needing to exist. These are notable gaps, though the tool is simple enough to remain minimally usable.
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 only provides a generic 'id' string with 0% description coverage. The description adds meaning by clarifying that the parameter is an attachment ID, which materially improves an agent's ability to populate the argument correctly.
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 ('Get'), a distinct resource ('presigned URL for an attachment'), and the key input ('by attachment ID'). It distinguishes itself from all sibling tools because none mention presigned URLs, removing ambiguity about what this 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 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 upload_attachment or other get_* tools. The description does not mention prerequisites, typical use cases, or why this tool should be selected over others.
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?
With no annotations provided, the description carries the full behavioral burden. It clearly indicates a read-only retrieval operation via 'Get', with no hint of side effects or destructive behavior. It does not mention error cases, authentication, or response shape, but for a simple getter that is a moderate rather than severe gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It communicates the operation, the resource, and the lookup key efficiently.
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 one-parameter schema and no nested objects, the description plus schema is nearly enough for an agent to invoke the tool correctly. However, with no output schema, the description does not clarify what is returned or how errors like a missing ID are handled, leaving some contextual gaps.
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 only an integer 'id' with no description, and schema coverage is 0%. The description's 'by ID' gives the sole parameter meaningful semantics by tying it to the payment-received entity, which is minimal but sufficient for a single required parameter.
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 ('Get') and resource ('a payment received') with a clear lookup qualifier ('by ID'). It is immediately understandable, though it does not explicitly differentiate itself from sibling tools beyond the standard get-by-ID pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies this tool is for retrieving a single, known payment received, which suggests when it should be used versus list_payments_received. However, it gives no explicit guidance about when not to use it, prerequisites, or how it relates to create/update payment 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?
No annotations are provided, so the description carries the burden. It discloses the lookup-by-ID behavior but nothing else: no mention of authorization, null/not-found behavior, whether related objects are included, or response format. For a simple read operation this is minimal viable disclosure, but lacks depth.
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, no filler, and the key lookup criterion is front-loaded. It is appropriately sized for a simple retrieval, though it could add a sentence about return behavior or related tools without becoming verbose.
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's simplicity (one required parameter, no output schema, no nested objects), the description covers the core call pattern. It is incomplete in a contextual sense because it provides no explicit guidance on when to prefer list_vendors or how to handle non-existent IDs, and with no annotations there is no safety/read-only hint. Still, the simplicity of the tool keeps it at a 3.
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 documents the single required id parameter with type and exclusiveMinimum, and only requires an 'id' value. Since there is only one param and the description explicitly says 'by ID', meaning is clear. With 0% schema description coverage but a single obvious integer parameter, the description sufficiently reinforces the parameter's purpose, so a 4 is appropriate rather than the low-coverage penalty.
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 'Get a vendor by ID' clearly states the operation (get) and the resource (vendor), with a specific lookup criterion (by ID). It distinguishes itself adequately from list_vendors, but does not explicitly mention which siblings to compare against, so it misses a point for not explicitly differentiating from other vendor-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need a single vendor by ID. No explicit exclusions or alternative routing are provided, and there are sibling tools like list_vendors that could be confused. The guidance is minimal but the purpose is straightforward, so it earns a 3.
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?
No annotations are present, so the description carries the full burden of behavioral disclosure. The verb 'List' conveys a read-only action that returns a collection, but ordering, pagination, scope, and limitations are not mentioned. This is adequate for a simple parameterless listing but lacks explicit behavioral detail.
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 action and resource are front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity—zero parameters and no output schema—the phrase 'List payments received' supplies the essential invocation information. It could be more complete by stating the return shape or naming sibling distinctions, but nothing about calling the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description correctly implies no arguments are needed and does not mislead about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'List' and the resource 'payments received,' making the core operation clear. It differentiates from get_payment_received by list-vs-get and from list_bill_payments by resource, though it does not explicitly call out those distinctions.
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 offers no guidance about when to use this tool versus get_payment_received or list_bill_payments. An agent must infer the intended use solely from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It only states that the tool 'gets' a manual journal, without mentioning return shape, error behavior, read-only guarantees, or any side effects. This is minimal transparency for a tool that is not backed 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, front-loading the verb and the lookup key. Every word contributes to conveying the tool's function.
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 that this is a simple single-parameter read-only lookup, the description conveys the essential information: retrieve the manual journal that matches the supplied ID. It lacks an output schema and annotations, but for sucha straightforward getter, the description is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, 'id', with no description coverage, but the description's 'by ID' does link that parameter to the intended resource. It does not explain the meaning of the identifier beyond that or why the numeric constraint (exclusiveMinimum: 0) exists, so compensation for the schema's lack of descriptions is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('manual journal'), and identifies the lookup key ('by ID'), making the tool's function unambiguous. It is also clearly distinct from siblings like list_manual_journals, create_manual_journal, and publish_manual_journal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies the appropriate condition for use: you have a manual journal identifier and need a single record. However, it does not explicitly say when to prefer this tool over alternatives such as list_manual_journals, and it gives no exclusions or adjacent usage guidance. The guidance is present but implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of indicating behavior. It clearly signals a read operation that fetches a single customer. However, it does not disclose what happens when the ID is not found, what response format to expect, or any permission requirements.
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 wasted words. Every part of it directly contributes to understanding the tool's core function.
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 read operation, the description is largely sufficient. It covers the main purpose and the key input. Given the lack of an output schema, a bit more detail about the expected return value or error behavior would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description itself must add parameter meaning. It only restates that the tool operates 'by ID,' which adds little beyond the schema's already-named 'id' property and its integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation ('Get') on a specific resource ('a customer') using a particular selection mechanism ('by ID'). It is immediately distinguishable from list_customers and other customer-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies this tool is appropriate when a specific customer identifier is already known, which is a useful contextual signal. However, there is no explicit guidance on when to prefer this over list_customers or other 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?
With no annotations present, the description carries the burden of behavioral disclosure. 'Get' signals a read-only lookup, which is a useful behavioral trait, and 'by ID' indicates direct retrieval. However, it does not disclose behavior for missing IDs, errors, authorization requirements, or what response shape to expect.
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 entire description is a single, front-loaded sentence with no redundant words. It communicates the operation and parameter in six words, so every component 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 one-parameter getter with no output schema, the description provides enough information to know when and how to invoke the tool. It omits potential return/error details, but given the low complexity and obvious semantics, the missing details are not critical. It is complete enough for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, id, but the description names its semantic role by saying 'by ID,' connecting the parameter to the expense resource. It does not add detail about the integer format or exclusivity, which are already in the schema; this is adequate for a single obvious parameter despite the measured 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the exact resource ('an expense') and selection criterion ('by ID'), so the tool's function is immediately clear. It does not explicitly differentiate itself from sibling tools such as get_vendor or update_expense, although the resource and verb make the distinction largely obvious.
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 phrasing implies this tool should be used when the agent has an expense ID and wants a single expense record. There is no explicit statement of when not to use it or which alternative to prefer, so the guidance remains implicit rather than prescriptive.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The word 'Get' conveys a read-only lookup, but the description does not mention not-found behavior, authorization needs, or that no records are modified. This is adequate for a simple getter but leaves clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 states the operation, the resource, and the selection method in the most efficient way possible.
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 tool with one required parameter and no annotations, this description is enough to make a correct call when the ID is known. However, without an output schema, it would benefit from stating that the response is the full invoice object and what happens if the ID does not exist, so completeness is only partial.
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 0%, and the only parameter is id. 'By ID' adds the key semantic that the integer id identifies which invoice to retrieve, but it adds almost nothing beyond what the schema's property name already implies. For a single obvious parameter, this is acceptable but not rich.
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 ('Get') and names the exact resource ('a sale invoice') selected by ID. This clearly distinguishes it from get_bill, get_expense, and list_invoices, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' clearly implies the intended usage: call this tool when you need a single sale invoice and you already have its identifier. However, it does not explicitly name alternatives like list_invoices for when the ID is unknown, so it stops short of full exclusion guidance.
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:

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

Score Badge

Copy to your README.md:

[![mcp-bigcapital MCP server](https://glama.ai/mcp/servers/Reomar/mcp-bigcapital/badges/score.svg)](https://glama.ai/mcp/servers/Reomar/mcp-bigcapital)

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/Reomar/mcp-bigcapital'

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