Drone Intelligence

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

No annotations are provided, so the description carries the burden. It indicates the operation returns a comparison (a read-like behavior) and specifies the input format (slug). However, it does not disclose any side effects, output structure, or data source details. Since this is a non-mutating retrieval tool, the minimal transparency is acceptable but not exceptional.

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, concise sentence that front-loads the tool's purpose and includes an example. No unnecessary words or overlapping with schema 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?

This is a simple tool with one parameter and no output schema. The description adequately communicates the tool's core function and input format. It does not explain what the comparison includes, but for a straightforward retrieval of a comparison by slug, it is sufficiently complete for an AI 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 already documents the 'slug' parameter with a clear description and an example. The tool description also provides an example (droneshield-vs-dedrone), adding marginal value but not going beyond the schema's coverage. With 100% schema description coverage, a baseline 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 states the tool performs a side-by-side company comparison, with the resource being companies and the mechanism being a slug. The title 'Get a company comparison' and the tool name 'compare_companies' reinforce the purpose. It clearly distinguishes from siblings like get_company_profile or get_briefing, which are not comparison-focused.

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 the tool is used when a side-by-side company comparison is needed, and the slug example shows how to specify the comparison pair. However, it does not explicitly state when to use this tool instead of alternatives, nor does it mention any exclusions or prerequisites.

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 that the tool returns the full text and lists the sections, which is useful. However, it does not mention error behavior, authentication requirements, or potential limitations (e.g., only for Drone Intelligence Signal Dossiers).

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?

A single, front-loaded sentence that efficiently communicates the tool's function and key output components without any waste. Every word 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?

For a simple retrieval tool with one parameter and no output schema, the description provides an adequate outline of what is returned (the sections). It lacks notes on errors or return format, but given the simplicity, this is acceptable.

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

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

Schema coverage is 100% and the schema already describes the slug parameter with an example. The description adds context by indicating the slug identifies a briefing and that the returned content includes specific sections, which helps an agent understand the parameter's role 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 that the tool returns the full text of a Drone Intelligence Signal Dossier briefing, identified by slug, and lists the sections included (executive summary, signals, assessment, sources). This specific verb+resource+scope distinguishes it from siblings like get_intelligence_page or get_company_profile.

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: when you need the full briefing content by slug. It does not explicitly state when not to use it or mention alternatives, but the specificity of the purpose provides clear context for an AI agent.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavior. It lists the profile contents but does not explicitly state that this is a read-only operation, nor does it describe error behavior or response format. This is insufficient for a tool without 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 a single, concise sentence that front-loads the core information and avoids redundancy. It efficiently communicates the tool's purpose and content without unnecessary 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 is simple (one required parameter, no output schema), and the description lists the key output components (positioning, facts, funding, contracts, products). However, it omits details about response format, error cases, or usage context, leaving some gaps for an agent to infer.

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

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

The input schema already fully describes the slug parameter with an example (droneshield). The description merely says 'by slug', which adds no new semantic information beyond the schema. Since schema coverage is 100%, 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 defines the tool as returning a company profile with specific content categories (positioning, sourced facts, funding, contracts, products). It identifies the input as a slug and scopes it to Drone Intelligence, which helps distinguish it from broader tools like get_intelligence_page or get_products.

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 offers no guidance on when to use this tool versus siblings such as compare_companies or get_briefing. It only mentions the slug parameter, which is a requirement, not a usage scenario, and no alternatives or exclusions 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It lists the content sections, giving some idea of the return structure, but does not explicitly state that the operation is read-only, discuss error handling, authentication, or any side effects. The 'get' verb in the title implies a safe read, but the description itself is minimal.

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, compact sentence that front-loads the resource type and then lists the included sections. Every word adds value with no 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?

The tool has only one parameter and no output schema, so the description is relatively complete for a simple retrieve-by-slug operation. However, with many sibling tools, it lacks differentiation guidance and does not explain the broader context of market intelligence pages or when the returned sections would be useful. It is adequate but not enriched.

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 for the single 'slug' parameter with a description and example. The description merely reiterates 'by slug' without adding syntax, format, or additional constraints, so it does not improve on 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 identifies the resource as 'a Drone Intelligence market intelligence page' retrieved 'by slug' and enumerates its contents (overview, sections, key players, outlook, sources). This clearly distinguishes it from sibling tools like get_company_profile or get_briefing, though the description itself is a noun phrase rather than a explicit verb phrase.

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 no guidance on when to use this tool versus alternatives like get_briefing or get_company_profile. No exclusions, prerequisites, or context are mentioned, leaving the agent to infer usage solely from the tool's name and sibling list.

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 burden of behavioral disclosure. It indicates that the output is 'machine-readable' and includes specific data fields, which is useful context. However, it does not disclose any side effects, permissions, or limitations, leaving some behavioral ambiguity.

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, concise sentence that front-loads the key information (commercial products, machine-readable, specific data fields). There is no unnecessary verbosity, and it is appropriately sized for the tool's simplicity.

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

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

For a tool with no parameters and no output schema, the description provides sufficient context about the returned content (prices, checkout URLs, licence terms). It could be more explicit about the action (e.g., 'returns' or 'retrieves') and output format, but it is reasonably complete for a simple read-only 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 input schema has zero parameters, so there are no parameter semantics to clarify. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not need to compensate for missing schema details.

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

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

The description clearly identifies the resource (commercial products) and the scope of returned data (prices, checkout URLs, licence terms). The verb 'get' is implied by the tool name rather than stated explicitly, and it does not distinguish itself from the sibling tool 'list_catalogue', but the scope is specific enough to be useful.

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 (retrieving product information) but provides no explicit guidance on when to choose this tool over siblings like 'list_catalogue' or 'get_intelligence_page'. There is no mention of alternatives or exclusions, so it is minimally adequate.

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 pagination (50 per page), filtering by type, and that the result is slugs. However, it does not describe the exact return shape (e.g., array of strings, object with metadata) or behavior for out-of-range pages, which is a notable gap.

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?

A single, focused sentence that immediately conveys the core purpose, filter options, and pagination. Zero wasted words; the structure is clean and 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?

For a straightforward list tool with two parameters and no output schema, the description covers the essential behavior but omits the return format and pagination semantics beyond page size. Given the sibling tools, it is enough to distinguish purposes but not fully self-contained.

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 explicitly lists the enum values for type and adds the page size (50 per page), which is helpful. However, it does not name the 'page' parameter or explain its default/minimum, leaving some burden on 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 states it returns paginated slugs filtered by content type, which clearly distinguishes it from sibling content-fetching tools like get_briefing or get_products. It uses a noun phrase rather than an explicit verb, but the tool name 'list_catalogue' makes the action clear.

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 alternatives. It does not mention that it should be used to discover slugs before fetching specific content, nor does it exclude any use cases. The intended usage is only implied by the word 'slugs'.

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

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

With no annotations, the description carries the transparency burden. It discloses the result limit (up to 10 matches) and the return fields (title, type, URL, excerpt), which is useful behavioral information. It does not state explicit read-only behavior, but the search action and return data imply it.

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 action and scope, and includes essential return details without any filler. 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 one-parameter search tool with no output schema, the description covers the content types searched and the result format, which is enough for an agent to select and invoke it. It omits advanced details like pagination or sorting, but those aren't critical for core use.

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 provides a full description for the only parameter 'query' (including an example), covering 100% of the semantics. The description does not add extra parameter guidance, 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 clearly states a specific action ('Search') and a specific resource ('Drone Intelligence briefings, market intelligence pages, company profiles and comparisons'), and distinguishes itself from sibling tools that retrieve individual items (e.g., get_briefing, get_company_profile) by emphasizing search across multiple content types.

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 when to use the tool (when you need to search across multiple content types), and its scope is clear. However, it does not explicitly mention alternatives or provide 'when not to use' guidance, though the sibling tool names suggest concrete 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?

No annotations are provided, so the description carries the behavioral transparency burden. It discloses a key requirement (licence token) and implies a read-only operation through the word "Counts." However, it does not describe the output format, potential pagination, or any other behavioral traits. The token requirement is useful, but the description is thin overall.

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 long, front-loaded with the core function and followed by the prerequisite. Every word earns its place, with no redundancy or filler. It is exceptionally concise while still conveying the essential purpose and a key constraint.

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

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

Given the simplicity of the tool (one enum parameter, no output schema), the description adequately explains what the tool does and the required token. It could go further by describing the returned counts' structure, but for a straightforward aggregation tool this is likely sufficient. The sibling tools imply a comparison context, but the description stands on its own.

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 a single parameter 'dimension' with an enum, but the schema itself provides no descriptive text (0% coverage). The description compensates by explicitly naming the grouping options ('theatre, layer, or awardee'), which directly clarifies the parameter's meaning. This adds value beyond the raw enum list.

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 the tool counts tracker awards grouped by theatre, layer, or awardee. The verb "Counts" and the specified grouping dimensions make the purpose specific and distinguishable from the sibling tracker_awards tool, which likely lists raw awards. However, it does not explicitly name an alternative tool or contrast with siblings.

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 no guidance on when to use this tool versus alternatives such as tracker_awards, compare_companies, or search_content. It only mentions a licence token requirement, which is a prerequisite rather than a use-case guideline. There are no explicit or implicit instructions on appropriate scenarios or 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 are provided, so the description carries the full behavioral disclosure burden. It discloses an access requirement ('Requires a tracker licence token') and the dataset scope ('76 sourced'), but it does not describe pagination, how filters combine, or the return format. 'Query' implies read-only operation, but this is implicit rather than explicit.

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 exactly two sentences: the first states the core purpose and scope, the second covers filters and the licence requirement. Every word earns its place, with no 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?

The tool is simple: three optional string parameters, no nested objects, no output schema. The description covers the resource, filters, and licence prerequisite, which suffices for basic invocation. However, because the output schema is absent, the agent still lacks clarity about the return shape, so a small deduction is made.

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% because all three parameters have detailed descriptions with substring examples. The tool description echoes the filter dimensions (theatre, kill-chain layer, awardee substring) but adds no new semantics beyond what the schema already provides. With high schema coverage, the baseline 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 opens with a specific verb 'Query' and a concrete resource: 'the 76 sourced counter-UAS awards.' It clearly states the tool's function and distinguishes it from sibling tracker tools by identifying a unique dataset. The listing of filter dimensions adds further clarity about its 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 provides clear context (querying a specific awards dataset) and enumerates the filter dimensions available. However, it does not explicitly contrast the tool with sibling tools like tracker_aggregate or tracker_capital_ledger, nor does it state when to prefer this tool over alternatives. Usage guidance is therefore implied rather than explicit.

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 present, so the description carries the full burden. It only discloses the token requirement, but fails to mention side effects, return format, or whether the operation is read-only. This is minimal and insufficient.

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 extremely concise, with two short sentences, no redundant phrasing, and the key information (what it is and the token requirement) front-loaded. 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?

With no output schema, the description should clarify what the tool returns, but it only describes the ledger's subject matter. It is adequate for a vaguely defined data source but leaves gaps about return type or content granularity.

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. There is nothing for the description to add beyond what is already vacuously covered by 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 identifies a specific resource—the capital and acquisition ledger for counter-UAS vendors—but lacks a clear verb indicating the action (e.g., 'lists', 'retrieves'). It adds context beyond the title but remains vague about what the tool actually does.

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 sibling tools. The only usage-related note is the licensing requirement, which is a prerequisite rather than a context for selection.

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 disclose behavior. It mentions the licence token requirement, but it doesn't explicitly characterize the operation as read-only or describe the response format. The metadata framing implies no side effects.

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?

One concise sentence packs the tool's purpose and the key prerequisite without redundancy.

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

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

Despite having no output schema, the description lists the metadata components and the auth requirement, providing adequate expectation-setting for a simple schema retrieval tool. It could mention that the response is a schema 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 accepts no parameters, so the baseline is 4. The description adds no parameter-specific information, which is appropriate given the empty 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 specifically names the 'paid Counter-UAS Tracker dataset' and enumerates its contents ('fields, theatres, layers, counts, data-through date, licence'), clearly distinguishing it from sibling data-query tools like tracker_aggregate and tracker_awards.

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 understanding dataset metadata but doesn't explicitly state when to use it versus sibling tools. It provides a prerequisite ('Requires a tracker licence token') but no guidance on alternatives or conditions.

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 transparency burden. It discloses a key behavioral requirement (license token) and implies a read-only query, but it does not specify return format, pagination, error behavior, or whether any side effects exist. It adds some context but not a full behavioral profile.

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, and every sentence adds value. The structure is efficient and free of redundant wording.

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 a simple query with two optional string parameters and no output schema, so the description covers the essential context: what it queries, how to narrow results, and an authentication requirement. It lacks details like return shape or result limits, but for this complexity level it is reasonably 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 schema already documents both parameters with substring-match examples. The tool description adds only that these filters relate to 'layer' and 'US-procurement eligibility', which is a minor semantic clarification but does not significantly go 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 ('Query') and a concrete resource ('the 45-vendor counter-UAS competitive matrix'), clearly distinguishing it from sibling tools like get_company_profile or compare_companies. It also scopes the tool precisely with the vendor count and domain.

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 clear context on what the tool does and what filters are available ('Filter by layer or US-procurement eligibility'), and mentions a prerequisite ('Requires a tracker licence token'). However, it does not explicitly state when to use this tool over alternatives, nor does it mention exclusion scenarios.

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