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

With no annotations provided, the description carries the full transparency burden. It discloses key behaviors: the record is immutable, timestamped to now, and dry_run=true previews without writing. It also explains auditor verification. This is strong, though it omits details like permissions or failure modes.

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 well-structured: a crisp main sentence, a bulleted list of use cases, then behavioral notes and dry_run guidance. Each section earns its place without redundant fluff, making it easy to scan and understand.

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 tool with 7 parameters and no output schema, the description sufficiently covers purpose, usage, behavior, and even hints at response structure (e.g., nil UUID in dry_run). It lacks error handling or permission details, but overall it's complete enough for an agent to use effectively.

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 documents all 7 parameters. The description adds minimal extra parameter context (e.g., dry_run usage), but doesn't significantly enhance beyond the schema. Baseline 3 is appropriate.

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?

Description clearly states the tool's purpose: recording that a team member read and understood an AI governance policy. Uses a specific verb ('record') and resource ('policy_acknowledged evidence record'), and distinguishes itself from sibling tools like attest by focusing on policy acknowledgment for compliance.

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 includes a 'Use this when' section listing three concrete scenarios: new employee onboarding, policy updates, and periodic renewals. It also advises using dry_run before the real call but doesn't explicitly mention when not to use this tool, so it stops short of full exclusion guidance.

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 fully discloses behavior: it returns record_id and compliance controls earned, notes that unknown fields are stored but earn no controls, explains the enforce_gates blocking behavior, and states default values for environment and occurred_at. This goes well beyond the structured 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?

The description is compact and well-structured, leading with the core purpose, then when to call, when not to call, and finally the return value. Every sentence carries meaningful information with no 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?

Despite lacking an output schema, the description clearly explains the return value (record_id and controls) and how the records integrate with the governance dashboard. It also covers exclusions and gate-checking behavior, making it complete for this 8-parameter tool with no annotations.

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%, with rich descriptions for all 8 parameters. The main description adds no additional parameter-level semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 opens with a specific verb ('Record') and resource ('compliance evidence event in the Mima governance ledger'), and further specifies the compliance frameworks (EU AI Act, SOC 2, ISO 42001, NIST AI RMF). This clearly defines the tool's purpose and distinguishes it from siblings like dry_run_attest or check_gates.

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 explicit usage guidance: 'Call this when the AI system performs a governance-relevant action...' and 'Do NOT call this for routine AI inference calls'. It also names dry_run_attest as an alternative in the enforce_gates parameter description, giving clear when-to-use vs when-not-to-use direction.

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 of behavioral disclosure. It explains that the tool returns each gate's current score vs threshold and pass/fail status, which is transparent for a read-only check. However, it does not explicitly state the operation is read-only, mention permissions, or address limitations, leaving room for more context.

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 concise, front-loaded with the primary purpose, then return information, then usage examples. Every sentence earns its place, and there is no fluff or repetition.

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 is simple with no parameters and no output schema, but the description explains what gates are, what the tool returns, and provides example use cases. Given the complexity, the description is complete enough for an agent to select and invoke the tool confidently.

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 has zero parameters, and the schema coverage is 100% (vacuously). Per the baseline for 0 parameters, the description does not need to explain parameters, and it appropriately avoids adding irrelevant detail.

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 checks the status of all configured governance gates for the workspace, with a specific verb and resource. It distinguishes itself from siblings by focusing on gate status and threshold-based blocking, and is not ambiguous.

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 explicit usage guidance with example questions like 'Can we deploy right now?' which help the agent know when to invoke it. However, it does not explicitly name alternative tools or when-not-to-use it, so it lacks the full 'when/when-not/alternatives' clarity that would earn 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?

With no annotations provided, the description carries full burden. It transparently lists what it returns (action description, uncovered required controls, risk tier, Art. 14 status) and notes non-determinism ('where deterministic from the ledger'). It also explains the null art14_applicable behavior and suggests a resolution path, exceeding typical disclosure.

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 sentences, front-loaded with the core purpose, followed by a structured list of outputs and actionable guidance. No filler or redundancy; 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?

Given no output schema, the description thoroughly explains return values (action description, uncovered controls, risk tier, Art. 14 status) and includes conditional behavior for nulls and a recommended next step. It is complete for an analysis tool with moderate complexity and good sibling context.

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 already provides 100% description coverage for all three parameters, including detailed guidance for ai_risk_tier ('high → art14_applicable=true'). The tool description adds no extra parameter-level information beyond what the schema already states, so it hits the baseline for high schema coverage.

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 opens with a specific verb+resource: 'Returns your current governance coverage gaps relative to the described action.' This clearly distinguishes it from siblings like attest, get_posture, and dry_run_attest by focusing on gap analysis rather than attestation or overall posture.

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 clear context for use: 'Use this data to reason about which record types the described action requires and why — then propose them via dry_run_attest before writing.' It also gives a conditional for unregistered systems ('Offer to run /mima:register-systems to resolve it'). While it doesn't explicitly list when-not or alternative tools, the workflow is clear.

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 does so thoroughly. It discloses that nothing is written to the ledger, that the return value includes the same mapped_controls list as `attest`, and that record_id will be the nil UUID to signal no DB write. This is rich behavioral context beyond the basic 'dry run' idea.

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 well-structured with a front-loaded purpose sentence, a numbered workflow, and a clear return-value explanation. Every sentence adds value: the nil UUID clarification and the 'Do NOT skip' warning are both practically useful. It is not overly verbose.

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 description fully covers the tool's role in the compliance loop, its output shape, and the safety implications. It even explains how to interpret the nil UUID and why the step should not be skipped. For a tool with 4 parameters, nested objects, and no output schema, this is very 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%, so the baseline is 3. The description adds extra meaning by noting that `payload` uses the 'same schema as `attest`', clarifying that `identity` is the user or service identity that would be recorded, and explaining that the returned nil UUID is a signal of no write. This goes slightly beyond schema descriptions.

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 opens with a specific verb and resource: 'Preview which compliance controls a proposed evidence record would earn — without writing anything to the ledger.' It clearly distinguishes itself from sibling `attest` by saying 'Use this before calling attest' and explicitly frames it as a dry-run verification step.

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 explicitly states when to use the tool: 'Use this before calling `attest` to confirm the record is correct.' It also provides a numbered step sequence (get_posture → dry_run_attest → human approval → attest) and a strong exclusion: 'Do NOT skip this step when proposing records on behalf of a human.' This gives clear context and alternatives.

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 must fully convey behavior. It discloses the nature of the return data (compliance scores, failing gates, call counts) and implies a read-only action via 'Get'. However, it does not explicitly state that the operation is side-effect-free, requires specific permissions, or has any rate limits or data freshness caveats.

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 well-structured: the first paragraph states purpose and outputs, the second paragraph provides practical usage examples. Every sentence earns its place, and the information is front-loaded. It is concise yet comprehensive without being verbose.

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?

Given the simplicity (no parameters, no output schema), the description provides sufficient context by listing the return elements and example questions. It could have added a note about read-only nature or data boundaries, but overall it is complete for a straightforward retrieval tool.

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 has zero parameters, so the schema provides no parameter semantics to explain. The baseline for zero parameters is 4, and the description doesn't need to add any parameter information. It doesn't waste space on non-existent parameters.

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 verb ('Get') and resource ('AI governance posture'), and breaks down specific outputs (per-framework compliance scores, failing gates, unattested call count). This is a specific, action-oriented explanation that distinguishes it from sibling tools like check_gates, which is more narrowly about gates.

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 clear usage context by listing example user questions that this tool answers ('How compliant are we with the EU AI Act?', 'Which frameworks have gaps?'). It does not explicitly mention alternatives or exclusion criteria, but the examples effectively guide when to use this tool versus a more specific one.

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 provided, the description carries the full behavioral burden and does so thoroughly. It discloses ordering ('newest-first'), result limits ('Default limit 20, max 100'), and the meaning of the source field ('sdk' vs 'inferred' with audit weight). This gives the agent important context for interpreting results.

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 well-structured and every sentence earns its place: a clear purpose statement, a usage rationale with concrete examples, and key behavioral details. It is concise yet complete without fluff.

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 context signals show no output schema and no annotations, so the description must fully equip the agent. It covers return ordering, limits, filtering semantics, and the meaning of the source field, making the tool's behavior fully predictable for a read-only listing operation.

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 input schema already achieves 100% parameter coverage, so the baseline is 3. The description adds small value by explaining the 'since' example format and reinforcing the default/max limit, but it largely restates schema information without introducing significant new semantics.

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 opens with a specific verb and resource: 'List evidence records from the governance ledger'. It clearly distinguishes the tool from siblings like attest (create records) and list_systems (list systems) by focusing on reading evidence with optional filters.

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 explicitly states when to use: 'Use this to understand what evidence already exists before proposing new records'. It provides concrete example queries showing the kinds of questions this tool answers. It does not explicitly mention when not to use it or name alternatives, so a small gap remains relative to a perfect 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?

With no annotations provided, the description carries the transparency burden. It explains the meaning of the key field is_registered, including the Art. 9 intake gap, and lists the returned fields. It does not explicitly state read-only status, but the 'list' semantics and lack of side effects imply it. The description adds valuable behavioral context beyond the raw 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?

The description is well-structured and front-loaded: the first sentence states the core function, followed by a key-field explanation, bulleted use cases, and a return list. Each section adds meaningful value without redundancy. It is concise yet comprehensive, earning every word.

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?

Even without an output schema, the description lists all return fields and explains the critical field is_registered. The optional filter is documented in the schema. The tool is simple, and the description covers purpose, semantics, usage, and output, making it complete for an agent to invoke correctly.

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 input schema already fully documents the single optional parameter system_name with a description. The tool description does not add new information about the parameter, but the schema coverage is 100%, so the baseline of 3 is appropriate. The description emphasizes output semantics, not 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 opens with a clear, specific verb+resource statement: 'List all AI systems in this workspace with their registration status and evidence coverage.' It distinguishes itself from sibling tools like list_evidence (which lists evidence, not systems) and register_system (which registers systems). The additional use cases further clarify the tool's purpose.

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 explicit usage guidance via a 'Use this to' bullet list, covering identification of unregistered systems, evidence gap analysis, and answering common questions. It does not explicitly mention when not to use this tool or name alternatives, but the context makes the applicable scenarios clear.

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 provided, the description bears full responsibility for disclosing behavior. It explicitly notes that the real call writes a ledger entry while dry_run=true 'preview[s] which controls this registration would earn without writing anything' and that the nil UUID signals no write occurred. It also discloses that registration is mandatory and returns record_id and mapped controls. This goes beyond minimal disclosure, though it does not discuss permissions or irreversibility.

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 well-structured: it opens with a clear purpose, then gives usage context, example utterances, dry-run guidance, and return values in a logical, front-loaded order. Every sentence contributes unique information, and the bullet-point examples make it easy to scan. It is appropriately sized for the tool's complexity.

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 description covers the essential context for an AI agent: when to invoke, what it does, how dry-run works, and what the response contains (record_id and mapped controls). Since there is no output schema, this return-value disclosure is valuable. It could add more about failure modes or prerequisites, but for a registration tool with 100% schema coverage, it is sufficiently 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 description coverage is 100%, so the baseline is 3. The description does not need to explain each parameter, and it adds minimal extra meaning beyond the schema—mainly reinforcing dry_run's purpose, which is already described in the schema. The schema itself carries the parameter semantics, so the description neither detracts nor significantly augments.

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 purpose: 'Register an AI system in the Mima governance ledger. Creates an Art. 9 risk assessment record.' This is a specific verb+resource pair that differentiates it from sibling tools like list_systems or derive_controls, and it includes the regulatory context (EU AI Act).

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 explicitly says when to use it: 'during design reviews or architecture discussions when a new AI system is being planned or has just been deployed' and provides realistic example utterances. It also explains the dry_run workflow, but it does not explicitly mention when not to use it or point to alternative tools, though the guidance is clear enough without exclusions.

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 full burden for behavioral disclosure. It explains the tool's analysis and the four types of suggestions, but does not state whether it is read-only, requires specific permissions, or has any side effects. It also does not describe the output format or data sources.

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 well-structured: a clear first sentence, a concise bulleted list of the four output actions, and a practical list of example queries. Each section adds relevant information without 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?

The description is detailed for a tool with no parameters, no annotations, and no output schema. It covers the tool's purpose, the types of recommendations, and use cases. It could mention prerequisites or limitations, but the example about having no gates configured implies it works from scratch.

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 has zero parameters, so the baseline is 4. The description correctly focuses on the tool's behavior rather than parameter details, and there is nothing to clarify since the schema is empty.

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 analyzes governance posture and gate configuration, then returns a prioritized list of gate recommendations. It distinguishes itself from sibling tools by focusing on recommendations rather than execution or checking, and the four action types add specific value.

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 explicit example queries and a zero-configuration starting point, clearly indicating when to use the tool. It does not explicitly mention when not to use it or alternatives, but the examples make the intended use case clear.

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