OI AI Adoption

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description adds substantial context on top: selection is deterministic and does not use a language model, and it details the exact shape of the result (ask_first first, one recommendation workflow, at most two alternatives, plus an internal evidence section). This goes well beyond what the annotations 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?

One dense paragraph, front-loaded with purpose before mechanics and the general_question special case. Every sentence carries information (deterministic model, output ordering, edge-case task), though the middle sentence stacking recommendation sub-parts is somewhat heavy.

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 and the nested properties object holds ~32 fields, so the description carries real burden; it compensates by describing the return structure (ask_first, recommendation, alternatives, internal ids/evidence/sources) and the special general_question path. An agent has enough to call it correctly and interpret the response.

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 meaning beyond the schema by explaining the interaction between description, task and properties ("the process properties it states; leave out what it does not say") and clarifying the special semantics of general_question and user_unsure. Marginal but genuine added value over the already-thorough schema.

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: advises on using AI in a user-described process, drawing from a curated, sourced knowledge base. It distinguishes itself from siblings like adoption_get_pattern by describing the input (free-text description plus matched task and properties) and the deterministic selection model, so an agent can tell this is the entry-point discovery tool.

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 clear routing context: use task general_question when there is no concrete process, and set user_unsure true after the user says they don't know. It does not, however, explicitly name sibling alternatives (e.g., use adoption_get_pattern to fetch one pattern by id, or adoption_list_process_types to browse), leaving that comparison to inference.

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 a safe, read-only, idempotent operation, so the bar is lower, and the description still adds real value by disclosing the two-part response shape and that every claim in the internal part is either resolved to sources (title, publisher, URL, date read, location, evidence level) or explicitly marked as source-less. It does not mention permission requirements or pagination, but for a single-record read those are minor.

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 dense sentences that front-load the primary return value before describing the internal part. The parenthetical enumerations are long but each item earns its place by telling the agent what fields to expect.

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 largely discharges it by naming the user-facing fields and the internal part's source-resolution structure. Minor gaps remain (it doesn't restate the language-fallback or default sections behavior), but those are covered by 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?

Schema description coverage is 100%, so the schema already documents id, lang, and sections (including defaults and the untranslated-text fallback). The description adds no parameter-level detail beyond loosely referencing the 'internal part' that the sections parameter selects, which is the baseline expectation when the schema does the heavy lifting.

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 verb and resource ('returns the user-facing recommendation for one pattern') and enumerates the payload (workflow, sourced effects, needs, risks, a first step). 'For one pattern' implicitly separates it from the sibling adoption_find_patterns, but no sibling is named explicitly.

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: fetching a single pattern's detail, and the note that the internal part 'answers questions such as what the advice is based on' hints at a use case. There is no explicit when-to-use/when-not guidance or routing to adoption_find_patterns for discovery.

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, destructiveHint=false, so the safety burden is covered. The description then adds useful context about what each returned entry contains: the plain-words requirement, the article, the date checked, and a link to the official text — this is genuine added value 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?

A single, well front-loaded sentence that leads with the resource and then enumerates the returned fields. No filler, though the trailing list of returned attributes makes it slightly long for one sentence.

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 appropriately compensates by enumerating the returned fields (plain-words requirement, article, date checked, official link), which is exactly what an agent needs to interpret results. Safety and idempotency are covered by annotations, so little is missing beyond selective-use guidance.

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% and all three parameters are enums with documented meanings, so the schema does the heavy lifting. The description maps country and the optional pattern link to their roles but adds no syntax or format detail beyond the schema, matching the 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 and resource: returns EU and national provisions from the regulation register, scoped to a chosen country and optionally to one pattern. The resource is distinct from siblings like adoption_find_patterns or adoption_get_pattern, but the description never explicitly contrasts itself with them.

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: it makes clear that pattern_id narrows results to provisions linked to that pattern, which tells the agent the optional filter's role. There is no explicit when-to-use vs siblings guidance and no stated prerequisites or exclusions, so it stops short of 4-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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral content on top: the result set is a fixed, cardinality-known collection of six types, each with a definition and associated pattern ids, which tells the agent the response is static and non-paginated. It does not note any auth or rate-limit considerations, but none are needed for a static taxonomy lookup.

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 sentence, front-loaded with the return content, with the parenthetical enumeration earning its place by fixing expectations about the result set. No filler or restatement of the name.

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-required-parameter, read-only list tool, the description covers what the tool returns (the six types, their definitions, and the pattern ids per type), which is precisely what an agent needs since no output schema exists. Nothing required to call it correctly is missing.

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% and the single enum parameter is fully documented in the schema, including the English-fallback-and-marking behavior. The description adds no parameter-level detail of its own, 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?

Specific verb+resource ("Returns the six process types of the knowledge base") and it even enumerates the six types and states what each entry carries (definition + adoption pattern ids), so an agent knows exactly what comes back. It does not, however, explicitly differentiate itself from the sibling adoption_find_patterns / adoption_get_pattern tools that work with those same pattern ids.

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: by disclosing that each type carries the ids of its adoption patterns, it hints this is a discovery step before pattern lookups. There is no explicit when-to-use, when-not-to-use, or naming of the alternative sibling for retrieving patterns.

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 establish this is a safe, idempotent, closed-world read. The description adds genuinely new behavioral context beyond that: scoring happens 'with fixed rules' (deterministic, no model discretion), each limit carries its underlying rule, gaps come paired with next steps, and the output is explicitly framed as 'a self-assessment' rather than an authoritative audit. That last caveat is exactly the kind of expectation-setting 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?

Three compact sentences, front-loaded with the core action, then the output contract, then the unanswered-input rule and the self-assessment framing. Nothing is repeated from the schema or annotations and no sentence 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 output schema, the description carries the burden of describing returns and does so concretely (levels, rules, gaps, next steps). It covers the edge case of unanswered areas and the interpretive status of the result, which is sufficient for an agent to call this correctly after get_readiness_questions.

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

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

Schema description coverage is 100%, so the schema already documents both the 'answers' mapping (keyed by question id, values being option ids) and the 'lang' enum and its untranslated-text behavior. The description only restates that answers come from get_readiness_questions and hints that partial answer sets are tolerated, which is marginally additive. Baseline 3 is appropriate.

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

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

The description names a specific verb (scores) and the exact resource (the answers returned by get_readiness_questions), then enumerates the output shape: a 0-4 level per area, the rule behind each limit, the gaps, and a next step. It is clearly distinguishable from its sibling get_readiness_questions, which produces the input rather than the score.

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 workflow context is explicit: this tool consumes 'the answers from get_readiness_questions', so an agent knows it runs downstream of that tool. It also tells the agent what happens with incomplete input ('Unanswered areas are reported as not assessed'). It does not name any alternative scoring tool or state when not to use it, so it falls 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 readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds real value beyond that by disclosing its data sources (Eurostat, ECB exchange rate, four studies) and its failure mode: inputs lacking a public source are listed rather than assumed. It also clearly bounds the funding-call output (no amounts, no open/closed status).

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, front-loaded with what the tool produces; the sourcing and missing-input caveats are dense but each sentence carries substantive information. Slightly overlong but no 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 14-parameter, nested-object, no-output-schema tool, the description does a good job describing the shape of the result (costs shown separately, payback across three scenarios, missing inputs listed) and the data provenance. A few parameter-level gaps remain but the agent can invoke it confidently.

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 only 36% across 14 parameters, and the description compensates partially by grouping fields into conceptual buckets (external, compliance, internal staff, licences, operations) and hinting at study-driven savings and own_savings_share. It adds little meaning for individual cost parameters like internal_it_hourly_cost_eur, maintenance_eur_per_month, or the model_usage tier values.

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 ('Estimates the costs of introducing AI') and enumerates the outputs it produces: external costs, internal staff time, licences, operations, and a payback period in three savings scenarios. It is clearly distinct from the readiness/planning siblings, though it never names an alternative tool explicitly.

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 when the tool is appropriate (cost/payback analysis) and explains data-handling behavior, but gives no explicit when-to-use versus when-not-to-use guidance relative to siblings like assess_ai_readiness or plan_ai_rollout. Usage must be inferred.

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, so the safety profile is covered. The description adds the genuinely useful constraint that answers are option ids, not free text, and that each question carries id, reason, and allowed options. It doesn't mention pagination or result size, but adds real context beyond 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?

Two tight sentences that front-load what is returned, then the shape of each item, then the answer-format constraint. No 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 single-optional-parameter read tool with a 100%-covered schema and annotations, this is adequate. However, there is no output schema, so the description could say more about the response shape (e.g., grouping or ordering), and it gives no guidance on the sibling tool it naturally pairs with.

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%, and the enum values are documented in the schema itself, so the baseline is 3. The description does not restate or expand on the lang parameter's behavior (English fallback for untranslated texts), which the schema already handles.

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 (Returns) and resource (self-assessment questions on AI readiness) and even enumerates the four content areas (data, processes, people, compliance). This distinguishes it clearly from siblings like assess_ai_readiness, which scores rather than retrieves questions.

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 the retrieval use case but never states when to call this versus assess_ai_readiness or plan_ai_rollout. The pairing with assess_ai_readiness is inferable but not explicit, so 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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuine behavioral detail beyond that: the fixed four-phase output structure and the deterministic augmentation rule (level 0/1 readiness areas inject preparation tasks into the discovery phase). It stops short of noting determinism guarantees or output 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?

Two sentences, zero filler: the first front-loads what is returned, the second adds the conditional behavior. No restatement of the tool name or schema enums.

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 must carry the return-value burden and does so well (phases, tasks, RACI, risks, indicators). The only shortfall is that the dependency on get_readiness_questions for constructing 'answers' lives only in the schema and would have been useful in the description itself.

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 for the 'answers' parameter by explaining its downstream effect (preparation tasks added to discovery for level 0/1 areas) and ties 'pattern' to the plan's shape rather than restating the enum. 'lang' gets no extra context, keeping it from 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 gives a specific verb ('Returns') and resource ('phased rollout plan') and enumerates the plan's contents (discovery/pilot/rollout/operations, tasks, RACI roles, risks, indicators) scoped to 'the chosen implementation pattern'. This is clearly distinct from siblings like assess_ai_readiness, estimate_ai_costs, or adoption_get_pattern.

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 second sentence establishes a conditional ('When readiness answers are given...'), which suggests the answers parameter is optional, but it never says when to call this vs. running assess_ai_readiness or fetching get_readiness_questions first. No explicit when-not guidance or sibling routing.

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