Bidda Sovereign Intelligence

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

The description adds behavioral details beyond the readOnlyHint and openWorldHint annotations, such as returning aggregated counts and supporting drill-in via the topic parameter. It explains the conceptual relationship to pillars, which is useful. The mention 'Free, no key required' is redundant with openWorldHint, but the rest adds value.

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 with the core purpose. It contains five sentences, but one sentence ('Free, no key required') duplicates the openWorldHint annotation and could be removed without loss. Overall, the description is efficient and informative.

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 read-only tool with one optional parameter, the description covers the essential aspects: what it does, what it returns, and the parameter's effect. It also provides context on how topics relate to pillars. Since there is no output schema, the description's mention of 'how many rules carry it and across how many pillars and jurisdictions' helps set expectations, though it could mention edge cases like no results.

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 describes the topic parameter as 'Optional topic name to filter or drill into,' and the description reinforces this with 'Pass a topic string to drill into one.' It also clarifies the default behavior by stating the tool returns all topics when no parameter is passed. The examples of topics add semantic richness beyond 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 tool's function: 'Browse the registry by cross-cutting compliance TOPIC' and specifies the output—'each topic with how many rules carry it and across how many pillars and jurisdictions.' It distinguishes itself from siblings like list_pillars by emphasizing that topics are cross-cutting and sit on top of the 39 pillars without replacing them.

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 when to use the tool: for browsing topics rather than pillars or other registry views. It also explains the optional topic parameter, saying 'Pass a topic string to drill into one.' However, it does not explicitly mention alternatives or when not to use it, so it stops short of full explicit 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?

Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds value by detailing the output (ranked list of regulations, risk indicator) and the 'may apply' nuance, indicating a non-exhaustive heuristic. This aligns with annotations and adds transparency.

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 the core purpose, then examples, then positioning. No redundant 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?

The tool has 3 params, no output schema. The description provides sufficient context about inputs (natural language action), outputs (ranked list + risk indicator), and usage domain. It could detail the output structure more, but for a read-only compliance check, this is adequate.

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 100% of parameters with descriptions. The description enhances the 'action' parameter with concrete examples (EU biometric data, health records transfer, trading model) that teach the agent how to phrase queries. Limit and jurisdiction are already well-documented in 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 tool's function: a pre-flight regulatory check that takes natural-language action descriptions and returns ranked regulations with a risk indicator. It distinguishes itself from siblings by being 'the primary tool for runtime compliance gating'.

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 explicitly frames when to use: before performing an action, as a pre-flight check, and positions itself as the primary tool for runtime compliance gating in autonomous workflows. It doesn't explicitly name alternatives or when-not-to-use cases, but the context is strong.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the bar is lower. The description adds an important auth requirement (active subscription, pass api_key) and a behavioral constraint (does not rank), which are beyond what annotations provide and help the agent understand usage constraints.

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 main purpose, followed by clarifying limitations and requirements. Every sentence earns its place, with no redundancy or 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 description conveys purpose, non-ranking behavior, and auth prerequisites, but lacks output format details (e.g., how the side-by-side comparison is structured) since there is no output schema. It also leaves topic scoping and error handling implicit, making it incomplete for a tool with no output schema.

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 topic and api_key are already well described in the schema. The description adds an example of a topic ('data breach notification') and repeats the api_key requirement, but this is marginal added value; 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 compares jurisdictions on a compliance topic side by side, with a concrete example of numeric thresholds. It also distinguishes itself by explicitly noting it does not rank which jurisdiction is stricter, setting it apart from sibling tools like get_jurisdiction_bundle.

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: use for side-by-side comparison of rules, with a stated prerequisite (active Bidda subscription). It also implies a when-not by saying it does not rank, but it does not explicitly name alternatives or exclusion scenarios, missing the top tier.

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?

The description discloses resource consumption ('consumes one call on your key'), authentication requirements ('Requires an active Bidda subscription: pass api_key'), and side effects (records a node_consulted entry that pins version + integrity hash). These go beyond the annotations, which only indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false.

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 dense sentences that front-load the core behavior ('one-call governed turn') and then deliver essential usage context. No wasted words; every clause adds value.

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 combines fetch and record operations, requires auth, has a specific use case, and has no output schema. The description covers the operational context, the reason for the integrity tracking, and the auth prerequisite. Optional parameters are documented in the schema, so the description doesn't need to repeat them.

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 covers all 9 parameters (100% coverage), but the description adds important context for api_key (Bidda subscription, free trial counts) and clarifies the combined role of run_id and node_id. The explanation of the integrity hash provides context for the optional hash parameters even though it doesn't name them directly.

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 dual action: 'fetch the full vault node' AND 'record a verified node_consulted entry for it on an open run'. It also distinguishes from a sibling by saying 'Use this instead of get_node when you are inside a run'.

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?

Explicitly tells when to use: 'inside a run', and names the alternative get_node. The condition 'when you are inside a run' implies the excluded case (outside a run), providing clear use-vs-alternative 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?

Beyond the annotations (readOnlyHint: false, etc.), the description adds meaningful behavioral context: it creates a record, returns a record ID and a public verify URL, and confirms immutability ('later confirm the record has not been changed'). It also discloses the subscription/api_key requirement. This goes beyond what annotations already state and helps set expectations.

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 efficient and front-loaded: the main purpose is in the first sentence, followed by return value, usage, and a requirement. Each sentence contributes useful information, though it could be slightly tighter if you drop 'time-stamped' redundancies. Overall, it is concise and well-structured.

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 schema richness (5 well-documented parameters) and annotations, the description adds important context about return values and the requirement of an active subscription. It does not explain exact node_id format or edge cases, but for a create tool with good schema coverage, it is reasonably complete. The absence of an output schema is compensated by the explicit mention of the returned record ID and verify URL.

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 for all five parameters, so the bar for description-added value is lower. The description only mentions api_key explicitly ('pass api_key') and does not elaborate on agent, nodes, action, or workflow_steps_followed beyond the schema. Thus it provides marginal added meaning, consistent with the baseline of 3.

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: 'Create a signed, time-stamped record of which Bidda rules a person or AI agent relied on for a decision.' This is a specific verb+resource with a clear scope. However, it does not distinguish itself from the sibling tool create_control_attestation, so it doesn't fully differentiate between potentially similar options.

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: 'Useful for agents that must keep an audit trail of what they checked.' It also notes the subscription requirement. However, it does not explicitly mention when not to use the tool or alternatives like create_control_attestation, so it lacks exclusions or explicit alternative 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?

Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable behavioral context: tamper-evidence, pinning to version + integrity hash at signing time, and the subscription requirement. It does not go into further lifecycle details (e.g., whether records are permanently immutable), but the description covers key behaviors beyond the annotations.

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 four sentences long, each serving a distinct purpose: main action, behavioral detail, differentiation from alternatives, and a prerequisite. It is front-loaded with the core verb and resource, with no redundant or filler content.

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 9 parameters, no output schema, and no idempotency, the description provides essential context about purpose, behavior, and usage. It does not describe what the response contains (e.g., a record ID or signed artifact), which would be helpful but is not strictly required by the criteria since there is no output schema.

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 100% description coverage for all 9 parameters. The description mentions 'control or policy' and 'obligation nodes' but does not add significant new meaning beyond the schema's own descriptions. It reiterates the api_key requirement but nothing that would shift it above the 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 that this tool signs a tamper-evident record of the user's own controls/policies and maps them to Bidda obligation nodes. It distinguishes itself from run receipts by explicitly positioning this as design-side evidence, and the verb 'Sign a tamper-evident record' is specific and resource-oriented.

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 contrasts this tool with run receipts, stating 'This is the design-side evidence... run receipts are the operating-side evidence.' This provides a clear when-to-use and an alternative tool category. It also states a prerequisite: 'Requires an active Bidda subscription: pass api_key.'

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?

Even though annotations already declare readOnlyHint=true and openWorldHint=true, the description adds context: it returns fresh/drifted/withdrawn statuses, allows omitting the hash to fetch current fingerprint (from schema), and notes per-call batch size scales with plan. This goes beyond annotations and gives useful behavioral expectations.

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 front-loaded with the primary purpose, then explains the input/output, then adds plan scaling. At four sentences it stays reasonably concise, though the 'Pass api_key' is already visible in the schema and the 'Included with every API tier' may be slightly extraneous.

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 complete enough: it names the inputs (node_id and hash), the output (per rule fresh/drifted/withdrawn), and the usage context (re-ground before acting). With no output schema, it still adequately describes returns, making it self-sufficient.

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 baseline is 3. The description explains the anchors as 'the integrity hash you stored when you last grounded,' but doesn't add much new meaning. There is a minor ambiguity: it says submit node_id and hash together, while the schema marks hash as optional, so it doesn't fully clarify parameter behavior.

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 with a specific verb and resource: 'Check whether the compliance rules an agent has cached in its own memory are still current.' It also differentiates by describing the per-rule outcome (fresh, drifted, withdrawn), which distinguishes it from sibling tools like get_latest_changes or watch_changes.

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 on when to use: before acting on cached rules, to re-ground on stale law. It also mentions it's included with every API tier and batch size scales with plan. However, it does not explicitly name alternative tools or exclusion cases, so it stops short of 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable context: the requirement for an active Bidda subscription (api_key), the specific output content (prerequisite gaps and withdrawn rules), and the scope limitation (based on Bidda's dependency graph). No contradiction with annotations.

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 primary purpose. It uses three sentences with no wasted words, each sentence contributing distinct value: core functionality, scope/disclaimer, and authentication requirement.

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 moderate complexity, the description adequately explains the output (missing prerequisites and withdrawn rules) without an output schema. It notes the subscription requirement and clarifies limitations. It could mention error cases or examples but is sufficiently complete for an agent to select and 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?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it clarifies that 'nodes' likely refers to the compliance rules a team says it covers and emphasizes the api_key requirement. This is marginal but not enough to raise the score.

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: returning prerequisite rule gaps from Bidda's dependency graph and withdrawn rules. It specifies the exact resource (compliance rules), the verb (return), and the nuance (NOT listed, withdrawn), distinguishing it effectively from sibling tools like drift_check or 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 that it is a coverage aid for a qualified reviewer and explicitly states what it does not do ('does not rank or determine compliance'). This implies appropriate use cases, though it does not name specific alternatives or exclusions beyond this.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the important behavioral trait that a still-open run's draft pack requires api_key, and clarifies that sealed runs are readable by id. This goes beyond the annotations without contradicting them.

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; the first lists contents compactly, the second clarifies state-dependent behavior. No redundant or filler text; every phrase adds 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?

For a 2-parameter tool with no output schema, the description sufficiently describes what the tool returns (pack contents) and the access conditions. No missing critical information such as error cases, but those are not necessary for a read-only export.

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?

Input schema already documents both parameters with 100% coverage. The description adds the conditional that api_key is needed for unsealed runs, which clarifies the otherwise optional parameter's role. This extra context elevates it above the 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 exports a run as a governance evidence pack, listing concrete contents (signed receipt, entries, node roll-up, hash-chain/Merkle check, coversheet). This distinguishes it from sibling tools like get_run by specifying the full audit pack rather than just run details.

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 about sealed vs open runs and the api_key requirement, but does not explicitly mention when to use this tool over alternative siblings (e.g., get_run). No exclusions or alternative tool references are given, so usage is only implied.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context by noting that discovery returns available dimensions while full mapping values are vault-gated, which tells the agent about a two-tier access model not captured in annotations.

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 front-loaded action, includes a clarifying example, and ends with a concise note on access levels. Every sentence earns its place 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?

Given the simple schema (one parameter) and lack of output schema, the description adequately covers the return value ('mapping dimensions') with an example and notes the vault-gating nuance. It is complete enough for a look-up tool, though a brief mention of output format would have made it fully concrete.

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 provides 100% coverage with a clear description of node_id ('Node ID to inspect crosswalks for'). The description's mention of 'for a node' adds no significant semantic detail beyond the schema, so the baseline score 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 uses a specific verb+resource ('Return the cross-framework mapping dimensions for a node') and includes a concrete example chain. It distinguishes itself from siblings like get_mitre_mapping by focusing on cross-framework mappings across regulations, standards, and jurisdictions.

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 its use case when cross-framework mappings are needed, but it does not explicitly state when to use this tool versus alternatives. It lacks exclusions or direct comparisons with sibling tools such as get_mitre_mapping or compare_jurisdictions, so guidance is only implied.

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?

Annotations already signal read-only and open-world hints, lowering the bar. The description adds useful behavioral details beyond the schema: it explains the tool's traversal behavior (full dependency tree), gives a typical size estimate (3-8 upstream nodes), and clarifies the default depth (2) and maximum (4). No contradiction with annotations.

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 sentences, front-loaded with the action, followed by a clear explanation, use case, and parameter defaults. Every sentence contributes meaning without redundancy or 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 tool is relatively simple with two parameters and no output schema. The description covers what the tool does, when to use it, and its key behavioral constraints. It doesn't detail the exact structure of the returned tree, but given the tool's straightforward nature and the presence of the input schema, 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 coverage is 100%, so the baseline is 3. The description repeats the default/max depth information already present in the schema ('Defaults to depth 2; max 4') but doesn't add substantial new meaning beyond what the schema provides. The phrase 'full dependency tree' gives some context but is not parameter-specific.

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 walks the prerequisite chain for a compliance node and returns the full dependency tree, which distinguishes it from sibling tools like get_node (single node retrieval) and search_nodes (search). It uses a specific verb+resource construction and explains the output at a high level.

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 context: 'Use this to plan a complete compliance posture' and notes that unlocking one node typically requires understanding 3-8 upstream nodes. It doesn't explicitly name alternatives or when not to use it, but the context is clear enough for an agent to decide.

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?

Annotations already cover read-only safety, so the description need not repeat that. It adds useful context about the jurisdictions covered and the 'full regulatory surface' concept, but doesn't disclose behavior like pagination or result ordering. With annotations providing the safety profile, this is adequate but not rich.

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 the action and resource, with no filler. The first sentence states the core function, and the second gives a concrete use case. Every word 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 filtered-list tool with two parameters and no output schema, the description covers the essential context: what it returns, which jurisdictions are supported, and when to use it. It could mention response format, but the readOnlyHint and openWorldHint supply additional context, making it 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 description adds no significant meaning beyond what parameters already document. The jurisdiction list is duplicated from the schema, and 'limit' is fully described in the schema. Baseline score of 3 is appropriate because the schema does the heavy lifting.

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 uses a specific verb ('Return all compliance nodes that apply') and clearly identifies the resource (compliance nodes for a jurisdiction). It distinguishes itself from siblings like compare_jurisdictions by focusing on a single jurisdiction's full regulatory surface, making the tool's unique purpose obvious.

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?

Explicitly states when to use: 'when an agent enters a new market and needs the full regulatory surface for that geography.' This provides clear context and implies an exclusion for comparative or topical needs, though it does not explicitly name alternative tools.

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?

Annotations already mark the tool as readOnly and openWorld. The description adds context about it being a regulatory change feed and provides scheduling advice, but does not disclose return format, pagination, or other behavioral details. With annotations covering the safety profile, a 3 is appropriate.

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 sentences, front-loaded with the primary purpose. Every sentence adds value: purpose, usage, and scheduling guidance. There is 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?

For a simple read-only tool with two optional parameters and no output schema, the description covers the core purpose, use case, and operational guidance. It doesn't detail return values, but the description implies the result is a list of nodes, which is sufficient for this complexity level.

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 both parameters described in the schema. The description adds minimal extra meaning ('Filter by pillar to focus on a domain'), essentially paraphrasing the schema. This matches the baseline 3 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 clearly states the tool lists recently updated compliance nodes, framing it as the regulatory change feed. It uses specific verbs ('List', 'monitor') and resource scope, and differentiates from siblings by emphasizing its role as a feed for monitoring amendments and new guidance.

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 to use this tool for monitoring incoming changes and suggests calling it on a schedule to keep compliance posture current. It also mentions filtering by pillar, giving concrete usage context. However, it does not explicitly mention alternatives or when not to use it, so it falls just short of 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that it returns a Bidda node plus obligations and mentions 'Free', but does not detail rate limits, authentication, or response structure beyond that.

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-loaded with a memorable metaphor and then detailed specifics. It is slightly verbose with 'The MITRE Rosetta Stone' and 'Free', but each part adds flavor or info. No wasted sentences.

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 (multiple frameworks and compliance standards) and no output schema, the description should explain more about the response format. It lists the standards but not the structure, which is a notable gap for an AI 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?

The schema description covers 100% of the parameter with extensive valid ID examples. The tool description adds framework context but introduces a slight inconsistency by listing 5 frameworks while schema includes CAPEC as an additional valid input type. Overall, the schema does the heavy lifting.

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 maps a MITRE technique ID to a Bidda node and associated compliance obligations across multiple frameworks. It distinguishes itself from siblings by its specific 'Rosetta Stone' role, bridging SOC and compliance terminology.

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?

Usage is implied clearly: when you have a MITRE technique ID and need mapping to compliance controls. It does not explicitly name alternatives or say when not to use, but the context is strong enough to guide selection among sibling tools.

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?

The description adds useful context beyond annotations: it specifies that the tool returns a summary (title, compliance pillar, version, last updated, BLUF) and that the full node is accessible at bidda.com. While readOnlyHint and openWorldHint already indicate safety and open nature, the description clarifies the output content and external reference, enhancing behavioral transparency.

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 well-structured. It opens with the key action, then enumerates the summary fields, and finally points to the full node location. Every sentence provides value with no redundancy or extraneous details.

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 get-by-ID tool with one parameter and no output schema, the description covers the return summary and directs users for full details. It does not mention error handling or when a node might not be found, but given the tool's simplicity and annotations, 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 coverage is 100%, with the 'id' parameter fully described including examples. The tool description adds little beyond the schema, only confirming that the ID refers to a node. Since the schema handles parameter semantics, 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 clearly states 'Get a specific compliance node by its ID' with a specific verb and resource. It distinguishes from sibling tools like search_nodes by emphasizing 'specific node' and 'by ID', 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?

The context is implied: use this when you have a node ID and want a summary. However, no explicit alternatives or exclusions are provided, such as directing users to search_nodes for finding IDs or browse_topics for exploration. The 'by its ID' gives some hint but lacks explicit comparison.

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?

The annotations already indicate readOnlyHint and openWorldHint, but the description goes beyond by disclosing that sealed runs are publicly readable by id and that the tool reports signature validity. This adds important behavioral context regarding access control and output details, which is valuable beyond the structured annotations.

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-loaded with the main action and includes necessary access and behavior details. Every sentence contributes to understanding the tool's purpose and usage without redundancy or 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?

Given no output schema, the description tells the agent what to expect (run and entries) and even mentions signature validity reporting, which is a key part of the return. It doesn't elaborate on structure or error cases, but for a simple fetch operation with two parameters, this 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 coverage is 100%, so baseline is 3. The description adds meaning to the api_key parameter by explaining it's needed for owners to read open/sealed runs, while sealed runs are publicly readable without it. This clarifies the practical use of the parameter beyond the schema's simple 'required to read your own still-open run' 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 clearly states the tool's purpose: 'Fetch a run and its entries.' This uses a specific verb (fetch) and resource (run with entries), and distinguishes it from sibling tools like open_run and seal_run which are lifecycle operations. The additional detail about open/sealed runs and ownership further clarifies the scope.

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 gives clear context on when to use the tool and how to handle api_key for open vs sealed runs. It doesn't explicitly name alternatives or when not to use it, but the ownership and public/private distinctions provide enough guidance for an agent to decide when this tool is appropriate.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a read-only operation. The description adds context beyond annotations by specifying that it returns node counts, enumerates the scale (10,108 nodes, 39 pillars), and provides a preview of the domains (MITRE frameworks, Banking, AI Governance, etc.). No contradictions.

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-loaded with the primary action. The first sentence states the exact scope ('List all compliance pillars... with node counts'). The second sentence provides valuable context about the registry's size and content without verbose filler. No unnecessary repetitions.

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 no parameters and no output schema, the description sufficiently explains what the tool returns: a list of pillars with node counts. It also gives examples of pillar domains, helping the agent anticipate the response type. It stops short of describing the exact response structure (e.g., JSON fields), but for a simple listing tool, this is adequate.

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 doesn't need to explain parameter semantics, and the schema is fully covered (100% for an empty schema). The description adds context about the output (node counts) but doesn't modify parameter guidance.

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 uses a specific verb+resource: 'List all compliance pillars in the Bidda Sovereign Intelligence registry with node counts.' It clearly states the tool's purpose and differentiates from siblings by noting it's a discovery step ('Use this first') and by mentioning node counts. This distinguishes it from search_nodes, browse_topics, and get_mitre_mapping.

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 recommends using this tool first before searching: 'Use this first to discover available compliance domains before searching.' This provides clear contextual usage guidance, though it doesn't explicitly list when-not-to-use or alternative tool names.

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?

The description adds detail beyond the annotations by explaining what feeds the change feed (primary sources changed or node withdrawn), that results are mapped to obligation nodes, and that filtering by time, pillar, or nodes is supported. It also discloses the subscription requirement. While readOnlyHint is present, this additional context about inclusion criteria and mapping is valuable.

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 what the tool returns, the second gives a use case and authentication requirement. Every sentence earns its place, and key info is front-loaded in the opening phrase.

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 change-feed tool with no output schema, the description conveys the essential concept (what is fed, how it maps, how it can be filtered, auth requirement). It does not detail the exact response shape, but the high-level mapping description is sufficient for an agent to select and invoke the tool. Given the complexity, this is solidly 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?

The input schema already provides descriptions for all five parameters (100% coverage), so the description adds little beyond reinforcing filterability by time, pillar, or nodes. The mention of api_key mirrors the schema. No additional parameter semantics are introduced beyond what the schema 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?

The description explicitly identifies this as 'the obligation-level change feed' and explains what it maps ('primary sources whose content changed... mapped to the Bidda obligation nodes they affect'), which is specific and distinguishes it from sibling tools like get_latest_changes or watch_changes. The use-case phrasing 'what obligations changed since I last reviewed?' further clarifies its unique role.

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 a clear use case: 'Use it to answer "what obligations changed since I last reviewed?"' and states the required authentication ('Requires an active Bidda subscription: pass api_key'). It does not explicitly name alternatives or exclusions, but the obligation-level focus makes the intended context 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?

Annotations already indicate this is a non-read, non-destructive operation, and the description adds meaningful context: it returns a run_id, requires an active Bidda subscription, and describes the ledger as signed and tamper-evident. It does not fully describe side effects or lifecycle details, but is sufficient for the operation's simplicity.

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 that front-load the core purpose and workflow, with no filler. Every sentence contributes meaningful information: what the tool is, what it returns, and how to use it next.

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 is a straightforward creation operation with no output schema, the description adequately covers the return value (run_id) and workflow hints. It does not detail error conditions or edge cases, but this is acceptable for the tool's simplicity and the presence of rich 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?

Schema description coverage is 100%, so the parameters (agent, label, api_key) are fully documented in the schema. The description adds a hint about api_key ('pass api_key') but this is redundant with the schema. No extra parameter semantics beyond the structured fields.

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 opens a run ledger with a specific definition ('signed, tamper-evident log of what an agent does'), and it explicitly contrasts with record_run_entry and seal_run as part of the workflow. This effectively distinguishes it from sibling tools like get_run.

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 context for when to use the tool (starting a run ledger) and outlines the next steps ('Record one entry per turn with record_run_entry, then seal_run'), making the usage sequence clear. It also notes the subscription requirement, which is a concrete precondition.

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?

Adds value beyond annotations by disclosing the api_key requirement for open runs and the document's internal structure. readOnlyHint is consistent with 'Export'. No contradictions. It doesn't mention response format, but the description compensates with run-state specifics.

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, no fluff. The first sentence is information-dense but coherent; the second clarifies the api_key condition. Every phrase 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?

The tool has no output schema, so the description appropriately explains what the OSCAL document will contain (reviewed-controls, observations, props). It also addresses run state, which is key for usage. Missing minor details like exact serialization format, but overall complete for a straightforward export 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 already covers both parameters well (100% coverage), so baseline is 3. The description adds meaning by explaining that api_key is needed specifically for open runs, and that run_id refers to the run to export. This is a meaningful addition over the 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 clearly states the verb 'Export' and resource: 'a governed run's evidence as a NIST OSCAL assessment-results document'. It also enumerates specific content items (reviewed-controls, observations, props), making it distinct from sibling tools like get_run or seal_run.

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 clear context: this is for exporting to OSCAL for GRC/audit tooling. It gives a usage condition ('A sealed run is readable by id; a still-open run needs your api_key') but does not explicitly name alternative tools or say when not to use it. The context is sufficient for most use cases.

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?

The description adds useful context about the public history chain and the subscription requirement, which are not in the annotations. However, with readOnlyHint=false and the annotation title 'Sign a point-in-time record', the description does not clarify whether the call creates a signed record or merely fetches one. This ambiguity limits transparency, but there is no direct contradiction.

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 concise sentences: what the tool does, when to use it, and the required authentication. Every sentence earns its place 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?

The description covers purpose, usage, and auth, but lacks return-format details and does not address potential side effects or alternatives. With no output schema and openWorldHint=true, this leaves some ambiguity for the 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?

The schema already documents all three parameters (as_of, api_key, node_id) with 100% coverage. The description reinforces as_of as a past date and api_key as the subscription key, but adds little meaning beyond 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 uses a specific verb and resource: 'Get a signed record of which committed version of a rule was authoritative at a specific past date.' This clearly distinguishes it from siblings like get_latest_changes or get_node.

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 explicitly states when to use the tool: 'Useful when an agent must show what a rule said at the moment it acted.' It also notes the Bidda subscription/api_key prerequisite. However, it does not name alternatives or exclusion cases.

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?

Annotations already indicate it is a write operation (readOnlyHint false), non-destructive, and non-idempotent. The description adds valuable behavioral context: each entry is hash-chained to the previous one, providing an integrity guarantee. It also notes the subscription requirement. No contradiction with annotations.

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, about 40 words, with the main action front-loaded ('Append one entry to an open run'). Every sentence earns its place, covering purpose, content types, hash chaining, and the required API key. No redundancy or 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?

With 12 parameters fully documented in the schema and no output schema, the description covers the core purpose, prerequisites, and a key behavioral trait (hash chaining). It could have explicitly stated the position in the run lifecycle (after open_run, before seal_run), but the description is otherwise sufficient for an agent to understand the tool's role.

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 adds a slight clarification about note vs input_hash for user input, but the schema already describes each parameter in sufficient detail. The description does not meaningfully enrich parameter semantics beyond 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 opens with the specific verb+resource: 'Append one entry to an open run.' It then clarifies what constitutes an entry (rules consulted, decision, user input) and distinguishes between text and hashed input. This clearly differentiates it from sibling tools like open_run and seal_run.

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 states the prerequisite of an open run and the need for an active Bidda subscription with api_key. This gives clear context for when to use the tool, though it does not explicitly mention alternatives or when not to use it. The implication of using it between open_run and seal_run exists but is not stated.

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?

Annotations already provide idempotentHint, readOnlyHint, and destructiveHint. The description adds behavioral detail: produces a signed Run Receipt, returns the same receipt if already sealed, and requires an active Bidda subscription with api_key. This goes beyond the annotations without contradicting them.

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 concise sentences, each adding value: purpose, idempotency, and requirement. Front-loaded with the primary action and output. No redundant or filler content.

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 purpose, idempotency, and subscription requirement, which is strong for a 2-parameter tool. It mentions the public verify URL but does not specify the exact response structure or whether the run remains open after sealing. Overall, it is fairly complete but leaves a small gap in post-conditions.

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 run_id and api_key both meaningfully described. The description reinforces the api_key requirement but adds no new format or syntax details. Per the rubric, baseline 3 is appropriate when the schema carries the full explanatory weight.

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 exactly what the tool does: 'Seal an open run into one signed Run Receipt covering every entry, with a public verify URL.' The verb 'seal' and the resource 'open run' are specific, and the output (signed receipt) is described. This clearly distinguishes it from siblings like open_run, get_run, and 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 gives clear context: it is used for open runs, and note that sealing is idempotent. It implies the right time to use it (when a run is open and all entries are recorded) but does not explicitly exclude alternatives or compare to other tools. Since open_run and get_run are siblings, the guidance is clear enough, though not exhaustive.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's mention of return format (summaries with BLUF) and the no-hallucination, source-tracing guarantee adds meaningful behavioral context beyond the structured fields. It does not contradict annotations and provides useful reliability expectations.

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: three sentences that front-load the purpose, then describe the return value, and end with concrete examples. Every sentence adds value, with 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 that there is no output schema, the description compensates by explaining the return structure (summaries with BLUF) and the source-tracing guarantee. It covers the essential behavioral context for a search tool, including typical query examples. Minor gaps like match semantics or limit/pillar behavior are left to the schema.

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 does not add parameter-specific details beyond what the schema provides, though the example queries illustrate how to phrase the query parameter. This aligns with the baseline expectation.

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: 'Search Bidda compliance nodes by keyword.' It clearly distinguishes itself from sibling tools like browse_topics or consult_node by focusing on keyword search and output summaries. The BLUF sentence and example queries 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 clear context: use this to search nodes by keyword and get concise summaries with source links. However, it does not explicitly state when not to use it or contrast with alternatives like browse_topics or get_node. The examples imply typical use cases, giving adequate but not exhaustive 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?

Annotations already indicate readOnlyHint=false and idempotentHint=false, so the mutating and non-idempotent nature is known. The description adds valuable context beyond annotations: the requirement for a Bidda subscription, the email/webhook delivery channels, and the 'primary source changes' trigger. This gives the agent a clear behavioral model without contradicting annotations.

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 the core purpose, then a necessary prerequisite. Every word earns its place; no redundant phrasing or verbose explanation. The structure is highly scannable for an AI agent.

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 core functionality and the key prerequisite. The schema handles parameter details (including the required webhook_url when webhook is enabled). It does not describe return values, but for a create/subscribe operation, that is often a simple confirmation. The combination of description, schema, and annotations is sufficient for correct invocation for most use cases.

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 semantic meaning by explicitly mapping 'specific rules' to nodes and 'whole pillars' to pillars, and states 'email or webhook' which aligns with channels. It also clarifies that api_key is mandatory. This goes slightly beyond what the schema alone provides.

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 explicitly states 'Subscribe to regulatory change alerts' with specific actions: 'watch specific rules and/or whole pillars' and get notified via email/webhook. It clearly distinguishes from sibling tools like get_latest_changes by emphasizing ongoing subscription rather than a one-time query, and the title 'Create a regulatory change alert' confirms the mutating nature.

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 clear context on when to use: when the user wants to monitor regulatory changes and be notified. It also states a prerequisite ('Requires an active Bidda subscription: pass api_key'). However, it does not explicitly name alternatives (e.g., get_latest_changes for current changes) or state when not to use, so it lacks explicit exclusions.

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