Set per-transaction limit

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

No annotations exist, so the description carries the full burden; it does disclose that this is a mutation that creates a rule and attaches it to a card, that subsequent authorizations over the limit are declined, and that a server-side cap rejects oversized limits. It omits whether an existing limit rule is replaced or duplicated, what permissions are needed, whether the rule can be later removed, and it never mentions the confirm-gated dry-run behavior that the schema flags as important in the live environment.

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, and the functional outcome is front-loaded before the server-side constraint. Nothing repeats the title or the schema.

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 mutation with no annotations and no output schema, the description covers the core effect and one server constraint but leaves the mutation's blast radius vague: no statement about replacement vs. additive behavior, no mention of the confirm dry-run mode, and no hint of what is returned. Adequate to invoke correctly, thin for invoking 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 description coverage is 100%, so all four parameters are already documented and the baseline is 3. The description adds the 500.00 USD ceiling, which is genuinely useful, but it phrases it in major currency units while maximumAmount is declared in minor units, so it creates a conversion ambiguity rather than resolving one.

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 ('Create an amount-limit spend rule') and states the observable effect ('attach it to a card, so any single authorization above the limit is declined'), which is far more than a restatement of the name. It does not explicitly distinguish itself from the closest sibling, restrict_merchant_categories, which is another spend-rule creation path, so it falls one step short of a 5.

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

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

Usage is implied by the effect statement: an agent can infer this is the tool for capping per-authorization spend. It gives no guidance on when to prefer it over restrict_merchant_categories or how it relates to simulate_authorization for testing, and the 500.00 USD ceiling is stated as a hard fact rather than as a precondition the caller should check before invoking.

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