Compliance Registry

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

With no annotations, the description bears full burden and discloses the tool logs an intent, triggers a manual verification process, and does not immediately change verification status. This provides clear 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 relatively concise with three sentences, front-loading the primary action. The extra detail about the OAuth plan is slightly tangential but does not significantly detract from clarity.

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 purpose and behavioral flow, but lacks parameter details and does not mention error scenarios or expected output. Given no output schema and 4 parameters, it is minimally 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?

Schema description coverage is 0%, yet the description adds no information about the four parameters (firm_slug, claim_email, claimant_name, claimant_role). The schema titles provide minimal meaning, but the description fails to explain their purpose or usage.

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 'Record a firm's intent to claim its directory listing', providing a specific verb and resource. It distinguishes this tool from sibling tools like find_compliance_firm or get_firm_profile by focusing on the claiming action.

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 the current manual workflow and mentions a future OAuth flow, giving context on when to use the tool. However, it does not explicitly exclude alternative tools or provide guidance on 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, and the description fails to disclose behavioral traits such as whether the operation is read-only, any authentication requirements, or return value characteristics. The description focuses solely on parameter semantics, leaving the agent unaware of side effects or 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?

The description is reasonably concise but could be better structured. The parameter details are presented as a bullet list without clear indication of required vs optional. It is not overly verbose, but the lack of a summary or example makes it less 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?

The description does not explain the return format, which is important given no output schema. It also fails to mention that all parameters are optional or how the search behaves with no parameters. Additional context like result ordering, pagination, or error cases is missing.

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 description adds significant meaning beyond the input schema, which only provides types and defaults. It explains sub_vertical values ('environmental_compliance' | 'accessibility' or free-text), region matching (case-insensitive contains), capability keyword matching, and limit max results. This compensates for the 0% 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's purpose: 'Search the Compliance Registry for vetted compliance and regulatory firms.' It uses a specific verb (Search) and resource (Compliance Registry), and distinguishes this search tool from sibling tools like get_firm_profile or claim_listing.

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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The usage context is implied by the parameter descriptions, but no exclusions or prerequisites are 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?

With no annotations, the description carries the burden. It lists return fields (behavioral) but does not disclose side effects, authorization needs, or rate limits. Minimal 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 a single, well-structured sentence that front-loads the core purpose. It is concise, though the field list could be formatted more clearly.

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 retrieval tool, the description covers return fields but lacks parameter explanation and usage guidance. Given no output schema and low coverage, it is only moderately 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 0%: the description does not explain the 'slug' parameter, leaving the agent without guidance on what value to provide.

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 'Full dossier for a single firm in the Compliance Registry' and enumerates the fields returned, making the purpose explicit and distinguishable from sibling tools like find_compliance_firm.

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 guidance is provided on when to use this tool versus alternatives (e.g., using find_compliance_firm first to get the slug). The description only lists fields without usage context.

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 carry the behavioral disclosure burden. It lists the data elements returned (scope, deliverables, timeline, pricing, etc.) but doesn't mention side effects, authentication requirements, or data freshness. For a simple read operation this is adequate but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences. The first lists the key output components; the second provides the usage context. Every word is purposeful with no redundant 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?

The description enumerates the key fields returned (scope, deliverables, timeline, pricing bands, service-type slugs, profile URL) in the absence of an output schema. It is sufficiently complete for a tool that retrieves a known structured offering, though it could explicitly state the return format (e.g., JSON object).

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 no parameters, so the input schema is empty with 100% schema description coverage. Per guidelines, zero parameters yields a baseline of 4. The description does not need to add parameter-level information.

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

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

The description clearly identifies the tool as retrieving structured details about TESSA's WCAG 2.2 AA Accessibility Audit, including scope, deliverables, timeline, pricing, and associated slugs. It explicitly states the use case: when a buyer agent wants structured audit details. This distinguishes it from siblings like get_firm_profile which might provide general firm information.

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 usage directive: 'Use when a buyer agent wants accessibility audit details in structured form.' It implies the appropriate context but does not explicitly state when not to use or contrast with alternatives like get_firm_profile or find_compliance_firm.

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

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

With no annotations, the description carries full burden and discloses key behaviors: routing to listed firms, logging the lead, forwarding a warm intro email with TESSA Cc'd, and no calendar booking. It could mention whether the operation is idempotent or any rate limits, but provides solid context for a lead generation 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?

Description is four sentences, front-loaded with the action, and each sentence adds distinct value. No redundant or extraneous 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 description covers core functionality and one key parameter but lacks detail on return values (no output schema), synchronization model, or confirmation. For a tool with no output schema and 6 parameters, more completeness is needed.

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 0%, so description must compensate. It only explains target_firm_slug, leaving prospect_email, prospect_name, prospect_org, project_brief, and requested_window unexplained. This is insufficient for a tool with 6 parameters.

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

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

The description clearly states the tool requests a warm introduction to a Compliance Registry firm, specifies that target_firm_slug is required, and explains the routing and behavior (logs lead, forwards email with Cc). It distinguishes from siblings by focusing on introduction rather than listing or finding firms.

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 usage for requesting introductions to listed compliance firms and notes exclusions like 'not to TESSA directly' and 'no calendar booking.' However, it does not explicitly state when to use this tool versus alternatives like find_compliance_firm or request_quote.

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

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

No annotations are provided, and the description does not disclose any behavioral traits (e.g., side effects, authentication needs, rate limits). It only states the action and lists parameters, failing to inform the agent about what happens upon invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a front-loaded purpose clear line followed by a structured list of parameter explanations. No unnecessary words, but it omits critical context for completeness.

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 absence of annotations and output schema, the description is incomplete. It lacks usage context, behavioral details, and full parameter coverage. The tool likely requires more guidance (e.g., returns quote ID, sends email) that is missing.

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 0%, so the description must compensate. It provides brief explanations for 4 of 7 parameters (firm_slug, prospect_email, scope_summary, budget_band), including enum values for budget_band. However, three parameters (prospect_org, prospect_name, requested_window) are not mentioned, leaving gaps.

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: 'Request a quote from a Compliance Registry firm.' This is a specific verb+resource combination that distinguishes it implicitly from sibling tools like claim_listing or find_compliance_firm.

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 guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or context for using request_quote over request_introduction or other siblings.

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