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

No annotations are provided, so the description bears full burden. It discloses return structure and notes topics sit on top of pillars, but lacks details on side effects, authentication, or rate limits.

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, front-loaded with purpose, no redundancy. Examples are concise and helpful.

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 browse tool with one optional parameter and no output schema, the description is adequate. It explains what is returned and its relationship to pillars. Minor gap: no mention of default behavior when query is empty.

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 baseline is 3. The description adds context about cross-cutting topics but does not enhance meaning of the 'query' parameter beyond the schema's description.

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 specifies a verb ('browse') and resource ('registry by cross-cutting topic'), provides concrete examples, and explains return values (node, pillar, jurisdiction counts). It distinguishes from sibling tools that operate on nodes or jurisdictions directly.

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 implies use when exploring topics across pillars, but offers no explicit guidance on when not to use it or how it compares to sibling tools like 'search_nodes' or 'consult_node'.

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 bears full responsibility for behavioral disclosure. It indicates the tool returns a ranking and risk indicator (non-mutating checkout), but does not explicitly state whether it is read-only, has side effects, requires authentication, or has rate limits. The absence of such details leaves some behavioral ambiguity, though the 'pre-flight' metaphor suggests safety.

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 two sentences with no wasted words. The first sentence front-loads the core purpose ('Pre-flight compliance check') and provides immediate clarity. The structure is efficient, using a colon to introduce details and examples. Every sentence serves a purpose: defining the tool, giving examples, and stating its role.

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 tool has three parameters with full schema coverage and no output schema, the description covers the essential aspects: input format, output (ranked list + risk indicator), and use case. It could be more complete by mentioning whether the check is real-time or cached, or confirming that it is non-destructive. However, it is sufficient for an agent to select and invoke the tool 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 has 100% description coverage, providing baseline semantics for all three parameters. The tool description adds significant value by explaining the 'action' parameter usage with concrete examples and clarifying that 'jurisdiction' is a hint. It also implies a default limit of 10 (from 'max 25' in schema) and describes the output format. This extra context elevates the parameter understanding beyond the schema alone.

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: a 'pre-flight compliance check' that takes an action description in natural language and returns a ranked list of regulations and a risk indicator. It uses specific verbs and nouns, and the examples ('process EU resident biometric data') make the purpose unmistakable. The phrase 'headline runtime gate for autonomous agents' further distinguishes it as a proactive compliance tool, though it does not explicitly differentiate from sibling tools.

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 usage context (when to assess an action before execution) and gives examples of input, which implies when to use. However, it does not mention when NOT to use this tool or suggest alternatives among the siblings (e.g., browse_topics, compare_jurisdictions). An agent would need to infer usage boundaries from the tool's name and purpose.

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 discloses it surfaces real rules and does not rank, but lacks details on data sources, update frequency, or potential side effects like rate limits. Adequate but not thorough.

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 with no wasted words. First sentence captures core function and key example; second adds important qualifier about ranking and api_key. Front-loaded and efficient.

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 adequately explains what the tool does and its boundary (no ranking). Could optionally mention output format or supported jurisdictions, but not necessary for basic usage.

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 baseline 3 is fair. The description adds value by giving an example for 'topic' and explaining 'api_key' is optional, sent as header, and free trial counts. Goes beyond 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?

Clearly states the tool compares jurisdictions on a compliance topic side by side, including numeric thresholds. Distinguishes from siblings like 'check_action_compliance' or 'get_jurisdiction_bundle' by focusing on comparison.

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?

Tells when to use (compare jurisdictions) and explicitly states what it does not do (does not rank strictness). Mentions optional api_key usage. Could be improved by referencing sibling tools for other tasks.

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?

Despite no annotations, the description discloses that it consumes one call on the key, records an entry, pins the node version, and requires an open run. It covers essential behaviors but could mention error conditions.

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 and front-loaded with the key purpose. It uses four sentences without unnecessary detail, efficiently conveying the tool's function.

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?

With no output schema, the description should explain return values, but it does not. It also omits potential errors or states like what happens if the run is not open. This leaves a gap in completeness for agent decision-making.

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 add significant per-parameter meaning beyond what the schema already provides, thus scoring at baseline.

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 fetches a vault node and records a verified consult entry in a single step. It explicitly distinguishes this from get_node, making the purpose unambiguous.

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 provides explicit guidance: 'Use this instead of get_node when you are inside a run.' It also specifies the prerequisite of a Bidda subscription key, giving clear context when to use the tool.

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. It explains that each obligation is pinned to its current version and integrity hash at signing time, and that the record is tamper-evident. However, it does not disclose potential side effects, storage behavior, or retrieval mechanisms beyond what is implied.

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 two sentences plus a brief note, all front-loaded. First sentence gives the main action, second adds detail, third provides contrast. No fluff or 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?

Given no output schema, the description does not explain return values, success/failure indicators, or how to retrieve the created attestation. It also omits guidance on handling the max 50 nodes constraint. While the purpose is clear, missing return information reduces completeness for a tool with 9 parameters.

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 context for the overall purpose but does not significantly augment the parameter descriptions (e.g., it repeats the api_key requirement already in schema). No additional semantics are provided for individual 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 signs a tamper-evident record of a control/policy and its mapped obligation nodes. It explicitly contrasts design-side evidence with operating-side evidence (run receipts), distinguishing it from sibling tools like record_run_entry.

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 indicates when to use (for design-side evidence) and contrasts with run receipts, implying when not to use. It also mentions the requirement for a Bidda subscription key. However, it does not explicitly list alternative tools or conditions for avoidance.

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 full burden. It discloses the possible return states (fresh, drifted, withdrawn) and behavior when the hash is omitted. It does not cover rate limits or authentication details beyond requiring an api_key, but the core behavioral traits are explained.

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 two sentences with no wasted words. It front-loads the purpose, then explains the usage and outcome efficiently.

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 adequately explains return values (fresh, drifted, withdrawn). It covers prerequisites (api_key, cached hash), parameters, and the agent's follow-up action (re-ground). The context is complete for the tool's complexity.

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 has 100% coverage, so baseline is 3. The description adds value by explaining the role of the hash (integrity hash for prior grounding) and the effect of omitting it (fetch current fingerprint), beyond the schema documentation.

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: checking whether cached compliance rules are current. It specifies the action (submit node_id with integrity hash) and the outcome (fresh, drifted, withdrawn), distinguishing it from sibling tools like check_action_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 provides context for when to use the tool (before acting on stale rules) and a prerequisite (Bidda subscription key). However, it does not explicitly exclude scenarios or compare to alternatives, though the language implies its specific use case.

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 fully discloses behavioral traits: it explains the difference between sealed (readable by id) and open runs (needs api_key) and details the pack's contents.

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 dense paragraph that front-loads the purpose, but it could be slightly more structured for readability.

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 complexity and lack of an output schema, the description thoroughly covers the tool's purpose, contents, and usage conditions, including regulatory references.

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 covers both parameters (100% coverage), and the description adds value by clarifying the conditional requirement for api_key when the run is unsealed.

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 exports a run as a governance evidence pack and lists its specific components, distinguishing it from sibling tools like 'get_jurisdiction_bundle' or 'oscal_assessment_results'.

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 explains when to use the tool (exporting a run as an evidence pack) and provides context for sealed vs. open runs, but does not explicitly state when not to use it or mention 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?

No annotations are provided, so the description must convey behavioral traits. It indicates a read-only operation by using 'List', but does not disclose side effects, authentication requirements, rate limits, or the format of returned nodes. More transparency would be beneficial.

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 with two sentences, no wasted words. The first sentence states the core function immediately, and the second provides usage context. Excellent structure.

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 tool's simplicity (2 parameters, no output schema), the description is reasonably complete. It covers purpose and usage. However, it could elaborate on what a 'compliance node' is or the structure of the response, but the current level is adequate for an agent to understand the 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds context by listing example jurisdictions and explaining the tool's purpose, which enhances understanding beyond the schema. However, it does not add specifics on parameter usage beyond what is in the 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?

The description clearly states the action ('List') and resource ('compliance nodes') with a specific jurisdiction. It provides examples of jurisdictions, making the purpose clear. However, it does not explicitly differentiate from sibling tools like 'compare_jurisdictions' or 'browse_topics', so it lacks explicit sibling distinction.

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 clear usage context: 'Use when an agent enters a new market and needs the regulatory surface for that geography.' It tells when to use the tool, but does not mention when not to use it or provide 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 provided, the description bears full burden. It explains the output (changed primary sources with counts) and implies a read-only operation, but does not detail the tracking window or status meanings.

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 concise sentences: first defines the tool's purpose and output, second gives practical usage context. No wasted words.

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 tool with one optional parameter and no output schema, the description provides sufficient context about what it returns and why to use it. Minor gaps like defining 'tracking window' are acceptable.

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 fully describes the 'limit' parameter with min/max and default, so the description adds no additional meaning. 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?

The description clearly identifies the tool as a regulatory change feed for primary sources with counts by status. It distinguishes from siblings like 'browse_topics' or 'watch_changes' by focusing on recently changed documents and status counts.

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 usage hint ('Use to see what recently moved before relying on a cached rule'), but does not explicitly state when not to use it or mention alternative tools for similar tasks.

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 behavioral disclosure. It indicates the tool is a change feed (implying read-only), describes what it maps, and mentions filtering capabilities. However, it does not discuss pagination behavior, rate limits, or response structure, leaving some gaps.

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 two sentences: the first defines the tool's core functionality, the second provides a concrete use case and a prerequisite. Every sentence adds value, no fluff, and the most important information is front-loaded.

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 tool has 5 parameters, no output schema, and no annotations, the description adequately explains the tool's purpose, filters, and the API key requirement. It lacks details on response format or behavior at limits, but the presence of sibling tools with similar purposes makes the differentiation clear enough.

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 covers all 5 parameters with descriptions (100% coverage). The description adds contextual meaning by summarizing filter capabilities (time, pillar, nodes) and the requirement for an API key, but these largely mirror the schema descriptions without providing additional constraints or formatting 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 clearly states it is the 'obligation-level change feed' that maps changed primary sources to affected obligation nodes. It also provides a concrete use-case question ('what obligations changed since I last review?'), which strongly differentiates it from sibling tools like 'get_latest_changes' or 'watch_changes' that might be more general.

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 the tool answers a specific question and highlights filterability by time, pillar, or nodes. However, it does not mention when not to use it or provide direct comparisons to sibling tools, such as when to prefer 'obligation_deltas' over 'watch_changes' or 'get_latest_changes'.

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?

Without annotations, the description fully explains the export's content (reviewed-controls, observations, props) and notes the integrity self-check. It also clarifies the sealed/unsealed access behavior. However, it does not mention if any state is modified or if permissions are required beyond the api_key.

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, each earning its place: the first covers purpose and content, the second covers access conditions. No redundant or extraneous information, and the key details are front-loaded.

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 output format (OSCAL assessment-results with listed components) and handles the api_key condition. Since there is no output schema, the description adequately describes what the agent can expect. The tool's complexity is moderate, and all relevant aspects are addressed.

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?

Both parameters have schema descriptions with 100% coverage. The description adds value by explaining the purpose of api_key (required for unsealed runs), which the schema does not elaborate. However, the schema already describes the parameters adequately, so the addition is helpful but not essential.

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 specifies a concrete action: exporting a governed run's evidence as a NIST OSCAL assessment-results document, listing the included components (reviewed-controls, observations, props). This clearly distinguishes it from sibling tools, which perform different functions like browsing topics or checking 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 provides clear guidance on when the api_key parameter is needed (for still-open runs) and distinguishes sealed vs. open runs. However, it does not explicitly contrast this tool with siblings or state when to choose it over alternatives, though the unique OSCAL output implicitly sets it apart.

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 transparency burden. It mentions the signed, anchored nature of the record and the API key requirement, but does not detail return structure, error conditions (e.g., missing node_id at the date), or rate limits. Some transparency provided, but gaps remain.

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 two sentences: one defining the action, the second providing use case and requirement. No unnecessary words; highly concise and efficient.

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?

While the description covers purpose, usage, and key requirement, it lacks details on the return format (signed record structure) and potential edge cases (e.g., no version at date). Given no output schema, more detail would improve completeness. Sufficient but not thorough.

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 covers all three parameters with descriptions (100% coverage). The tool description reinforces the api_key requirement and node_id as 'rule,' but adds no additional semantics 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?

The description clearly states the tool retrieves a signed historical record of which rule version was authoritative at a given past date. It distinguishes itself from sibling tools like 'consult_node' (current version) and 'get_latest_changes' (recent updates) by specifying past point-in-time retrieval.

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 'Useful when an agent must show what a rule said at the moment it acted,' providing clear context for use. However, it does not name alternatives or state when not to use this tool, which would improve 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?

No annotations are provided, and the description only adds one behavioral detail: 'Each entry is hash-chained to the previous one.' This is useful but leaves out other traits like whether entries are immutable, permission requirements, or rate limits. The description carries the full burden and is only partially transparent.

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 two sentences, front-loading the core purpose and key behavioral note (hash-chaining). It is concise but packs significant detail. Some restructuring could improve clarity (e.g., separating the entry content from the requirement), but overall it is efficient.

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 complexity (12 parameters, no output schema, no annotations), the description covers the core purpose and ensures the agent knows what an entry contains. However, it does not describe the return value (e.g., success indicator or entry ID), prerequisites beyond the API key, or what happens if the run is not open. These gaps could hinder a new agent.

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 each parameter is documented. The description adds meaningful context beyond the schema by explaining the distinction between note and input_hash for user input, and mentioning that entry_type defaults to note. This enriches understanding of how parameters interact.

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 verb 'append' and the resource 'one entry to an open run', specifying the content (Bidda rules, decisions, user input). This distinguishes it from sibling tools like browse_topics or check_action_compliance, which are not recording actions.

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 mentions the requirement for a Bidda subscription key, but does not explicitly state when to use this tool versus alternatives (e.g., consult_node, drift_check). Usage is implied by the recording nature, but no exclusions or comparative context are provided.

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. It mentions that the tool returns nodes with id, title, pillar, and BLUF, and that every node traces to a primary legal source. However, it does not describe behavior such as result ordering, handling of no results, or whether search is fuzzy/exact. These gaps leave some behavioral uncertainty.

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 two sentences: the first states the core function and return fields, the second provides usage guidance and examples. It is front-loaded, efficient, and every sentence contributes meaningfully. No redundant or vague phrasing.

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 search tool with 3 parameters and no output schema, the description covers the essential aspects: functionality, return information, usage context, and examples. It lacks details on pagination or result limits (though limit param is documented), but overall it provides sufficient context for an agent to use the tool 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 coverage is 100% with clear parameter descriptions. The description adds value by showing example queries ('GDPR breach notification 72 hours') and hinting at pillar usage via 'list_pillars'. However, it does not significantly enhance understanding beyond the schema, so a 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 starts with 'Keyword search across the Bidda registry of source-verified compliance obligations', clearly stating the verb ('search') and the resource (registry of obligations). It distinguishes from sibling tools like browse_topics or consult_node by being a general search tool, and the examples and usage guidance reinforce its unique 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 includes 'Use to find the rule that governs a topic, law, standard, or MITRE technique' and provides concrete examples. While it doesn't explicitly say when not to use or list alternatives, the context of sibling tools and the clear search purpose imply the appropriate use cases. It would benefit from mentioning when to use browse_topics or consult_node instead.

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. It discloses the subscription nature and delivery methods (email/webhook), but lacks details on unsubscription, subscription lifecycle, limits, or what the tool returns (e.g., a subscription ID).

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: first captures action and method, second adds a critical prerequisite. No extra words, front-loaded, and 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 6 parameters, nested objects, and no output schema, the description covers the what, how, and prerequisite. It misses the return value (e.g., subscription ID or confirmation), but overall is sufficient for an agent to understand the tool's role among 14 siblings.

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?

All 6 parameters have schema descriptions (100% coverage), but the description adds value by explaining how parameters like 'nodes', 'pillars', 'channels', and 'webhook_url' relate to the overall purpose of watching rules and pillars and getting notified.

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 verb 'Subscribe', the resource 'regulatory change alerts', and the outcome 'get notified by email or webhook'. It specifies what can be watched ('specific rules and/or whole pillars'), distinguishing it from sibling tools like 'get_latest_changes' (one-time query) and 'browse_topics' (browsing).

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 the key prerequisite: 'Requires a Bidda subscription key (a free trial counts)'. It implies use for ongoing notifications rather than on-demand queries, but does not explicitly state when not to use or name alternatives.

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