Qashier MCP by usefulapi

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

Annotations only carry destructiveHint=true; the description adds real context the agent can't see elsewhere: this is a WRITE, it defers any charge until the customer pays, and it returns a payment url. It stops short of noting the idempotency/retry behavior, which stays buried 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 short sentences, front-loaded with the "WRITE:" marker and ending on the HTTP endpoint. Nothing is redundant or padded.

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

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

For a 7-parameter write tool with no output schema, the description covers the mutation nature, the deferred charge, and the return value, with units clarified. Minor gaps remain around retry/idempotency semantics, though those are documented per-parameter in the schema.

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 explains all seven parameters. The description reinforces the unit_amount convention with a concrete conversion example (SGD 12.50 = 1250), but adds no meaning beyond that 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 (create), resource (payment Checkout Session), and scope limit (ONE item), plus the return value (payment url). The create verb separates it cleanly from the get/list/expire/refund siblings without needing to name them.

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

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

Implies usage through "It charges nothing until the customer pays at that url," which tells an agent this is the pre-payment step, but it never states when to choose this over siblings (e.g. multi-item flows, refunds) or any preconditions.

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 only give a title and destructiveHint=true, so the description adds real value: it labels the operation WRITE, describes the precondition and the fact the session becomes unpayable. It could go further on irreversibility (whether an expired session can be reopened) and response shape, but the core behavior is disclosed.

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

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

Two compact sentences plus the endpoint, with the WRITE prefix and the key precondition front-loaded. 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?

For a two-parameter mutation with no output schema, the description covers purpose, precondition, and failure mode. A note on what happens to the customer after expiry (e.g., whether the session can be recreated) would make it fully complete.

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 session_id and idempotency_key fully documented in the schema, so the description carries no additional parameter burden. The description adds no syntax or format detail beyond what the schema already provides — baseline 3.

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 the exact verb and resource ('expire an OPEN Checkout Session'), the precondition (must be open), and the effect on the customer, plus the underlying endpoint. It is clearly distinguishable from qashier_get_checkout_session and qashier_create_checkout_session.

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 scopes usage to sessions that are OPEN and states the failure condition when the session is not open, which is a clear usage context. It does not name alternatives (e.g., cancel vs refund) or exclusions, so it falls short of a 5.

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?

readOnlyHint=true already declares the operation safe and non-mutating, so the description is not obligated to cover that. It does add useful behavioral context by enumerating the returned payload (including refunds), which matters because no output schema exists; it stops short of describing not-found or expired-session 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?

A single sentence that front-loads the verb and resource, then lists the returned fields, with the HTTP endpoint tacked on as compact supplementary context. Nothing is redundant.

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 one-param read tool with no output schema, enumerating the return fields is the key missing piece and it is present. The remaining gap is error/absence semantics (not found, expired), which is minor here given readOnlyHint and the trivially simple schema.

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?

With one parameter at 100% schema coverage, the schema already defines session_id with a minLength constraint. The description's 'by id' and the '/checkout/sessions/{id}' path reinforce where the id goes but add no format or sourcing detail 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 ('Get one Checkout Session by id') and enumerates the fields it surfaces (status, payment status, payment method, amount, checkout url, refunds). The singular 'one ... by id' framing clearly separates it from qashier_list_checkout_sessions without needing to name the sibling.

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

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

Usage is only implied: an agent infers it should call this when it already holds a session_id. There is no explicit guidance on when to prefer list_checkout_sessions or expire_checkout_session, nor any note about what to do if the session is missing or expired.

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 readOnlyHint=true already declaring the safety profile, the description adds real context: newest-first ordering, the exact attributes returned (status, payment status, amount in cents, refunds, receipt number), and the cursor mechanics. It omits rate limiting or page-size defaults, but the value beyond the annotation is genuine.

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, zero filler, with the resource and ordering front-loaded followed by the pagination recipe and endpoint. Every clause carries information the 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?

For a read-only list tool with no output schema, the description enumerates the returned fields and explains pagination, which is enough to call it correctly. Authentication or rate-limit behavior is not covered, but nothing critical is missing.

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

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

Schema coverage is 100%, so limit, status and both cursors are already documented; baseline is 3. The description only adds the one useful recipe of feeding the last id into starting_after, without clarifying ending_before or how status interacts with pagination.

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 ('List online payment Checkout Sessions') plus ordering ('newest first') and the fields surfaced, and the GET /checkout/sessions endpoint pins it to the collection. It implicitly separates itself from get/create/expire siblings by being the collection read, but never names them explicitly.

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

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

Usage is only implied: 'Cursor pagination: pass starting_after with the last id' tells the agent how to page but never says when to choose this tool over qashier_get_checkout_session or how to filter by status. No when-not-to-use or alternative routing is given.

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 only declare destructiveHint=true, but the description adds the critical facts: money moves to the original payment method, the refund is asynchronous with status pending, and there is no idempotency key so retries are unsafe. That is exactly the behavioral context the annotation does not carry.

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?

Four short sentences, front-loaded with operation class and risk, then semantics, then the retry hazard. Nothing is wasted and the highest-risk information appears before the procedural detail.

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 two-parameter mutation with no output schema, the description covers the return behavior (asynchronous, status pending) and the safety constraint (no idempotency, verify via get_checkout_session first). An agent has everything needed to invoke it correctly and safely.

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%, so both parameters are already documented including the cents unit and the omit-for-full-refund rule. The description restates that same information without adding format or edge-case detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('refund a paid Checkout Session to the customer's original payment method') and prefixes it with 'WRITE, MONEY' so the agent knows the operation class immediately. It is clearly distinct from the create/expire/get/list 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?

Explicitly says to omit amount for a full refund, and instructs the agent to call qashier_get_checkout_session before retrying, naming a concrete sibling and the condition that selects it. It also states a hard when-not: do NOT retry this call.

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