Awardia

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely new context: it is free during beta, Portugal coverage is exhaustive (including small direct awards), and it returns summary stats, top winners and recent awards. It lacks rate/latency or per-country coverage caveats, but it adds real value beyond the annotations.

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

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

Three dense sentences with no filler, each carrying distinct information (cost, capability, filters, coverage, output). The leading 'Free during beta' is slightly odd as the very first token but is short and front-loads a material 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?

With no output schema, the description usefully sketches the return shape (summary stats, top winners, recent awards), which the agent otherwise could not know. It also signals coverage asymmetry (Portugal exhaustive vs. other countries unstated), making it largely sufficient for a zero-required-parameter search tool, though multi-country behavior is left ambiguous.

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 schema already documents buyer, winner, cpv_prefixes, region, countries, since and limit. The description restates four of those filter axes (buyer, winner, CPV sector, region) without adding syntax or matching-behavior detail beyond the schema, so it neither helps nor harms.

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 a precise verb+resource: past awarded public contracts, including winner, price, bidder count, and award procedure. The 'past/awarded' framing implicitly separates it from sibling tools such as search_tenders (open tenders) and expiring_contracts, so an agent can route correctly without opening a schema.

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 communicates when the tool applies via coverage and filtering context ('For Portugal covers every public contract (Portal BASE), incl. small direct awards') and lists the filter axes (buyer, winner, CPV sector, region). However it names no explicit alternative tool or when-not condition, so guidance stops short of full routing clarity.

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

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

Beyond readOnlyHint/openWorldHint, the description discloses the fallback comparison logic (same buyer+sector, else same kind of work nearby/district), that it reports sample size, that it does not read tender documents, and even a pricing note ('Free during beta'). These are behavioral traits the annotations cannot convey.

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 core decision is front-loaded in the first two sentences, and the long enumeration of outputs is dense but each item is informative. It is slightly list-heavy, but there is little filler and the structure (purpose, modes, outputs, scope limits) is logical.

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 carries the return-value burden and does so by enumerating the analysis dimensions it returns. With all four params optional, it clearly explains the two alternative ways to invoke it, so an agent has everything needed to call 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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: it explains the mutual exclusivity of tender_id vs. buyer+cpv and the provenance of tender_id. It says nothing about the country parameter's role, so it does not fully earn a 5.

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

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

The description opens with the exact decision it supports ('Should I bid, and at what price?') and then enumerates the concrete analysis outputs (bidder counts, single-bid share, price range, incumbents, win rates). This clearly separates it from siblings like award_history and competitor_profile, which are raw lookups rather than bid/no-bid analysis.

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

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

It states the two valid invocation modes – a tender_id (explicitly sourced from search_tenders/match_company) or a buyer+sector pair – so the agent knows exactly how to trigger it. It also draws a scope boundary ('Does not read the tender documents'). It stops short of an explicit 'use X instead when...' exclusion, so it is a strong 4 rather than a 5.

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

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

Annotations only assert readOnlyHint and openWorldHint=false; the description adds real behavioral context beyond that: 'Free during beta' (cost), the closed public-records provenance, the geographic caveat that Portugal yields materially richer data (entered contests, win rate, rivals, losses), and the constraint 'report facts, not conclusions about wrongdoing'. It does not mention pagination or result-size limits.

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?

No output schema exists, so the return-field enumeration earns its place, but it is delivered as one very long semicolon-chained sentence and the leading 'Free during beta' front-loads pricing instead of purpose. Dense and waste-free, yet poorly structured for scanning.

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 correctly carries the burden of describing returns and does so exhaustively, including the Portugal-only extras. Safety is already covered by readOnlyHint. Minor gaps remain: no default time range, no pagination/result-size behavior, and ambiguity between the 'countries' input filter and the countries listed as outputs.

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 company, since, and countries, so a baseline 3 applies. The description reinforces the company parameter by naming the NIF alias and notes country-level outputs, but adds nothing about the 'since' cutoff or the default time window, and its use of 'countries' for outputs blurs it with the input filter.

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 opening clause 'What a company wins in public procurement' states the resource and scope precisely, and the following enumeration makes clear this is a retrospective awards/competition profile. It never explicitly contrasts itself with siblings like award_history or bid_intelligence, so an agent must infer the boundary. Clear purpose, but no sibling differentiation.

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?

'Search by name or tax id (NIF)' tells the agent how to invoke it, and the content implies the when (profiling a company's public-procurement footprint). There is no explicit when-to-use/when-not guidance and no routing to siblings such as award_history for raw award lists. Usage is implied rather than stated.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false). The description adds meaningful context beyond that: the 'free during beta' cost signal, the inference logic (term ending soon implies likely re-tender), and the returned fields, which is useful since there is no output schema.

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 tight sentences; the cost note is front-loaded and each sentence carries weight (purpose, framing, return contents). No filler 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?

With no output schema, the description usefully enumerates the returned fields (buyer, incumbent suppliers, value, dates), and high schema coverage plus zero required params means little else is needed. Pagination/limit behavior is not addressed, a minor gap.

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 86%, so the schema already documents essentially all parameters (region, months_ahead, cpv_prefixes, etc.) in detail. The description contributes no additional parameter meaning, so 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?

States a specific resource (public contracts whose term ends soon) and explains the purpose concretely as a pre-tender sales pipeline. It conceptually distinguishes itself from search_tenders by being 'before tenders are published', but never names a sibling, so differentiation relies on inference.

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 framing as 'a sales pipeline before tenders are published' implies when an agent should reach for it, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. search_tenders or award_history). Usage is only implied.

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

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

Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds real behavioral context beyond that: 'FREE' signals no credit/quota consumption, and the listed contents describe what the agent will get back from a no-parameter call.

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 compact fragments, front-loaded with the cost signal and the call-order instruction. Every clause earns its place; nothing is padded.

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 carries the burden of describing the response, and it does enumerate the returned fields (sources, countries, date range, counts). It stops short of describing the response shape or how the counts should guide subsequent tool selection.

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 the baseline of 4 applies; there are no parameter semantics to clarify and the description correctly spends no words on inputs.

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?

States a specific resource ('What data Awardia holds') and enumerates the coverage dimensions returned: sources, countries, date range, counts of open tenders and award notices. This clearly separates it from the search/profile siblings, though it never explicitly names an alternative.

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?

'Call this first.' is an explicit sequencing directive that tells the agent when to invoke this tool relative to the others. There is no statement of when-not to call it, but for a zero-cost discovery endpoint the routing guidance is 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?

Annotations declare readOnlyHint and openWorldHint=false, so safety is covered; the description adds real behavioral context beyond that: pricing/availability ('Free during beta') and result ordering ('best match first'). It stops short of stating rate limits or result-count behavior beyond what the schema's limit field already carries.

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 tight sentences with no filler. The commercial note ('Free during beta') is front-loaded ahead of the functional content, which is slightly less useful first, but overall 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?

For a 3-param read-only tool with no output schema, the description covers purpose, input shape, and return ordering. Given full schema coverage and annotations, only minor gaps remain (no explicit contrast with siblings).

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 loosely maps to company_description and countries ('what it sells, where') but adds no syntax, format, or recall guidance beyond what the schema descriptions already 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?

States a specific verb (match) and resource (company) and describes the output (open public tenders it could bid on). It is clear on its own, but never names or contrasts with siblings like search_tenders or award_history, leaving the agent to infer the distinction.

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 how to use it ('describe a company in plain words (what it sells, where)') but gives no explicit when-to-use versus alternatives such as search_tenders. Usage is inferable from the framing rather than stated.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds non-obvious behavior the annotations do not: the tool is free during beta, and its corpus is TED EU-wide plus all Portuguese national tenders of any value. It still omits pagination/ordering behavior and any rate or quota limits.

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 tight sentences with zero filler: pricing note, scope and sources, then return fields. The most decision-relevant constraint (open tenders only) 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?

With no output schema, the description usefully enumerates the returned fields and clarifies source coverage, which is what an agent needs to judge relevance. It falls just short of complete by not describing result ordering or how limit interacts with the max-25 cap.

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 explains every parameter, including keyword language handling and CPV prefix examples. The description only restates the facet list (keywords, country, region, CPV sector, value) without adding syntax or format guidance, so the baseline 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?

States a specific verb and resource ('Find OPEN public tenders') plus the exact scope constraint (deadline still in the future) and the two data sources (TED EU-wide, Diário da República for Portugal). An agent can distinguish this from award_history or expiring_contracts without opening any schema.

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 'OPEN tenders (deadline still in the future)' framing gives clear context for when this tool applies versus historical or contract-expiry siblings, and the source coverage tells the agent what geography it can serve. However, it never names an alternative tool or states an explicit when-not condition.

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