Kiltikonet (public)

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 fully covered structurally. The description adds only that remaining seats per tariff are part of the response, which is modest extra context; lookup failure behavior or missing-event handling is not addressed.

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 compact sentence with the resource and the accepted key formats front-loaded. Nothing is wasted and nothing relevant is buried.

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 an output schema present, the description needn't explain return values, and it still flags that per-tariff availability is included. For a one-parameter read-only lookup this is nearly complete; only the relationship to the culture_events list tool is left unstated.

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 0% and the single parameter is documented only as a bare 'string' named 'event'. The description compensates by stating that either an identifier or a slug is accepted, which is the crucial disambiguation an agent needs; format examples or slug syntax would have pushed this higher.

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 and resource — retrieving the detail of a single Culture Connect event — and adds that availability per tariff is included. The singular form implicitly contrasts with the plural sibling culture_events (list), but that distinction is never made explicit.

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: an agent can infer this is the drill-down companion to culture_events, but the description never says when to prefer one over the other or what happens with an invalid identifier. No exclusions or prerequisites 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered elsewhere. The description contributes one real behavioral constraint — only ticketed events with open or paused status are included — but says nothing about ordering, pagination, or volume.

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 compact sentence that front-loads the resource and then the returned fields. No filler, no restatement of the title.

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 parameters, full annotation coverage and an output schema covering return values, the description only needs to convey scope, which it does. The one missing piece is a pointer to the sibling culture_event for per-event detail.

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 explain and the baseline is 4. Nothing in the description misleads about 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 (Culture Connect events) and the fields surfaced: dates, venue, prices, plus a scope qualifier on ticketing status. It does not, however, distinguish itself from the singular sibling culture_event, so an agent must infer list-vs-detail from the plural name alone.

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 when-to-use or when-not-to-use statement; the parenthetical '(ouverte ou en pause)' implies the tool covers events currently on sale or paused rather than all events. The natural alternative, culture_event, is never mentioned, so selection guidance is left implicit.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description usefully adds the aggregate nature and content scope, but says nothing about shape, granularity (counts vs. records) or whether the payload is large.

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 short sentence with the resource named first and the covered domains in parentheses — front-loaded and waste-free. It is arguably too terse for the amount of behavior it leaves unexplained, but nothing in the 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?

For a zero-parameter, read-only aggregate with full annotation coverage and no output schema, the description names the entity and the domains included, which is close to sufficient. It stops short of describing the level of aggregation, which is the one thing an agent might misjudge.

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 nothing for the description to disambiguate; baseline 4 applies. The mention of domain coverage is a bonus, not a parameter explanation.

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 and output shape ('Instantané agrégé du Kiltikonet Network') and enumerates the covered domains (territoires, opérateurs, franchises, licences), so the agent knows what the call yields. It does not differentiate itself from related siblings such as network_programmes or observatory_global_territories.

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 indication of when this overview should be called versus the observatory_* or network_programmes siblings, nor any note about using it as a first orientation step before drilling into detail. The agent must infer its role from the name alone.

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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of whether the canon is stable, versioned, or returned as a flat list — so it contributes essentially no behavioral context of its own.

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?

It is a single short sentence with no padding, but it is under-specified rather than efficient — the brevity comes at the cost of substance, leaving the agent with a phrase that is only marginally more informative than the title 'Network — programmes'.

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 no parameters, the description is the only place to explain what the caller actually receives (list of names? codes? descriptions?), and it does not. For a lookup tool whose return value is its entire purpose, this leaves a meaningful 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?

The tool takes zero parameters, so there are no parameter semantics to explain; the baseline of 4 applies. Nothing in the description is needed to compensate for schema gaps.

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 resource (les programmes du Kiltikonet Network) and characterizes the content as a 'nomenclature canonique', which hints at a canonical listing. However, 'nomenclature canonique' is ambiguous — it is unclear whether this returns a list of programme names, an enumerated taxonomy, or definitions — and nothing distinguishes it from the sibling 'network_overview'.

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 given on when to call this tool, when not to, or which sibling (e.g. network_overview) to prefer. The agent must infer usage entirely from the name.

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 destructiveHint=false, so the safety profile is covered. The description adds genuine unannotated context: each section preserves the raw response of its source route, and generated_at is compilation time, not source-data freshness — a real trap for an agent reporting data recency. It omits cost/latency expectations for an aggregate call, which is the remaining 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?

Front-loaded with the key fact ('lecture seule', consolidated dossier), followed by the section inventory and then the generated_at caveat. Three dense statements, no filler. The section list is slightly run-on but each item tells the agent something it will receive.

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?

An output schema exists, so return values need not be described. But for a one-parameter aggregate over five source routes, the description leaves open what `limit` scopes, whether sections are independently truncated, and roughly how large/expensive the response is. Adequate but with clear gaps for a composite 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 0% and the single `limit` parameter (integer, default 50) is never mentioned in the description. It is unclear whether `limit` caps records per section or across the whole dossier, which materially changes what an agent should pass. The description does nothing to compensate for the undocumented parameter.

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 gives a specific noun phrase ('Dossier consolidé en lecture seule') and then enumerates the five sections it bundles — cultural indicators, territorial coverage, reference corpus, regional lenses and Caribbean view — which maps closely onto the sibling tools (observatory_global_corpora, observatory_global_territories, observatory_regional_lenses, observatory_caribbean_overview). That enumeration effectively signals this is the aggregate over those siblings. It stops short of naming them as alternatives, so an agent must infer the aggregation relationship rather than read it.

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 implied rather than stated: 'consolidé' suggests this is the one-shot snapshot to use when the whole picture is wanted, but there is no explicit 'use this instead of calling the four section routes separately' or any precondition. No exclusion or guidance on when a narrower sibling is preferable.

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 only the qualifier 'vérifiée' (verified data), which hints at curation but does not explain scope, granularity, or whether it covers all territories or only curated ones. With no output schema, no return-shape context is given 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?

One front-loaded sentence, no filler or repetition. It is arguably too terse given the absence of an output schema, but nothing in it is wasted.

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 parameters and no output schema, the description is the only place an agent can learn what this aggregate returns — and it does not say. It also leaves unclear how it relates to observatory_caribbean_brief, a near-name twin, which is the main risk for mis-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 no parameters and the schema is trivially complete, so there is nothing for the description to compensate for. Baseline 4 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 single sentence names a resource ('couverture culturelle vérifiée de la Caraïbe') and a shape ('vue agrégée'), so the agent knows this is a read-only aggregated view for a region. However it does not say what is inside the aggregate, and it fails to distinguish itself from the sibling 'observatory_caribbean_brief', which sounds like an alternative rendering of the same Caribbean data.

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?

There is no statement of when to use this versus the Caribbean brief or the global/regional observatory siblings, and no prerequisites or exclusions. The agent must infer selection purely from the name.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that, such as corpus size, update cadence, or what kind of reference material is returned.

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 single sentence is concise and front-loaded, but it is under-specified rather than efficient. It does not structure the information an agent needs to select the tool confidently.

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?

Although there are no parameters and annotations cover the safety profile, there is no output schema and the description does not explain what the tool returns. For a corpus-retrieval tool, the agent is left guessing about the response shape and contents.

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 there are no parameter semantics to explain. The schema coverage is 100%, and the baseline score for a no-parameter tool 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 says it is a 'corpus de référence' feeding the Observatory, so the resource category is identifiable. However, it lacks a specific verb or output focus and does not distinguish this tool from siblings such as observatory_global_facts or observatory_regional_lenses.

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?

There is no guidance on when to call this tool, what question it answers, or how it relates to the many sibling observatory tools. The agent must infer usage entirely from the name and title.

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 context — aggregated, redistributable data with provider provenance retained — but says nothing about result volume, the default limit of 50, or what a 'fact' record contains.

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 short sentences, front-loaded with the resource and then the data-provenance note. No filler, though the second sentence is more licensing boilerplate than operational guidance.

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 four-filter data query tool with no output schema and 0% parameter documentation, the description should explain accepted filter values and how results are shaped. It instead stops at a marketing-level summary, leaving the agent to guess at valid inputs.

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 carries the full burden, yet it only echoes the three filter names without any valid values, identifier formats (territory codes?), or expected strings. The limit parameter is not mentioned at all, nor is the default of 50.

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 verified cultural facts from the Observatory and names three filter axes, which is more than a restatement of the name. However, it never distinguishes itself from closely named siblings such as observatory_global_territories, observatory_global_corpora, or observatory_regional_lenses, leaving the agent unable to tell which of these data endpoints to pick.

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?

There is no statement of when to use this tool, when not to, or which sibling to prefer for a given question. The three filter names imply a retrieval use case but give no routing guidance among the nine siblings.

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds no behavioral context of its own — nothing about pagination behavior, default result size, ordering by territory, or what 'couverture' means in terms of returned 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?

It is a single front-loaded sentence with zero waste, which is structurally sound. But the brevity is achieved through under-specification rather than efficiency — the whole description is one fragment with no verb describing the operation.

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 an undocumented parameter, the description carries the burden of explaining the return shape and the limit's effect, and it does neither. For a corpus-coverage tool sitting among eight similarly named siblings, an agent needs more 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 description coverage is 0% for the single 'limit' parameter, which has only a title and a default of 100. The description does not mention the parameter, its meaning, its bounds, or what happens when it is omitted, so it fails to compensate for the coverage 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 names a specific resource — a coverage map of the Observatory's global cultural corpus, broken down by territory — so the agent knows roughly what data lies behind it. However, it never says whether the tool returns a data listing, an aggregated count, or a geo-structured view, and it does not distinguish itself from close siblings such as observatory_global_corpora, observatory_global_facts, or observatory_regional_lenses.

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?

There is no statement of when to call this tool versus the other nine observatory/global siblings, no prerequisites, and no exclusions. The only implicit signal is the word 'territoire', which the agent must infer from context.

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 non-destructive behavior, so the safety profile is covered. The description adds nothing beyond that — not what the lens definitions contain, not whether results are static reference data, not anything the annotations don't already say.

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 short sentence with no waste, but it is too thin to be considered well-structured — there is no front-loaded useful information beyond a noun phrase. Conciseness is achieved through under-specification rather than editing.

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 no parameters, the description is the only place an agent could learn what this returns, and it says only that definitions exist. For a lookup tool with a rich sibling set, this leaves the agent unable to predict the response content.

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 nothing for the description to explain; baseline 4 applies. The empty schema makes parameter documentation a non-issue.

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 resource — regional analysis lens definitions — which is marginally more than the title restated ('lentilles régionales'). It names no verb and gives no hint about what form the definitions take, so an agent can tell roughly what domain it covers but not what the tool does with it.

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?

There is no indication of when to call this versus siblings such as observatory_caribbean_overview or observatory_global_territories, nor of any prerequisites. The agent must infer usage purely from the name.

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