Awardia

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower, and the description still adds real behavioral context: it is 'Free during beta', it discloses data completeness ('For Portugal covers every public contract (Portal BASE), incl. small direct awards'), and it previews the return shape (summary stats, top winners, recent awards). It does not mention rate limits or latency, but the coverage and cost disclosures are substantive.

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?

Four sentences, zero filler, and the substantive claim (who won past contracts, at what price, against how many bidders, by which procedure) is front-loaded ahead of the filter and coverage details. 'Free during beta' leads slightly awkwardly but earns its place as cost 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?

There is no output schema, so the description carries the burden of describing returns and does so at a useful summary level ('summary stats, top winners and recent awards'). Combined with the annotation-covered read-only profile and the coverage note, an agent has enough to invoke correctly; only the exact response fields and pagination remain unspecified.

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 seven parameters with formats and examples, making 3 the baseline. The description names four of the filters (buyer, winner, CPV sector, region) but adds no syntax or semantics beyond what the schema provides, and omits countries/since/limit entirely.

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+resource ('past public contracts', who won, at what price, how many bidders, which procedure) and enumerates the return content, so the agent knows exactly what this retrieves. It never names a sibling, but the 'past' framing implicitly separates it from forward-looking tools like search_tenders or expiring_contracts, so it falls just short of 5.

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?

Usage is only implied: the past-awards framing and the Portugal coverage note suggest when this is the right tool, but there is no explicit 'use this when...' statement, no exclusions, and no named alternative such as search_tenders or competitor_profile. 'Filter by buyer, winner, CPV sector and region' describes capability rather than when-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?

Annotations already declare readOnly/idempotent/closed-world, and the description adds real substance beyond them: it discloses the fallback broadening logic (same buyer+sector first, else same kind of work in the nearby district), that it reports its sample size, that it will not read tender documents, and that it is free during beta. The fallback-and-sample-size disclosure is exactly the kind of trait an agent could not infer from the 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?

Front-loaded with the decision question and the two input modes before the long output enumeration, which is the right order. The lead 'Free during beta.' is a commercial aside taking the highest-attention slot, and the output list is a dense run-on, but nearly every clause carries information an agent needs.

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 and all four parameters optional, the description carries the full burden and does: it spells out what the analysis returns, the fallback comparison scope, the sample-size disclosure, and the document-reading limitation. An agent can decide whether to call it and how to shape inputs without further information.

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; the description adds the grouping semantics that the schema does not: tender_id alone, versus the buyer + cpv + country alternative path, with tender_id accepting either an id or a pasted link. It does not explain the sector/country interaction further, so it lands above baseline rather than at the top.

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?

Opens with the exact decision it answers ('Should I bid, and at what price?') and a specific verb+resource: analysing comparable past contracts for a tender or buyer+sector. It enumerates the concrete outputs (bidder counts, single-bid share, winner discount to estimate, price range, incumbents, frequent bidders with win rates, direct-award rate, recent awards), so it is unmistakably distinct from siblings like award_history or competitor_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?

Explicitly states the two entry paths — an open tender_id (sourced from search_tenders/match_company or a pasted link) or a buyer+sector pair — which routes the agent to the right prerequisite tools. It also carves out a negative scope ('Does not read the tender documents'). Missing is an explicit statement of when to prefer a sibling tool (e.g. competitor_profile for pure competitor questions).

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, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious context: it is free during beta, coverage is country-dependent (Portugal gets entered contests, win rate, rivals, losses), and it instructs the agent to report facts rather than conclusions about wrongdoing — a real usage constraint beyond the structured fields.

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 opening "Free during beta" is a weak lead for a data-retrieval tool, and the middle is one very long run-on sentence packing a dozen output fields. The field inventory is useful given there is no output schema, but the wall-of-text structure hurts scannability and front-loading.

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 what is returned and flags the country-specific depth of Portuguese data, which is exactly what an agent needs to set expectations. It still omits ambiguity handling (multiple name matches), result limits/pagination and whether absence of data is possible, which are relevant for a 3-param search 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 description coverage is 100%, so company, since and countries are already documented in the schema (including the NIF example and the 'part is fine' hint). The description only restates name/tax-id search and does not explain the since or countries filters or how they interact, so it adds little beyond the schema 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 states a specific verb-like purpose (profiling what a company wins in public procurement) and enumerates the concrete data returned: contracts, value, buyers, sectors, discount below estimate, rivals, losses. It is clearly a per-company profile tool, though it never explicitly distinguishes itself from the sibling award_history or match_company, leaving the boundary to 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?

"Search by name or tax id (NIF)" gives a minimal how-to-invoke cue, and the profile framing implies it is the tool for company-level analysis. But there is no statement of when to prefer it over award_history, bid_intelligence or match_company, and no exclusions or prerequisites beyond the beta note.

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 cover the safety profile (readOnly, idempotent) and closed-world scope, so the description only needs to add context. It does: the exact returned fields (buyer, incumbent supplier(s), value, start and expected end date) and a cost note ('free during beta'), which matter since there is no output schema. It omits result ordering and pagination 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, zero waste: the first carries the concept and the commercial/positioning context, the second enumerates return fields compactly. Front-loaded with what the tool is before the payoff framing.

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 supplies the return contents; with only optional filters, there is little else an agent must know to call it. The gap on ordering/pagination is minor for a capped (max 50) read-only 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?

Schema description coverage is 100% across all 7 optional filters, so the schema already documents buyer, region, countries, min_value, cpv_prefixes, months_ahead and limit with examples. The description adds nothing parameter-specific beyond 'term ends soon' loosely mapping to the default 12-month window, 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 resource (public contracts whose term ends soon) with a clear framing — 'a sales pipeline before tenders are published' — that positions it as distinct from search_tenders (published tenders) and award_history (past awards). An agent can identify what it gets without opening the 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?

Implies the use case clearly: prospecting for re-tenders that haven't been published yet, which implicitly routes published-tender queries to search_tenders. It stops short of naming an alternative or stating an explicit when-not condition, so it falls just short of 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 already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds non-obvious context beyond that: the call is FREE and the response shape is a coverage summary rather than records, which matters for cost-aware planning.

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 fragments, with the cost signal ("FREE.") and the payload description front-loaded. Every clause carries information; nothing is padding.

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 input parameters and no output schema, the description takes on the job of describing the return payload and does so by listing the coverage dimensions. Combined with annotations, an agent has everything needed to call this 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 the baseline is 4 and there is nothing for the description to disambiguate. It correctly does not invent parameter guidance for a parameterless call.

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 specific resource — what data Awardia holds — and enumerates the dimensions returned (sources, countries, date range, tender/award counts). It reads as a metadata/coverage endpoint distinct from data-returning siblings like search_tenders, but it never names those siblings to sharpen 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?

"Useful to check before searching a country or period" gives an explicit trigger condition tied to a concrete workflow, effectively routing the agent here ahead of search_tenders. It stops short of naming the alternative tool or stating when this is unnecessary.

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/idempotentHint/openWorldHint=false, and the description adds genuinely new behavior: ranked-by-relevance output, the exact competition fields returned, and the cross-language matching rule (English queries match all EU languages, local-language terms improve recall). It does not cover no-match/empty-result behavior or pagination, which keeps it out of 5 territory.

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 sentences: pricing, input, output. The pricing note is front-loaded, the input example is parenthetical, and the return contract is spelled out. No sentence is 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?

With no output schema, the description carries the return-shape burden and does so (ranked tenders with named competition metrics), and annotations cover safety. Missing only edge-case behavior (no matches, result count behavior) for full 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 limit and countries are fully documented in the schema and the description adds nothing about them. It only reinforces the company_description matching hint that the schema already states, making this a baseline 3.

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 description -> open public tenders), plus the scope of matching (best match first) and the value-add payload (competition signals). It never names the obvious sibling search_tenders, so an agent cannot tell from the description alone how this differs from keyword tender search.

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 input style but gives no when-to-use / when-not-to-use guidance and no routing against siblings such as search_tenders or bid_intelligence. 'Free during beta' implies a cost motive for choosing it, but that is a hint, not a rule.

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 safety (readOnlyHint, idempotentHint, openWorldHint=false), and the description adds substantial behavior beyond them: beta pricing, source coverage per geography, the full return payload, the meaning of the 'competition' metric, and the widening fallback sequence with its 'widened_to' and 'note' signals. This is exactly the kind of behavioral context an agent cannot get from structured fields.

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?

Dense and front-loaded with purpose before the alternative and fallback details, and most sentences carry distinct information. It is on the long side, but little is redundant given the number of distinct behaviors (sources, returns, competition metric, widening) it must convey.

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 thoroughly: title, buyer, country, region, CPV codes, estimated value, deadline, official link, documents link, plus the derived 'competition' metric. Combined with the fallback behavior and sibling routing, an agent has everything needed to call and interpret it.

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; the description goes slightly beyond by explaining the widening order that relaxes the place, then keywords, then the place entirely, which clarifies how region and keywords degrade when no exact match exists. Most other param meaning (keywords language handling, region matching) is already in the schema descriptions.

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') with the exact filter dimensions (keywords, country, region, CPV sector, value) and names the data sources (TED EU-wide, Diário da República for Portugal). It also distinguishes itself from the sibling bid_intelligence by routing price/rival analysis there.

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 names bid_intelligence as the alternative for price ranges and rivals, which tells the agent when to prefer that sibling. It gives clear context (open tenders, deadline in the future) but does not state exclusions against other siblings such as award_history or expiring_contracts.

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