Arquestra Consulting Market Radar

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely non-obvious behavioural context beyond that: the exact static payload (sources, value band, window, classification, data date, CC BY-NC 4.0 licence, required attribution) and the server's limits plus where to escalate — all useful for a tool with 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?

Roughly fifty words, front-loaded with the primary purpose before trailing into licence and limits. It is a single long sentence with parenthetical lists, which is dense but every clause carries information an agent would otherwise lack.

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, no parameters and only four annotations, the description carries the burden of stating what comes back, and it enumerates the topics well (coverage, methodology, date, licence, attribution, limits, contact path). It stops short of describing the response's shape or field names, which would fully close the gap, but the topical enumeration is sufficient to call the tool 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, which is the baseline-4 case; there is nothing for the description to disambiguate. The description correctly implies no input is needed by framing the tool as a pure 'about/what' statement.

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 names a specific informational resource — what the radar covers, how it is built, the data date, licence and attribution — so an agent knows this is a metadata/licence tool rather than a data query. It does not explicitly contrast itself with the data-returning siblings (get_firm, list_markets, search_tenders), though the content makes the distinction inferable.

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: read this to learn coverage, provenance and licence terms. There is no explicit 'use this before querying' or 'use this when you need attribution text / licence terms' statement, and no named alternatives, so an agent must infer the trigger from the content 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: fuzzy name matching that forgives accents, legal forms and typos, a fallback that returns candidate firms instead of erroring, and the format=markdown output mode — none of which are visible in annotations. It does not state what happens when nothing matches at all.

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 content inventory is dense but earns its place because no output schema exists to convey the return shape, and the input/disambiguation guidance is front-loaded in the second sentence. The awards list is long enough to read as a run-on, but no sentence is pure 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-value burden and does so thoroughly, listing the card's sections plus the Markdown option. The only meaningful omissions are the 'lang' parameter's effect and the empty-result case, which are minor for a single-record read tool whose annotations already signal safety.

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 67%, and the description compensates for the weakest-described parameter: it explains that 'firm' accepts a slug or a fuzzy name and what normalization is applied, and it documents 'format' (markdown returns the card as Markdown) which the schema leaves undocumented. The 'lang' parameter is not mentioned in the description at all, leaving one gap.

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 concretely enumerates what the returned card contains (awards by country, value won, rank, main buyers, frameworks, co-winners, similar firms) over a stated 24-month window, so the resource and its scope are unambiguous. It implicitly differentiates from list_firms by telling the agent to take the slug from there, though it does not explicitly contrast with get_market or search_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 clearly states the input options (slug or name in any spelling) and the disambiguation path: 'when the name is unclear, returns the candidates', which tells the agent how to recover from an ambiguous lookup. It stops short of explicit when-not-to-use guidance or naming an alternative tool for bulk/market-level queries.

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 (readOnly, idempotent, non-destructive, closed-world), so the description correctly spends its space on data semantics: rebuilt weekly, 24-month window, notice links, coverage, page link and citation. It does not mention error behavior for an unknown country/kind, but for a read tool the added context is solid.

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 resource definition, and the long enumerative second clause earns its place by listing the actual card contents rather than padding. It is dense and list-like but not wasteful.

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 full burden of describing return values, and it does so item by item (awards, competition, winners, SME share, buyers, trend, open calls, contracts, coverage, link, citation). An agent knows what it will get before calling.

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 all four parameters including enums are documented; baseline is 3. The description adds only a little beyond the schema, notably that format=markdown returns the same card rendered as Markdown, which reinforces the already-documented enum.

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 ('One market card (country x kind of work)') and, via the singular 'one' plus the sibling list_markets, an agent can tell it returns a single card rather than a list. The scope is concrete and distinguishable from 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?

Usage is only implied by 'One market card' and the singular framing; there is no explicit 'use list_markets to enumerate, get_market for one card' routing statement or prerequisite note. The only explicit alternative mentioned is format=markdown vs default json, which is a format switch rather than a tool-selection guide.

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, non-destructive, closed-world, so the safety profile is covered. The description adds behavior beyond that: result-set size limits (25 per page, 100 per query) and the fact that country filtering is by country of award rather than headquarters. Not quite a 5, since it doesn't say what happens at the pagination ceiling.

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, front-loaded with the entity definition, then filters, then paging. Every clause carries information; the middle sentence is slightly overloaded with the field enumeration, but nothing is redundant.

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?

A read-only list tool with annotations covering safety and no output schema, so the description must convey what comes back: it does, listing the aggregate fields and the card/page links. Paging limits are stated. Only the enumeration of kind values and the lang behavior are left entirely to the schema.

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?

At 33% schema coverage the description must carry weight, and it does: it explains that country matches firms with awards there, that query matches words of the name, that page_size tops out at 25, and it restates the paging model. The lang parameter's purpose (language of page links) is only covered by its schema description, keeping this below 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?

States a specific verb and resource and defines the population precisely: consulting firms winning European public contracts that have a firm card. It also enumerates the returned fields (awards in 24 months, value won, main country, kind of work, links), which lets an agent distinguish it from the single-entity get_firm. No sibling is named explicitly, so it stops short of a 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?

The description names the available narrowing dimensions (country, kind, name words) and the parenthetical "firms with awards there" clarifies country filter semantics, which is real usage help. However, it never says when to reach for this over get_firm or search_tenders, nor any exclusion such as 'use get_firm to fetch details of one firm'.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the dataset scope and threshold (EUR 15,000+), the card granularity, and the exact headline figures and links returned, which tells the agent what a call yields before making 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?

Purpose is front-loaded in the first clause, and the long parenthetical of headline figures earns its place because there is no output schema. The single dense sentence is slightly heavy, but nothing is redundant.

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 does the work of describing return content (cards with headline figures and links). Remaining gaps are minor: no default stated for the optional filters, no note on result size or empty-result behavior.

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 67%; the undocumented 'kind' parameter is compensated by the description enumerating all five kinds of work, and 'one card per country and kind of work' explains what both filters do. The 'lang' parameter is not mentioned in the description, but its schema entry already explains it affects only page links.

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 ('Lists the market cards of the Arquestra Consulting Market Radar') and immediately defines the underlying dataset: public consulting contracts in Europe from EUR 15,000 up, one card per country and kind of work. This makes it clearly distinguishable from get_market (single card) and list_firms in the sibling set.

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?

'Filter by country or kind' implies how to narrow results, and the granularity statement ('one card per country and kind of work') implies this is the browse/overview entry point. However, it never explicitly says when to use this versus get_market for a specific card, nor does it state the default when no filter is supplied.

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 this a safe, idempotent read, so the description correctly spends its words on non-obvious behavior: prefix-only matching, accent insensitivity, fallback behavior when no word matches (rows matching most words are returned and marked), and hard paging caps of 25 per page and 100 per query. It does not explain ordering beyond 'open calls first' or how the cap is surfaced to the caller.

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?

Information is front-loaded: what is searched, then matching rules, then filters, then results and paging. Sentences mostly earn their place, though the closing 'radar link' reference is compressed to the point of ambiguity for a first-time caller.

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 nine-parameter search with no output schema, the description covers result contents (public notice link plus radar link) and paging behavior, which is what an agent needs to invoke it correctly. Remaining gaps are minor: no explicit statement about result ordering beyond status, and the radar-link alternative is under-explained.

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 only 44%, but the description compensates for most of the gap: it explains query matching rules, status, country, kind of work, minimum value and firm filtering, and the paging limits that the schema only partially encode. The `lang` parameter's role (language of page links, data unchanged) is left to the schema, which does cover it.

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 (keyword search) over two named resources (open consulting calls, awards from the last six months) with geographic scope (Europe). The matching semantics (title, buyer, winners; prefix matching, accents ignored) further pin down exactly what is searched, so an agent knows what this tool does 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?

Gives concrete guidance on how to query (search in the notice's country language, or mix languages) and lists the available filters. It also points to an alternative path ('for a search by meaning, use the radar link'), though that alternative is a link inside results rather than a sibling tool, so routing is clear but slightly indirect.

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