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

No annotations are provided, so the description carries the burden. It discloses the time window, sorting, and sources, but omits potential behaviors like pagination, rate limits, or what happens when no tenders are found.

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 with no fluff. It conveys all essential information efficiently.

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

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

For a simple list tool with optional parameters and no output schema, the description covers the core behavior but does not describe the return format or edge cases. It is adequate but not comprehensive.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no extra semantic detail about the parameters, just restates the tool's overall function.

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 (Get), a specific resource (latest government tenders), and unusual context (24-48 hours, from CanadaBuys and SAM.gov). This distinguishes it from sibling tools like search_tenders and match_tenders.

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 implies when to use (when you want very recent tenders), but does not explicitly state 'when not to use' or contrast with alternatives. The clear time window provides context, but no exclusions are given.

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 discloses the nature of the output (counts, industries, countries) but does not explicitly state that the operation is read-only or describe any limitations like data freshness or access needs. It is enough to understand the behavior, but not richly detailed.

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 and immediately states the tool's purpose and data contents. It avoids any fluff or repetition, earning a top score for being concise and well-structured.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is complete. It covers what the tool returns (statistics), the scope (Canada + US), and when to use it (before searching). There are no missing details necessary for an agent to select and invoke it correctly.

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

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

The tool takes zero parameters, so there is no parameter semantics to clarify. The rubric assigns a baseline of 4 in this case, and the description appropriately focuses on the output rather than 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 starts with a specific verb and resource: 'Get current government tender statistics' and enumerates concrete data points (active tender count, covered industries, available countries). This clearly differentiates it from sibling tools like search_tenders and match_tenders, which focus on finding or matching tenders rather than summarizing dataset availability.

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 tells the agent when to use this tool: 'Use this to check what data is available before searching.' This provides a clear workflow context, though it does not name alternative tools or describe when not to use it, so it falls short of full 5 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 must carry the transparency burden. It discloses use of Claude Haiku AI, relevance scoring, and the scope of 11,000+ tenders. However, it does not mention edge-case behavior (e.g., zero matches) or output formatting, so it provides moderate but incomplete 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 three concise sentences, front-loaded with the primary purpose ('AI-powered semantic matching'), followed by usage guidance and a technical detail. Every sentence adds value, with no redundant or extraneous content.

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

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

Given a simple 3-parameter schema with complete descriptions, no annotations, and no output schema, the description adequately conveys the input requirements and general nature of the output ('ranked tender matches scored by relevance'). It could specify output structure more explicitly, but it is sufficient for basic invocation and understanding.

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%, covering limit, country, and description. The description adds no parameter-specific details beyond the schema; it only reinforces that description should be a business profile, which is already in the schema. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool's function: 'AI-powered semantic matching' leading to 'ranked tender matches scored by relevance'. This distinguishes it from sibling tools like search_tenders (likely keyword-based) and get_latest_tenders, by emphasizing semantic matching based on business description.

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 instructs users to 'Describe your business, capabilities, or expertise' to get matches, providing clear input guidance. However, it does not explicitly compare this tool with sibling tools or state when to prefer it over alternatives, leaving usage context 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?

With no annotations, the description bears the full burden of behavioral disclosure. It adds useful context about data sources (CanadaBuys and SAM.gov) and scale (11,000+ opportunities, 45 industries), which goes beyond the name. However, it does not disclose behaviors like pagination, ordering, parameter combination logic, or read-only safety. The description gives some context but leaves important behavioral aspects undisclosed.

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

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

The description is concise and front-loaded. The first sentence states the core purpose, followed by two sentences that add source and coverage context, and a final sentence with practical keyword examples. Every sentence serves a purpose; no redundant content. The keyword list is a bit lengthy but valuable for an agent to know typical industry terms. Structurally excellent.

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

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

For a search tool with 6 optional parameters and no output schema, the description provides essential context: sources, coverage, and filter examples. However, it omits important details like how multiple filters interact (AND/OR), result ordering, default behavior when no filters are provided, and what fields are returned. Given no output schema, more completeness would be beneficial, so this is adequate but not thorough.

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

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

Schema description coverage is 100%, so each parameter already has a description. The tool description adds examples of industry keywords and mentions value ranges, which aligns with the min_value/max_value parameters. However, it does not meaningfully enhance understanding beyond the schema — it reiterates the filter dimensions without adding new semantic details like how values combine. Baseline 3 is appropriate given full 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 function: 'Search government tenders by industry, region, country, or value range.' This specifies a concrete verb and resource (government tenders) and outlines the key filtering dimensions. It also distinguishes from sibling tools (get_tender_stats, get_latest_tenders, match_tenders) by emphasizing search/filtering rather than statistics, recency, or matching.

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 through 'Search government tenders by...' but does not explicitly state when to choose this tool over siblings or provide exclusions/alternatives. It doesn't mention 'use get_latest_tenders for recent tenders' or 'use match_tenders for similarity matching'. The guidance is implied rather than explicit, so it's clear enough for basic use but lacks direct comparative direction.

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