Read or verify the governed result for one finalized control package by ID; this cannot authorize or execute actions.
Read or verify the governed Result for one finalized control package. This cannot authorize or execute.
| Name | Required | Description | Default |
|---|---|---|---|
| control_package_id | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds a small behavioral confirmation with 'This cannot authorize or execute', but it does not disclose error behavior, result scope, or other constraints beyond what the annotations already imply.
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 short sentences with no filler. The core operation is front-loaded, and the important cannot-authorize/execute exclusion comes immediately after. 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 simple one-parameter tool, the definition is functional: the agent knows what to call it with and the intended purpose. Yet it does not explain what the 'governed Result' consists of or what the return value looks like, and there is no output schema to supply that missing information.
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 has no description coverage, and the tool description does not meaningfully explain control_package_id beyond referring to a finalized control package. The pattern and length constraints in the schema are present, but the description does not compensate for the 0% coverage by explaining what the ID is, how to obtain it, or what constraints are semantically important.
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 ('Read or verify') and resource ('governed Result for one finalized control package'), so the core purpose is clear. It does not explicitly compare itself to siblings like market_validate_request, market_preview_request, or market_fetch_evidence, though it gives enough scope to be reasonably distinguishable.
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 phrase 'for one finalized control package' gives a useful when-to-use condition, and 'This cannot authorize or execute' hints at a boundary. However, it never names alternative tools or explains when the sibling tools should be used instead, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.