Approval Rules

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

With no annotations, the description carries the full burden and does well: it discloses the three return verdicts, the shape of the approval card/link, and a non-obvious side effect (free plan logs the check for the weekly report) plus the critical caveat that on free plans nothing is ever actually approved. It does not explicitly state that the call itself performs no mutation, but the wording strongly implies a read-only check.

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, front-loaded with the trigger and purpose, then outcomes, then the free-plan constraint. No filler; each sentence contributes distinct 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?

There is no output schema, so the description correctly compensates by naming the return values and the free-plan behavior. For a single nested-object parameter, this is nearly complete, though it could have clarified how this differs from retrieving decisions via get_decision.

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%, including per-field descriptions for type, target, summary, amount_usd and reversible, so the schema already does the heavy lifting. The description adds the notion that the action must be 'consequential' but no additional per-parameter semantics, so the baseline of 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?

The description states a specific verb and resource: ask whether the user's rules auto-approve a given action, and it enumerates the three possible verdicts. It is clearly not set_rules or get_rules, but it never distinguishes itself from the similar-sounding sibling get_decision, leaving relationship ambiguity.

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 gives a clear trigger ('before a consequential action') and an explicit fallback rule under the free plan ('ask your user as you normally would'). It stops short of naming when not to call it or pointing to get_decision as the alternative for retrieving existing decisions.

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 annotations, the description carries the full behavioral burden. It discloses the outcome domain (approved vs rejected) and that the call is a check, but omits whether other statuses exist (pending/expired), whether checking consumes or mutates the card/token, and any auth or rate-limit behavior implied by card_token.

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 with the core action front-loaded and the actionable constraint second. Efficient, though the trailing instruction is phrased loosely enough to be slightly ambiguous.

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 tool with zero schema descriptions, no annotations, and no output schema, the definition is thin: the return shape and full set of possible status values are left unspecified. An agent cannot tell whether 'status' has values other than approved/rejected or what to do with an unrecognized result.

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 0%, so the description must compensate and it does not. It merely restates both parameter names ('card_id and card_token') without explaining what a card_token is, where it comes from, or its format/validity, adding no meaning beyond the schema keys.

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 ('Check') and resource ('approval card') and names the two inputs that identify it, so the agent knows exactly what the tool returns: an approved/rejected decision. It does not, however, differentiate itself from the somewhat adjacent sibling check_action, so it falls 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?

The line 'Only act when status is approved' gives a conditional gate for what to do with the result, which is useful implied usage. But it never says when to call this tool versus check_action or any other sibling, nor what to do on a rejected/expired outcome.

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 annotations, the description carries the full behavioral burden. It usefully discloses fallback behavior ('or the default starter rules'), but says nothing about permissions/auth, whether the operation is read-only, or the return format.

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 well-formed sentence with the resource and scoping front-loaded and no filler. Appropriately sized for a zero-parameter retrieval tool.

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 zero-arg tool this is mostly adequate, but with no output schema the description should hint at what 'rules' actually looks like when returned, and it does not. The read-only nature is also left to inference.

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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate beyond the implicit sense that rules are scoped to the caller's key.

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 clear verb ('Show') and resource ('rules') with a scope qualifier ('in effect for your key'), making it distinguishable from the write-oriented sibling set_rules. It stops short of explicitly naming or contrasting any 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 guidance, no exclusions, and no reference to alternatives such as set_rules for changes or check_action/get_decision for evaluation. Only a weak implied read use-case is conveyed by 'show.'

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 annotations, the description carries the full burden and handles most of it: API-key auth requirement, a preview/confirm safety flow, first-matching-rule-wins priority, and unmatched-rules-need-approval fallback. The one notable gap is whether saving replaces or appends to existing rules, which matters for a mutation.

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?

Front-loads the core action and packs the critical rule grammar, matching semantics, and confirm workflow into a few dense lines with no filler. The nested brace notation is slightly hard to parse but 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?

For a mutation tool with no annotations and no output schema, it covers auth, rule format, evaluation semantics, and the confirm gate. The remaining ambiguity about replace-vs-merge behavior and error responses keeps it just short of 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 0% and the rule object is an untyped generic object, yet the description decodes the full shape: the when-clause fields (type, max_usd, min_usd, reversible, target_ends_with) and the verdict enum (auto|ask|deny). The confirm parameter's purpose is also spelled out. This compensates well for the empty 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+resource ('Save the user's rules'), which cleanly distinguishes it from the read-only sibling get_rules. It does not explicitly name a sibling alternative, but the write/read split is unambiguous from the description alone.

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?

Provides an explicit two-step workflow: 'Call once without confirm to preview, then with confirm=true,' which tells the agent exactly how to invoke it safely. It also flags the API-key prerequisite, though it gives no guidance on when to reach for this versus check_action or get_rules.

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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses the free-tier limit and that usage is 'not metered,' but omits auth requirements, side effects, rate-limiting behavior beyond the free tier, and return format, leaving key behavioral traits unspecified.

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 three short sentences with the purpose front-loaded. Every sentence contributes: the first states what is shown, the second and third provide free-tier and billing context. There is no wasted text.

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 zero-parameter tool with no output schema or annotations, the description covers the core purpose and some pricing context, but it does not specify authentication needs, return values, or other details an agent might need. It is minimally adequate but has clear gaps.

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 tool takes zero parameters, so per the rubric the baseline is 4. The empty input schema already communicates that no arguments are needed, and the description appropriately adds no parameter 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 states a specific verb and resource: 'Show today's usage for your key or IP and the $49/month All Access upgrade link.' It is clear what the tool does, but it does not differentiate itself from siblings such as weekly_report or other usage-related tools, so it falls 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?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It merely states what the tool shows, 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.

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

No annotations are provided, so the description carries the full burden, and it does disclose the two most important traits: output is a draft (generated preview, not committed) and it is read-only with no side effects ('sends nothing'). It does not cover permissions, latency, or whether it depends on existing rule/action data, which keeps it from a 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?

A single sentence that front-loads the action and window, then itemizes the report contents, closing with the read-only guarantee. Every clause carries information; no filler.

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?

No output schema exists, yet the description effectively summarizes what the report returns (the enumerated sections), and there are no parameters or annotations to reconcile. Nothing an agent needs to call a zero-arg read-only report tool 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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond the implicit fixed 7-day window, which it already states.

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?

Specific verb (draft) plus resource (report of the last 7 days) with the exact contents enumerated — actions checked, auto-approval counts, escalations, top ask kinds, rule suggestions. That content list makes it unmistakable against siblings like check_action, get_decision, and get_rules without needing to consult their 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?

The 7-day window and report contents imply when it applies, but no sibling is named and there is no explicit when-to-use/when-not guidance. An agent must infer that this is the overview tool rather than the per-decision tools.

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