InvoiceVista Invoice Maker

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safe read profile (readOnly, idempotent, non-destructive), so the lower bar applies; the description still adds the 'or not-found' outcome, which the annotations do not convey. It does not mention auth or rate-limit behavior, so it stops short of 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the usage condition and return fields come first, and the exclusion is appended as a short guardrail. No filler or restated name/title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with annotations covering the safety profile and an output schema present, nothing needed to invoke it correctly is missing. Field enumeration is mildly redundant with the output schema but reinforces the invocation trigger.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

One parameter with 100% schema description coverage, including the 24-hex-char pattern, so the schema carries the full semantics. The description adds no extra meaning about businessId, which is the expected baseline when coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('one business's invoicing setup') and enumerates the fields involved (currency, country, language, timezone), which cleanly separates it from the revenue/receivables siblings. The explicit 'Not for revenue or unpaid invoices' sharpens the boundary further.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('when someone asks about one business's invoicing setup') and names the exclusions, implicitly routing the agent to get_revenue_summary and get_receivables_summary instead. Both when-to-use and when-not-to-use are present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful behavior beyond that: the 90-day default window, the 366-day cap, draft-skipping, and a 500-quote counting limit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the usage trigger followed by the returned fields and constraints. No filler or repetition; every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't enumerate return values, and the annotations cover safety semantics. It supplies default window, caps, and draft exclusion, leaving only minor gaps such as permissions or rejection-handling nuances.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (businessId, startDate, endDate) are already documented in the schema, including the date defaults and window cap. The description largely restates these; the extra 500-quote cap applies to results rather than a parameter, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (summarize) and resource (quotes/estimates), plus the exact outputs: quote count, total value, counts by status, and acceptance rate. This clearly distinguishes it from sibling tools like get_receivables_summary and get_revenue_summary, which cover different domains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with a concrete user-intent trigger ("when someone asks how many quotes or estimates they sent, what they were worth, or how many were accepted or rejected") and adds an exclusion ("Not for a single quote"). It does not name a specific alternative tool for single-quote retrieval, but no such sibling exists in the list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the 500-newest-invoice cap and the quirk that partially paid invoices are counted but excluded from amounts. It doesn't mention auth or rate limits, but those are not implied by the annotations either.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all load-bearing: usage trigger, return shape with caveats, and exclusion. The most decision-relevant information (what it's for) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations cover the safety profile, an output schema exists so return structure need not be re-explained, and the description still supplies the non-obvious limits (500-invoice scope, partial-payment handling) and boundary against adjacent tools. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (businessId) and schema description coverage is 100%, with the schema documenting the 24-hex-character pattern. The description adds no additional meaning about the parameter, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (receivables) with concrete outcomes: open invoice count/amount, overdue invoices, and age buckets by days past due. An agent can distinguish this from get_revenue_summary or get_quote_pipeline_summary without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit triggering conditions ('when someone asks how much customers owe, what is unpaid or overdue') and an explicit exclusion ('Not for chasing or charging a customer'). Both the when and the when-not are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: a default 90-day window, a hard 366-day ceiling, that drafts are skipped, and that at most 500 documents are counted. These are exactly the silent constraints that would otherwise cause a wrong call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the trigger phrase and followed by the return payload and the scoping limit. No filler, and the exclusion is placed last as a natural boundary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value detail is optional, yet the description briefly signals the shape (counts, totals, status breakdown, collection rate). Combined with the default window, caps, draft exclusion, and scope boundary, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents businessId, startDate, and endDate formats and defaults. The description nonetheless reinforces the window semantics (default 90 days, cap 366) and adds a non-parameter constraint (500-document counting cap), slightly exceeding the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('how much they invoiced or were paid in a period') and enumerates the returned artifacts: invoice and payment counts and totals in business currency, invoices by status, and a collection rate. The closing exclusion ('Not for a single invoice or customer') further sharpens its scope against narrower siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('Use this when someone asks how much they invoiced or were paid in a period, like last month') and an explicit when-not ('Not for a single invoice or customer'). It stops short of naming which sibling to use instead for per-customer or receivables questions, so routing between get_receivables_summary and this tool is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: it returns the active OR past-due plan, and falls back to Free plan defaults when no plan exists — a non-obvious edge case an agent would otherwise have to discover at runtime.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero filler: usage trigger first, return contract and boundary second. Every clause earns its place, and nothing is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape detail is already structured; the description still summarizes the useful cases (active, past-due, no-plan fallback). With a single well-documented parameter and full annotation coverage, nothing needed to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter, and schema coverage is 100% — the schema documents businessId including its 24-hex-character pattern. The description adds nothing about the parameter, so the baseline 3 applies when structured data does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (retrieve the InvoiceVista subscription plan for a business) and enumerates exactly what it yields: plan name, status, billing frequency and limits. The closing sentence distinguishes it from sibling reporting tools by ruling out customer invoices and payments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit trigger ('Use this when someone asks which plan a business is on, or how many customers, invoices or users it allows') and adds an explicit exclusion ('Not for customer invoices or payments'). Both when-to-use and when-not-to-use are present, so no inference is required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: the default page size, what is deliberately omitted (addresses, bank details), and the field set returned. It stops short of explaining pagination via cursor, but that is largely in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the trigger condition, then the payload shape, then the exclusion. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a two-parameter, zero-required listing tool. An output schema exists, yet the description helpfully summarizes the returned fields and pagination default, and the omission of addresses/bank details preempts wrong expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both limit and cursor are fully documented in the schema, which sets the baseline at 3. The description's mention of '25 per page by default' corroborates the limit parameter but adds no cursor semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list businesses) plus the exact fields returned (id, name, currency, country, language, timezone) and the page size. It explicitly distinguishes itself from the sibling case by noting 'Not for listing customers'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering conditions ('when someone asks which businesses they invoice from, or a business's id is needed') and an explicit exclusion ('Not for listing customers'). An agent can route to or away from this tool without inspecting siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new behavior: result ordering (most recently edited first) and default page size (25 per page), which the agent cannot infer from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no filler: the trigger comes first, then return/ordering/pagination facts, then the exclusion. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not enumerate return values, and it still adds ordering and paging context. Cursor mechanics are left to the schema, which documents them fully, so the definition is essentially complete for this read-only listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every parameter already carries format and range documentation; the description only restates limit's default of 25. Baseline 3 is appropriate when the schema does the parameter work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list catalog products/services with prices) and explicitly scopes what it is not (what a customer was invoiced), which cleanly separates it from the invoice/receivables-oriented siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit trigger condition ('when someone asks what products or services a business sells or what it charges') and adds a negative boundary ('Not for what a customer was invoiced'), so the agent knows both when and when not to reach for it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful scope context: the interactive sidebar nature, the 100-business cap, and the explicit exclusion of customer or individual financial records, which tells the agent what this tool will not surface. Minor gap: no mention of how the interactive session terminates or refreshes, but that is marginal. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the primary trigger ('when someone wants to open InvoiceVista'), followed by scope and exclusions. Every phrase earns its place; no filler or repetition of annotation data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description rightly avoids explaining return values and instead focuses on trigger, scope cap, and exclusions. Combined with annotations that cover safety and idempotency, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so schema coverage is effectively complete and there is nothing to document. The baseline for 0 params is 4, and the description appropriately does not invent or confuse any parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('open InvoiceVista') and enumerates exactly what surfaces appear (businesses, billing overview, revenue, receivables, quote pipeline). It also distinguishes from siblings by clarifying it returns up to 100 businesses rather than the focused summaries that get_receivables_summary or get_quote_pipeline_summary provide.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it ('when someone wants to open InvoiceVista and browse') and when not to ('Not for creating invoices or recording payments'). This gives a clear routing decision against the sibling read-only summary tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral detail beyond them: per-status counts are capped at 100 and only up to 12 catalog products are returned, and it explicitly excludes customer/invoice details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences that front-load the use case and then the payload shape; every clause carries information. 'quick overview or dashboard' is mildly redundant but overall there is little waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with full annotations and an output schema, nothing needed to invoke it correctly is missing. The description goes beyond the minimum by describing caps, product limits, and excluded data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single businessId parameter is fully documented (24 lowercase hex chars), so the schema does the work. The description adds no syntax or format detail for the parameter, which is the expected baseline when the schema is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (shows a business overview card) and enumerates the exact payload: business details, counts of customers/invoices/payments/quotes with status mixes, and up to 12 catalog products. It also carves itself away from a sibling with 'Not for revenue over a period', so an agent can distinguish it from get_revenue_summary without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear use condition ('when someone wants a quick overview or dashboard of one business') and an explicit exclusion ('Not for revenue over a period'). It stops short of naming the alternative sibling tool by name, leaving the agent to infer get_revenue_summary from the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.