imprest-account

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

Annotations already establish readOnly=false, so the non-read-only nature needs no credit. The description adds useful context: it returns the float id, defines imprest as the replenishment target, and notes the free-tier limit of one float. It does not discuss the side effect that calling twice opens two floats despite idempotentHint=false.

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 with no filler. The core action, return value, key concept, and constraint are all included efficiently, and the most important information 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?

For a simple creation-style tool with 6 parameters whose schema covers most of them, the description is largely complete: it states the output (id), a key business rule (free tier: one float), and clarifies the imprest concept. It would be slightly stronger with an explicit note about not using it for existing floats or replenishments, but that gap is mostly captured by the usage dimension.

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

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

Schema coverage is 83%, so the baseline is 3. The description adds genuine semantic value by explaining imprest_minor as the amount the tin is 'topped back up to at every replenishment,' which goes beyond the schema's 'float amount in whole minor units'. Other parameters rely on the schema's adequate descriptions.

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

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

The description states a specific verb ('Open') and resource ('petty cash float on the imprest system') and tells the caller it returns the float id. It is clear and unambiguous, though it does not explicitly contrast itself with lifecycle siblings like replenish_request or reconcile.

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?

There is no explicit guidance on when to use this tool versus alternatives. The phrase 'topped back up to at every replenishment' hints that opening precedes replenishment, but the description never states 'use this for a new float, not for top-ups or reconciliations' or similar.

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 this as a safe, read-only, idempotent operation. The description adds useful behavioral context beyond annotations by specifying exactly what the report contains, which matters because there is no output schema to convey return structure.

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

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

The main content is a single compact sentence with the reporting action and report contents front-loaded. The trailing 'Pro.' fragment adds no information and slightly undermines polish, so it is not a perfect 5, but overall the description is appropriately sized and waste is minimal.

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 the lack of an output schema, the description does a reasonable job of listing the report's major sections and the optional-selector semantics are already covered by the schema. It could go further by describing the result shape or how multiple floats are aggregated, but the core information needed to invoke it is present.

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

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

Schema coverage is 100%, with both parameters clearly documented in the schema. The description does not add meaning beyond the schema, so the baseline of 3 applies. It does somewhat align 'unreconciled vouchers' with the limit parameter, but adds no new parameter-specific details.

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

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

The description names a specific verb and resource ('Report each float') and enumerates concrete report contents: balance against imprest, restoration amount, unreconciled vouchers with their total, last count, and count history. This clearly differentiates it from siblings like float_open, reconcile, and replenish_request, which perform different actions.

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?

The description implies use when a float state report is needed, and the tool name/title reinforce this, but it does not explicitly state when to prefer it over alternatives or when not to use it. No exclusions are given, so usage guidance is only implied rather than 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 indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the operation.

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

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

The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential information.

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 activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent 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?

The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in the schema.

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

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

The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.

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?

The description provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.

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, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing the read-only nature of the 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 dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information 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?

With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.

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

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

There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.

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

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

The description begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.

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?

The description explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.

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

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

Annotations already establish readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds meaningful behavioral context by disclosing that the call marks the count as reconciled (a non-read-only side effect) and by listing the returned data. It does not contradict the annotations.

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

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

The main sentence is a long run-on that packs inputs, outputs, and side effects together; it is readable but not optimally structured. The standalone 'Free.' adds an extra sentence whose relevance to invoking the tool is unclear and does not earn 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?

Despite having no output schema, the description tells the agent what the tool returns (expected balance, difference, vouchers) and what side effect it has. Combined with the complete input schema and annotations, this is sufficient for correct invocation, though it omits error/edge-case behavior such as what happens with no previous count.

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?

All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description restates counted_minor and date in prose but adds no new semantic information about them, and it says nothing about the optional float parameter beyond what the schema already says.

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

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

The description states a specific action—counting the tin and reconciling—with required inputs (counted cash in minor units, date) and concrete outputs (expected balance, difference, vouchers since last count). It also names the side effect (marks reconciled), which clearly differentiates it from siblings like float_report and voucher_add.

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?

The description implies a use case ('give the cash counted... and the date') and the schema notes when to omit the float parameter, but it never tells the agent when to prefer this tool over siblings such as float_report or replenish_request, nor does it state any exclusions or prerequisites.

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?

The description explicitly claims 'Writes nothing,' which contradicts the readOnlyHint=false annotation. No other behavioral context (auth, side effects, failure modes) is supplied, so the description misleads rather than clarifies the tool's behavior.

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

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

The main sentence is compact and packs the essential output list into one line. The trailing 'Pro.' is unexplained noise and 'Work out what puts the float back to its imprest' is slightly indirect, but the overall definition is small and readable.

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 only two optional, fully documented parameters, the description gives the core computation and states safety ('Writes nothing'). However, it lacks an output schema and does not describe the actual return shape or error behavior, and the 'Pro.' flag adds ambiguity.

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%: both date and float already have descriptive meanings in the schema. The description adds nothing about how date or float affect the computation, so it meets but does not exceed 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?

The description identifies the operation as computing a replenishment: 'the amount, the vouchers it reimburses, the totals per category as an expense_add-ready payload, and the double entry.' This goes beyond the title by naming concrete outputs, though it does not explicitly distinguish the tool from siblings such as topup_record or reconcile.

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?

The description gives no when-to-use guidance, exclusions, or alternatives. 'Writes nothing' hints at preview-only use, but the tool never says to use this before topup_record or instead of reconcile, so an agent must infer the intended workflow.

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?

With no useful annotation hints (all false), the description carries the burden of disclosure, and it does disclose a major behavioral trait: recording cash also reimburses every voucher up to the given date. It also states the return value (new balance). It could add more on permissions, reversibility, or status changes to vouchers, but the main side effect is not hidden.

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

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

The description is compact: one sentence for the core action and one for the side effect. Both sentences add information, though 'tin' and 'imprest' are informal/domain jargon, and 'as a replenishment does' is slightly roundabout.

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 four-parameter tool with no output schema, the description tells the agent what the tool returns (new balance) and warns about the consequential voucher reimbursement. The optional float behavior is left to the schema, and there is no discussion of duplicate calls or failure cases, but the core call-and-response context is present.

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 schema already documents amount_minor, date, source, and float. The description restates 'whole MINOR units' and 'date and source' but adds no meaning beyond the schema, apart from reinforcing the minor-units constraint.

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

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

The description clearly identifies the operation as recording cash added to the float and returning the new balance, and it calls out the non-obvious side effect that existing vouchers get reimbursed. It is therefore more specific than a tautology and likely distinguishable from viewing/reporting tools, but it does not explicitly contrast topup_record with the closely related replenish_request sibling.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The phrase 'as a replenishment does' is explanatory rather than a routing rule, so an agent must infer from the name or title when this tool is preferred over replenish_request.

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?

It adds behavioral context beyond the annotations: the call returns a voucher number, is refused when the float is exceeded, rejects byte-identical duplicates, and mentions the free-tier quota. The only weakness is that the duplicate refusal is stated absolutely even though the schema's duplicate_ok parameter can override it.

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

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

The description is two tight sentences with no filler. The core action, return value, failure conditions, and quota are each given one crisp clause, and all information 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?

The schema covers parameter semantics, and the description covers the return value, refusal conditions, and rate limit. The only gap is the missing duplicate_ok caveat in the duplicate-refusal statement; otherwise an agent would have what it needs to invoke the tool correctly.

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

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

All eight parameters are already documented in the input schema with 100% coverage, so the description does not need to repeat them. It adds no parameter-level nuance beyond the 'tin' metaphor, making the schema the primary source of parameter meaning.

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

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

The description states a precise verb and resource: 'Record one voucher paid out of the tin' and even names the returned identifier format, VOU-YYYY-NNNN. This clearly separates it from the float, license, reconcile, and voucher_delete 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?

The recording use case is implied by the title and verb, and the description gives explicit refusal conditions such as exceeding the float and duplicate vouchers. However, it does not name any sibling tool or explain when to prefer voucher_add over alternatives like topup_record or voucher_delete.

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 mark destructiveHint=true, and the description adds meaningful context beyond that: reconciliation-covered vouchers are refused and the refusal names the count that would be falsified. This helps the agent anticipate rejection behavior without contradicting 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?

The description is compact and front-loaded: the main action comes first, followed by an important restriction and remedy. The trailing 'Free.' is slightly ambiguous but does not undermine clarity; overall the text is efficient and well-ordered.

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, destructive tool with no output schema, the description covers the core purpose, usage conditions, refusal behavior, and an alternative action. It does not describe return values, but given the annotations and simple schema, nothing essential 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?

The single parameter 'voucher' is fully documented in the schema with type, maxLength, and an example ('VOU-2026-0003'). The description's phrase 'by its VOU number' reinforces the parameter but does not add substantial meaning beyond the schema.

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

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

The description opens with a specific action and resource: 'Delete a voucher ... by its VOU number,' and adds the intended use case 'entered wrongly.' This clearly distinguishes it from sibling tools like voucher_add and indicates its role in correcting entry mistakes.

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

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

It explicitly states when to use the tool (wrongly entered vouchers), when not to use it (vouchers already covered by reconciliation), and what to do instead (record a correcting voucher). This provides clear routing guidance with no reliance on inference.

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