Bidda Sovereign Intelligence

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

No annotations exist, so description carries full burden. It discloses that the tool is free and keyless (no auth required), describes the browse action as read-only by nature, and explains drilling into a specific topic. This is sufficient behavioral context for a simple query tool.

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 total, each earning its place: first states action and examples, second describes return value, third explains position relative to pillars and usage. No fluff, front-loaded with purpose.

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 and only one optional parameter, the description adequately explains return values (counts, pillars, jurisdictions), relationship to pillars, and authentication requirements. Minor gap: no mention of error handling or response format, but not critical for this 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 covers the one optional parameter 'topic' with description. Description adds semantic value by distinguishing browsing all topics (no parameter) from drilling into one (with topic string), which enhances agent understanding 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?

Description clearly states the tool browses the registry by compliance topic, provides concrete examples (data breach notification, AI transparency, AML and KYC), and specifies what it returns (counts across pillars and jurisdictions). The verb 'browse' is distinct from sibling tools like check, create, or compare.

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?

Description implies usage for browsing topics and mentions it is free and requires no key, but does not explicitly contrast with siblings or state when not to use this tool versus alternatives. Context about topics being on top of pillars helps but lacks direct 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, so the description must fully cover behavior. It discloses that the tool returns a ranked list of regulations with a risk indicator, but it does not mention side effects, authentication requirements, or rate limits. The description adds some transparency but is incomplete.

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 extraneous information. Key details (purpose, input format, output characteristics) are front-loaded, making it highly 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?

Despite no output schema, the description effectively communicates the return format (ranked list of regulations, risk indicator). With three parameters and clear context, the description is complete for an agent to select and invoke 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?

The schema has 100% description coverage for all three parameters. The description adds value by explaining that the 'action' parameter should be a natural-language description, with specific examples (e.g., 'process EU resident biometric data'), which aids understanding 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 performs a 'pre-flight regulatory check' and provides examples of natural language actions it handles. It distinguishes itself by being 'the primary tool for runtime compliance gating in autonomous agent workflows,' which sets it apart 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 explicitly says it is the primary tool for runtime compliance gating, implying when to use it. However, it does not mention when to avoid it or provide direct comparisons to siblings like get_crosswalk or search_nodes. The guidance is clear but lacks exclusions.

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

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

No annotations provided, so description carries full burden. It discloses that the tool does not rank strictness, surfaces real rules/numbers, and requires a subscription. Contradictions are absent.

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 front-load main purpose, include an example, and convey key requirement. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description adequately explains the return concept (side-by-side with thresholds). Lacks specifics on return format or scope of jurisdictions, but sufficient for a comparison 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 coverage is 100% with descriptions for both parameters. Description adds value by providing example for topic ('data breach notification') and clarifying that api_key is sent as x-bidda-api-key and that free trial counts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'compare' and resource 'jurisdictions addressing a compliance topic', with specific examples like 'breach-notification deadline'. It distinguishes from sibling tools like get_jurisdiction_bundle by focusing on side-by-side comparison and thresholds.

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 requires an active Bidda subscription and mentions passing api_key. Provides usage condition but does not explicitly state when not to use or mention alternative tools like get_crosswalk.

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 provides critical behavioral details: the record is signed and time-stamped, returns a record ID and public verify URL for integrity confirmation, and requires a subscription. 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?

Three well-structured sentences: purpose and output, utility, and requirement. 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 explains return values. It covers purpose, output, and requirement. Could mention parameter constraints like max 50 nodes, but schema already covers that.

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 covers all 5 parameters with descriptions (100% coverage). Description adds minimal extra context, such as the api_key requirement. 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 creates a signed, time-stamped record of Bidda rules used for a decision, distinguishing it from the sibling tools which are read-only (get, list, search) or check 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?

Describes utility for audit trails and mentions the requirement of an active Bidda subscription and api_key. Does not explicitly state when not to use or compare with siblings, but context is clear.

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

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

Without annotations, the description discloses the tool's read-only nature, scalability, and return of per-rule status. Missing details on rate limits or error conditions, but adequate.

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 front-loaded sentences covering purpose, usage, and pricing/scaling. 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?

Complete for a simple tool with 2 params and no output schema. Could mention optionality of hash more directly, but generally 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?

Adds meaning beyond schema by explaining the hash usage (optional) and API key context. Schema coverage is 100%, so baseline is 3; description provides extra context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if cached compliance rules are current using integrity hashes. It distinguishes from siblings like 'check_action_compliance' by focusing on cached rule integrity.

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 guidance on when to use (before acting on stale law) and mentions batch scaling, but does not explicitly exclude alternatives or specify when not to use.

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 fairly discloses that full mapping values are vault-gated (requires additional permissions) and distinguishes between discovery and full mapping output. However, it does not mention other behavioral aspects like rate limits, idempotency, or error handling.

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 remarkably concise (2 sentences), with no fluff. The purpose is front-loaded, and every sentence adds value: first defines the tool, second clarifies limitations.

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 provides a solid overview of what to expect (list of dimensions, with examples) and mentions access gating. However, it does not specify the exact output format (e.g., JSON structure) or behavior when no crosswalks exist. It is sufficiently complete for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter node_id is described in the schema as 'Node ID to inspect crosswalks for.' The description adds context that the node is a rule and the mapping is cross-framework, which enriches understanding beyond the schema's minimal description. Schema coverage is 100% so baseline is 3, and the extra context justifies a 4.

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 returns cross-framework mapping dimensions for a node, with concrete examples (GDPR Article 17 → CCPA right-to-delete → POPIA Section 24). It also distinguishes between discovery and full mapping (vault-gated), which differentiates it from sibling tools like get_mitre_mapping or 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?

While the description implies using it to inspect crosswalk dimensions for a node, it lacks explicit guidance on when to use this tool versus alternatives like get_mitre_mapping or check_action_compliance. No ‘when to use’ or ‘when not to use’ statements 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, but the description discloses key behaviors: it walks the chain, returns a tree, defaults to depth 2, max depth 4. Lacks mention of side effects or auth, but is sufficiently informative for a read-like operation.

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 efficient sentences, front-loaded with the core verb and object, 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?

No output schema, but return value is described (full dependency tree). Siblings are listed but not compared. Overall 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?

Schema coverage is 100% with descriptions, and the added context (full dependency tree, typical depth) enhances 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?

Description clearly states it walks the prerequisite chain and returns the dependency tree, effectively distinguishing it from siblings like check_action_compliance or get_node by framing the purpose for compliance planning.

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 the tool ('Use this to plan a complete compliance posture') and provides typical depth expectations (3-8 upstream nodes). Lacks explicit when-not or alternatives, but 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?

No annotations provided, so the description must fully disclose behavior. It claims to 'Return all compliance nodes' but includes a limit parameter, creating ambiguity about completeness. It does not mention pagination, ordering, or what a 'compliance node' is, leaving significant 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?

Two sentences, no filler. The purpose and usage context are front-loaded. Every sentence 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 description lacks explanation of 'compliance nodes' and the implications of the limit parameter (e.g., capping results). With no output schema, the description should clarify the expected output. This is insufficient for a tool intended for entering new markets.

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. The description adds marginal value by listing jurisdiction examples (already in schema) but does not clarify the limit behavior or default beyond what schema states. 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 it returns compliance nodes for a specific jurisdiction, with examples. The verb 'Return' and resource 'compliance nodes' are specific, but it doesn't differentiate from siblings like search_nodes or get_node, which might also return nodes for a jurisdiction.

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 says 'Use when an agent enters a new market and needs the full regulatory surface for that geography.' This provides clear context, though it doesn't mention when not to use it or alternative tools like get_node for single node retrieval.

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 indicates a read-only polling operation ('list', 'call on a schedule'), which implies safety, but it omits details like pagination, rate limits, or behavior when no changes exist.

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 waste: the first defines the tool concisely, the second gives actionable usage advice. Each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple polling tool with two optional params and no output schema, the description covers purpose, usage pattern, and filtering. It could briefly mention the response is a list of nodes, but the name and description suffice.

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 schema already describes the parameters. The description adds 'Filter by pillar' but no additional meaning for 'days' beyond what the schema provides (default 30, max 180).

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 'list', the resource ('recently updated compliance nodes'), and frames it as a 'regulatory change feed', which is specific and distinguishes it from siblings like 'search_nodes' 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 explicitly advises agents to call this on a schedule for monitoring, and mentions filtering by pillar. However, it does not explain when to use this over the sibling 'watch_changes' or provide exclusion criteria.

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 states the tool returns 'Bidda node' + compliance obligations, but it does not mention read-only nature, authorization requirements, rate limits, or potential error cases. This is adequate but lacks depth for a tool that likely involves external data.

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 (two main sentences plus a short closing), with key information front-loaded via the metaphor. It lists supported frameworks and compliance standards efficiently. The 'Free.' is unnecessary but harmless.

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 tool's input (technique ID from multiple frameworks) and output (Bidda node + compliance obligations). Without an output schema, it provides a high-level but sufficient account. It omits return structure details, but the list of compliance standards gives agents a clear expectation.

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%, and the schema already provides detailed examples for the technique_id parameter. The description adds context about the returned compliance standards and the Bidda node, but does not clarify input format beyond the schema. Thus, the description adds only marginal value over 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 defines the tool as a mapper from MITRE technique IDs (across 5 frameworks) to compliance obligations (9 standards). The metaphor 'MITRE Rosetta Stone' effectively conveys its cross-domain purpose, distinguishing it from siblings like get_crosswalk 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 explains when to use it: as a bridge between SOC and compliance teams. It implicitly indicates not to use it for other mappings (e.g., cross-framework mappings might belong to get_crosswalk). However, it does not explicitly state alternatives or when to avoid this 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?

No annotations provided, so the description carries the full burden. It states the tool returns a summary and that the full node is available externally, which implies it is not a write operation. However, it lacks details on authentication, rate limits, or idempotency.

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 filler, front-loaded with the core action and results. Efficiently communicates purpose and extra 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 simple get by ID tool with one parameter and no output schema, the description adequately covers what the tool does and what it returns. It mentions where to find additional data, which is helpful 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 coverage is 100% and already describes the id parameter with examples. The description adds value by specifying that it retrieves a node by ID and listing the returned fields (summary contents), which goes beyond the schema's parameter 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 verb (Get), the resource (compliance node by ID), and the content of the return (summary with title, pillar, version, etc.). It distinguishes from siblings by specifying single-node retrieval by ID.

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?

No explicit guidance on when to use this tool versus list_pillars or search_nodes. It does not mention alternatives or conditions for use.

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 discloses key behaviors: the owner can read open/sealed runs with api_key, sealed runs are publicly readable, and the response reports signature validity for sealed runs. It doesn't cover error cases, but the mutation and access patterns are clear.

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 sentence states the core purpose, second adds critical behavioral details (access rules and output). No fluff, and 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?

Given no output schema, the description mentions entries and signature validity, which covers key output aspects. It is sufficient for a simple fetch tool, though more detail on return format would be beneficial.

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 api_key by specifying 'your Bidda key, required to read your own still-open run,' which clarifies the parameter's purpose 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 'Fetch a run and its entries.' which is a specific verb+resource combination. It distinguishes itself from sibling tools like open_run, seal_run, and record_run_entry by focusing on reading, not writing or starting runs.

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 api_key (to read an open run) and when it's unnecessary (for sealed runs, which are publicly readable). However, it does not explicitly mention alternatives or when to use other 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?

With no annotations, the description bears full burden but only adds scale details (10,040 nodes, 39 pillars). It lacks info on auth, rate limits, or side effects, but the operation is inherently safe and simple.

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 core purpose, then usage guidance and illustrative 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?

No output schema exists, so description must cover return format. It mentions 'node counts' and gives examples, providing a good mental model. Slight gap in explicit structure, but sufficient for a simple list.

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 has zero parameters, so schema coverage is 100%. Baseline is 4 per guidelines; description adds no param info but none is needed.

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 all compliance pillars with node counts, using specific verb (list) and resource (pillars). It distinguishes from siblings like search_nodes or browse_topics by focusing on discovering domains.

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 says 'Use this first to discover available compliance domains before searching', providing clear context. While it doesn't exclude alternatives, the guidance is strong and actionable.

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

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

With no annotations provided, the description carries the full burden. It mentions the tamper-evident nature, return of run_id, and api_key requirement, but misses details like idempotency or potential limits. This is adequate but not exhaustive.

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 concise sentences, front-loaded with the purpose. Each sentence adds value: definition, workflow, and requirement. 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?

Given the tool's simplicity and full schema coverage, the description covers the key aspects: purpose, workflow, and authentication. It could mention error handling or output format details, but overall it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra context beyond the schema (e.g., examples for label), but doesn't significantly deepen understanding of the 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 defines the tool as opening a run ledger, a signed tamper-evident log, and distinguishes it from siblings like record_run_entry and seal_run by positioning it as the first step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a workflow: open the run, record entries with record_run_entry, then seal_run. It also mentions the prerequisite of a Bidda subscription and api_key, though it doesn't explicitly state when not to use this 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?

No annotations exist, so the description carries the full burden. It discloses the signed record, anchoring to history chain, and subscription requirement. It does not detail side effects, but for a read operation the transparency is adequate.

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 with no waste. The core purpose is front-loaded, followed by usage guidance and a prerequisite. Every sentence 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 description explains what the tool returns (signed record) but lacks details about the format or contents of the output. Given no output schema, completeness is moderate but could be improved with output specifics.

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 minimal value beyond the schema: it mentions as_of defaults to now, node_id is the rule, and api_key is for subscription. This is sufficient but not above 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 it gets a signed record of the authoritative rule version at a past date, anchored to a public history chain. This verb+resource combination is specific and distinguishes it from siblings like browse_topics or check_action_compliance, which deal with other aspects.

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 a clear use case. It also requires an active subscription and api_key, but does not discuss when not to use or compare to 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 bears full responsibility. It discloses that entries are hash-chained and require an active subscription. However, it does not mention any error conditions, idempotency, or the fact that entries are immutable (implied by hash-chain but not explicit). Some behavioral aspects like rate limits or return value characteristics are omitted.

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 fluff. The first sentence captures the core purpose and content, and the second adds critical context (hash-chain and subscription). Every word is necessary and the structure 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?

The description explains the purpose and constraints but does not cover the return value (since no output schema) or explicitly state that run_id must come from open_run (though referenced in schema). For a tool with 9 parameters and no output schema, a bit more context about the workflow (e.g., that the run must be open) would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by grouping parameters into a narrative about what an entry contains, but it does not provide additional semantics beyond the schema for individual parameters. A score of 3 is appropriate as the description complements the schema without significant redundancy.

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 'entry to an open run'. It specifies the content of the entry: 'which Bidda rules the agent consulted, what it decided, and the end user's input'. This distinguishes it from sibling tools like open_run, seal_run, and get_run which serve different purposes.

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 that a Bidda subscription and api_key are required, and mentions hash-chaining. While it does not explicitly list when to use this tool vs alternatives, the context is clear given the sibling names. It lacks an explicit 'use when' or 'do not use when' statement, but the usage context is adequately 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?

With no annotations, the description carries the full burden. It discloses idempotency, return value, and authentication needs. It could mention state changes or error conditions, but is mostly 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?

Two sentences: first states purpose and output, second adds idempotency and requirement. No wasted words, front-loaded with key 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?

Given no output schema, the description explains the return value (signed Run Receipt with verify URL). It covers purpose, idempotency, and auth. Could mention required run state, but overall adequate for a simple 2-parameter 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 coverage is 100%, so baseline is 3. The description adds context for api_key (subscription info) but nothing beyond schema for run_id. Overall, it adds some value but not substantial.

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 'seal' and resource 'open run', and specifies the output: 'one signed Run Receipt covering every entry, with a public verify URL'. This distinguishes it from siblings like open_run, record_run_entry, and 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?

The description includes idempotency behavior and a subscription requirement, providing useful context. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.

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 describes output quality (no hallucination, legal trace) but does not explicitly state read-only nature, rate limits, or authentication needs. It is adequate but not exhaustive.

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?

Extremely concise: two sentences plus a list of examples. Every sentence adds value. Front-loaded with purpose and key output characteristics.

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 sufficiently explains what is returned (summaries with BLUF, legal sources). It also adds trust context (no hallucination). However, it omits details like pagination or error handling.

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 new semantic meaning beyond the schema's own parameter descriptions and examples. The examples in the description are similar to those 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 it searches compliance nodes by keyword and explicitly describes the return value (summaries with BLUF, tracing to legal sources). The examples differentiate it from siblings like browse_topics 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?

No explicit guidance on when to use this tool vs alternatives. While it's clear for keyword search, there is no mention of when not to use it or comparison to sibling tools like browse_topics or get_crosswalk.

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

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

With no annotations, the description carries the full burden. It states it is a subscription mechanism that notifies on changes, which is helpful, but does not disclose how to cancel, if updates are possible, or any rate limits or destructive behavior.

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 clear purpose and prerequisite. No fluff, front-loaded with the action.

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 main action and a requirement, but with 6 parameters and no output schema, it lacks explanation of return values (e.g., subscription ID) or what happens on error, leaving uncertainty 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?

Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema for parameters like label, nodes, pillars, channels, or webhook_url.

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 subscribes to regulatory change alerts and watches specific rules or whole pillars. It is distinct from sibling tools like get_latest_changes which is for one-time checks, though it does not explicitly differentiate from 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 mentions requiring an active Bidda subscription and passing an api_key, but provides no guidance on when to use this tool versus alternatives such as get_latest_changes or search_nodes.

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