evaluate_authority_actionCheck an exact action against a signed mandate, current lifecycle, and any required single-use action grant without executing it.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | ||
| signed_mandate | No | ||
| signed_action_grant | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a non-mutating operation, and the description reinforces this with 'without executing it'. It adds context about what is being checked (signed mandate, current lifecycle, single-use action grant) that goes beyond the annotation. It does not mention return formats or error behavior, but given the annotation coverage, the transparency is strong.
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 a single, well-structured sentence that front-loads the verb and includes the critical qualifier 'without executing it'. Every word earns its place, with no redundant or extraneous 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?
The tool has high complexity (signed mandates, lifecycle, single-use grants) and sparse schema (3 object params, no descriptions, no output schema). The description gives a high-level overview but omits expected return values, failure modes, and what 'current lifecycle' refers to. Given the annotations only cover read-only safety, the description is minimally viable but not fully complete for complex invocation.
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 0% schema description coverage, the description must compensate, and it does partially by naming the three inputs: 'an exact action' maps to the action parameter, 'signed mandate' to signed_mandate, and 'single-use action grant' to signed_action_grant. However, it does not explain the structure of these object parameters or the meaning of 'current lifecycle' (which is not a parameter), leaving significant ambiguity for an agent.
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 states the tool's function with a specific verb ('Check') and identifies the resources involved ('an exact action', 'signed mandate', 'current lifecycle', 'single-use action grant'). It also distinguishes itself from related tools like execute_delegated_action by explicitly noting it does not execute the action.
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 clearly implies the tool is for evaluating an action before execution, providing context for when to use it. It does not explicitly name alternative tools or exclusion criteria, but the phrase 'without executing it' effectively contrasts with execution tools in the sibling list, giving reasonable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
With 89 tools, there is extensive overlap. For example, multiple tools handle completing paid rail runs (complete_agent_self_serve_paid_rail_run, complete_paid_rail_run_with_callback, run_stripe_receipt_completion) and several verify receipts (verify_receipt, verify_managed_receipt_signature, verify_signature_by_version). Distinguishing between these without deep inspection is nearly impossible.
Most tool names follow a verb_noun snake_case pattern (e.g., start_rail_run, get_run_status, verify_receipt). However, there are minor deviations like 'credential_aware_mcp_write' which is not verb-first, making it slightly inconsistent. Overall the naming is quite uniform.
89 tools is an extreme count, far beyond the typical 3-15 or even 25+. This suggests the server is trying to cover too many sub-domains, making the tool surface unwieldy and difficult to navigate.
The tool surface is extremely broad, covering discovery, quoting, payment, run lifecycle, receipts, credentials, directory submission, compliance, and verification. It lacks some expected operations like cancellation or refund, but these are niche and the core workflows are well-covered.