Rated evidence on AI adoption: practices, company cases, claim checks and readiness assessments.
Scored across 10 tools
Most tools target distinct resources or actions, and the check_ai_figure vs check_vendor_claim split is clearly spelled out. However, there is real overlap between start (map overview returning cases/themes/figures), open (generic filtered list), and the specialized find_company_cases / find_practices / find_readiness_assessment tools, which return much the same rows. An agent must reason about which of these enumerators to use, though the cross-references help.
The dominant pattern is verb_noun (check_*, find_*, get_evidence, review_ai_transformation_plan), which is predictable. A few deviations exist: board_brief is a noun phrase, and open/start are bare verbs used as special entry points, but overall the set is readable and mostly consistent.
Ten tools is well within the healthy range for an evidence-map server covering discovery, retrieval, verification and synthesis. Some redundancy (start/open/find_* overlapping) means not every tool is strictly necessary, but the count is reasonable.
The surface covers the full workflow: orient (start), browse/filter (open, find_*), fetch full records (get_evidence), verify figures and vendor claims (check_*), and produce synthesis (board_brief, review_ai_transformation_plan). It is a read-only evidence domain, so no create/update is needed; only a keyword/full-text search might be a minor gap.
Prepare a one-page board brief on a question about AI adoption, from rated evidence only. Returns the company cases by the kind of work AI was used for, the themes (with practice counts for the company’s size), the claim checks and figure groups, and how to write the brief: open the cases for the work in question and one to three themes, fetch eight to twelve records and write from them. Use it when someone needs a summary for a board, an owner or an investment committee. To review a written plan, use review_ai_transformation_plan.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Company size band: micro-small, medium, mid-market, enterprise (1–49, 50–249, 250–999, 1,000+ employees). Or pass employees instead. | |
| industry | No | The site’s industry category, if one fits: professional-services (consulting, accounting, audit, law), agencies (marketing, advertising, creative), ecommerce-retail (online shops, retail, wholesale), manufacturing. Map the user’s words, in any language, to one of these; if none fits (a bank, a hospital, a public body), leave it out. | |
| employees | No | Number of employees, e.g. 120. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the evidence is restricted to rated evidence, and the return payload is itemised (cases by kind of work, themes with practice counts for company size, claim checks, figure groups). It stops short of covering behaviour when no inputs are supplied or any result limits, so not a 5.
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 purpose and output composition, with no filler sentences. It is a dense, comma-chained construction whose middle clause ('open the cases... fetch eight to twelve records') mixes usage procedure into the purpose statement, costing a little scannability.
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 description compensates by enumerating exactly what comes back and how to act on it (fetch eight to twelve records and write from them). Combined with the when-to-use guidance, an agent has everything needed to select and invoke 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% and the schema itself carries the enum mapping instructions and size-band definitions. The description only adds that the company's size drives practice counts in the returned themes, which is mild extra meaning rather than documentation of the parameters themselves. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and artifact ('Prepare a one-page board brief') plus the subject matter ('a question about AI adoption') and the constraint ('from rated evidence only'). It is clearly distinguishable from review_ai_transformation_plan, which it names.
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?
Explicit trigger ('Use it when someone needs a summary for a board, an owner or an investment committee') and an explicit exclusion with the correct alternative ('To review a written plan, use review_ai_transformation_plan'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before quoting an AI statistic (e.g. '95% of AI pilots fail', 'only 13% of companies are ready for AI'), check where it comes from, who was asked and what it covers. Returns every claim check of a widely repeated statistic and the groups of other figures; fetch the matching claim check, or open the group the figure belongs to. Use it for figures from surveys, reports and the press. For a claim a vendor makes about its own product, use check_vendor_claim.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds real behavioral context not in annotations: the call returns claim checks plus groups of related figures and is a discovery step that requires a follow-up ('fetch the matching claim check, or open the group'). It stops short of saying what happens when no match is found.
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 trigger ('Before quoting an AI statistic') is front-loaded with concrete examples that make the intent immediately legible. The middle sentence about claim checks and groups is slightly tangled in phrasing but still earns its place by describing the return.
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 at a high level, plus it explains the follow-up flow to the matching claim check or group. Missing only edge-case behavior (e.g., when nothing matches), which is a minor gap for a lookup 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?
Zero input parameters, so the schema baseline of 4 applies. The description adds nothing about parameters because there are none to document.
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 (check an AI figure/statistic) and immediately scopes it to provenance: origin, who was asked, what it covers. It also contrasts itself with the sibling check_vendor_claim, so an agent can pick between the two without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the domain of use ('figures from surveys, reports and the press') and hands off the excluded case ('For a claim a vendor makes about its own product, use check_vendor_claim'). This is a clear when-to-use plus when-not-to-use-with-alternative, the top of the scale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a claim made by an AI vendor or consultant, such as '30% productivity gain', 'cuts support costs by 40%' or 'our agents replace 700 staff'. Returns the questions to ask the vendor, the claim checks, the groups of figures and the company cases by the kind of work AI was used for, so you can find the same result and companies that tried the same kind of tool. Use it whenever someone selling or proposing AI quotes a result. For a statistic from the press or a report, use check_ai_figure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 valuable context by naming what comes back: questions to ask, claim checks, figure groups, and company cases grouped by kind of work. It stops short of describing format or how the caller should use the returned groups, which keeps it at 4.
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 and examples are front-loaded and the sibling routing is last, which is the right order. The middle sentence listing four return components is dense and slightly run-on, but every clause carries 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?
With no input schema and no output schema, the description carries the burden of explaining returns, and it does so by enumerating the four result categories. Minor gap: it does not say how the caller should match an incoming claim against the returned groups.
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?
Zero parameters, so the baseline is 4. The description correctly implies this is a reference/checklist lookup rather than a claim submitted for evaluation, matching the empty input 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+resource ('check a claim made by an AI vendor or consultant') and immediately grounds it with three concrete example claims. It is clearly differentiated from the sibling check_ai_figure, which handles press/report statistics.
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 an explicit trigger ('Use it whenever someone selling or proposing AI quotes a result') and an explicit exclusion with the correct alternative ('For a statistic from the press or a report, use check_ai_figure'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List real companies that used AI and how it turned out: measured result, company-reported result, went wrong, or partly walked back. Use it for 'Who has done this?' or 'What went wrong for others?'. Filter by the kind of work AI was used for (task), outcome, theme, industry or company size; returns the cases in one line each, or a menu with counts when there are many. Fetch the ones you use with get_evidence for the story, who produced the figures and the public sources.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Company size band: micro-small, medium, mid-market, enterprise (1–49, 50–249, 250–999, 1,000+ employees). Or pass employees instead. | |
| task | No | The kind of work AI was used for: a task key from start, e.g. customer-service-and-support. | |
| theme | No | A theme key from start, e.g. governance-and-risk or people-and-skills. | |
| outcome | No | Cases with this outcome: measured, company-reported, went-wrong or walked-back. | |
| industry | No | Cases in this industry: professional-services, agencies, ecommerce-retail, manufacturing, or other (none of the four, e.g. banks, airlines, public bodies). Practices apply to all industries. | |
| employees | No | Number of employees, e.g. 120. |
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 behavior the annotations cannot: results come back one line per case, or as a menu with counts when the result set is large — meaningful since no output schema exists. It doesn't say whether filters combine or how the menu threshold is chosen.
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, then triggers, then filters, then return shape and follow-up — a sensible funnel. The filter enumeration partly duplicates the schema's own parameter list, which is the one sentence that doesn't fully earn its place.
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 results and does so (one line each, or a counts menu), plus points to get_evidence for sources and figures. Missing only secondary details such as whether multiple filters are ANDed and any result cap, which are unlikely to block a correct first call.
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 each parameter (size bands, task key, theme key, outcome enum, industry enum, employees) is already documented in the schema. The description only restates the filter dimensions as a list, adding no syntax or combination semantics beyond the structured fields — the correct baseline of 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 — listing real companies that used AI — and enumerates the outcome taxonomy (measured, company-reported, went wrong, walked back) that defines what a 'case' is here. It also contrasts itself with the sibling get_evidence, which fetches the underlying story, so an agent can separate listing from deep retrieval without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger questions ('Who has done this?', 'What went wrong for others?') and an explicit next step: 'Fetch the ones you use with get_evidence'. It stops short of naming when to prefer find_practices (practices rather than cases), which is the main sibling ambiguity an agent would still have to resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List practices for adopting AI that fit a company's size, rated by strength of evidence. Use it for 'Where should we start with AI?' or 'What should a 120-person manufacturer do first?'. Pass the number of employees or a size band, and optionally the theme, stage or priority. Returns the practices in one line each, or a menu by theme when there are many; fetch the ones you use with get_evidence for their studies, cases and links.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Company size band: micro-small, medium, mid-market, enterprise (1–49, 50–249, 250–999, 1,000+ employees). Or pass employees instead. | |
| stage | No | How far the company is: explore, adopt, redesign or run. | |
| theme | No | A theme key from start, e.g. governance-and-risk or people-and-skills. | |
| priority | No | Practices with this priority. | |
| employees | No | Number of employees, e.g. 120. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state that the operation is read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral detail about output shape: practices are returned one line each, or as a menu by theme when there are many.
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 description is three tight sentences, front-loading purpose, then usage, then return behavior and follow-up. There is no wasted text.
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 read-only listing tool with five optional parameters, full schema coverage, and no output schema, the description gives enough context about input choice, output format, and the next-step tool. Minor detail about how evidence strength is represented could be added, but nothing essential 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 coverage is 100%, so the schema carries the detailed parameter documentation. The description still adds value by clarifying that employees or a size band can be supplied and that theme, stage, and priority are optional refinements.
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: list practices for adopting AI, filtered by company size and rated by evidence strength. This clearly distinguishes it from sibling tools such as get_evidence, which fetches supporting studies and cases, and find_company_cases.
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 usage examples ('Where should we start with AI?' / 'What should a 120-person manufacturer do first?') and routes the agent to get_evidence for deeper detail. It does not explicitly cover when not to use it versus every sibling, but the routing context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List published questionnaires, tests and task maps to assess AI readiness, AI literacy, staff attitudes or which tasks suit AI, best tested first, optionally by kind or free to use. Fetch the ones that fit with get_evidence for how well each has been tested, who answers it, its length, licence and cost. For advice on what to do, use find_practices.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | The kind key from start, e.g. readiness-surveys or ai-knowledge-tests-and-self-ratings. | |
| free_only | No | Only assessments that are free to use. |
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 two genuine behavioral traits beyond that: results are restricted to published instruments and are ordered best-tested-first. It says nothing about result volume, pagination or what a list entry actually contains, leaving a moderate 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?
Three sentences with no filler and the core purpose front-loaded. The middle clause stacks 'best tested first' and 'optionally by kind or free to use' into an already long sentence, making the ordering guarantee slightly easy to miss.
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?
No output schema exists, but the description compensates by explaining that the list is a discovery surface and that get_evidence supplies per-assessment attributes (test quality, respondent, length, licence, cost). Enough to call it correctly; only result cardinality is left 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 coverage is 100% and both parameters are documented in the schema, including the kind key example, so the description carries little extra burden. The phrase 'optionally by kind or free to use' only restates that both filters are optional, adding no syntax or semantics beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and a concrete resource set (published questionnaires, tests and task maps) with the assessed dimensions spelled out: AI readiness, AI literacy, staff attitudes, task suitability. It is clearly separable from find_practices (advice) and get_evidence (per-item detail), so an agent can pick it 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?
Explicitly routes: use get_evidence to fetch detail on the assessments that fit, and use find_practices when the need is advice on what to do rather than a measurement instrument. The optional filters (kind, free-only) are framed as narrowing the list, giving clear conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full records for ids from the menus and lists (such as "case:klarna-ai-customer-service" or "claim-check:mit-95-percent-of-ai-pilots-fail"): figures, ratings, verdicts, caveats, primary sources, the ai-first.company link, and the ids of related studies, cases and practices to follow. Up to 20 ids per call. Quote and cite only from what this returns.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Ids as the menus and lists give them, e.g. ["case:klarna-ai-customer-service", "practice:ask-ai-vendors-for-proof"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioral value beyond that: the shape of the returned payload and a hard citation policy ('Quote and cite only from what this returns'), which governs how the agent may use the output. The 20-id cap is repeated from schema rather than newly disclosed.
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 verb and resource, then a payload enumeration followed by two short operational sentences. The keyword list inside the parentheses is dense but every item maps to a real return field; 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 output schema, the description carries the burden of describing return contents and does so concretely, plus the batch limit and the citation constraint. An agent has enough to call it correctly and to know how to use the results.
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% for the single 'ids' parameter, including minLength/maxLength/maxItems and an example. The description reinforces the id format with a second namespace ('case:...', 'claim-check:...') and the per-call limit, but adds no meaningful semantics beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('get the full records for ids') and enumerates exactly what comes back: figures, ratings, verdicts, caveats, primary sources, link, and related ids. It implies the discovery-vs-retrieval split from siblings ('ids from the menus and lists'), but never explicitly names find_company_cases or find_practices as the path that produces those 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: ids are described as coming 'from the menus and lists', which tells an agent this is a follow-up lookup after discovery. There is no explicit when-to-use/when-not, and no alternative is named, so the agent must infer that query-based siblings like find_company_cases are for discovery and this is for hydration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open one part of the evidence map: a list (practices, cases, studies, figures, claim-checks, assessments) with filters such as theme, outcome, industry, company size, stage, priority, figure group (line) or assessment kind. Returns every matching row in one line with its id, or, when there are more than 25, a menu splitting them by the next filter, with counts. Use the arguments the menus show. Then fetch the rows you pick with get_evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Figures: the kind of number, e.g. measured-in-a-study or self-reported. Assessments: the kind key from start, e.g. readiness-surveys. | |
| line | No | Figures only: the group key from start, e.g. time-freed or running-cost. | |
| list | Yes | Which list: practices, cases, studies, figures, claim-checks or assessments. | |
| size | No | Company size band: micro-small, medium, mid-market, enterprise (1–49, 50–249, 250–999, 1,000+ employees). Or pass employees instead. | |
| task | No | Cases only: the kind of work AI was used for, a task key from start, e.g. customer-service-and-support or legal-research-drafting-and-filings. | |
| stage | No | How far the company is: explore, adopt, redesign or run. | |
| theme | No | A theme key from start, e.g. governance-and-risk or people-and-skills. | |
| outcome | No | Cases with this outcome: measured, company-reported, went-wrong or walked-back. | |
| industry | No | Cases in this industry: professional-services, agencies, ecommerce-retail, manufacturing, or other (none of the four, e.g. banks, airlines, public bodies). Practices apply to all industries. | |
| priority | No | Practices with this priority. | |
| employees | No | Number of employees, e.g. 120. | |
| free_only | No | Assessments only: free to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, idempotent read. The description adds real behavioral detail beyond them: a full row set with ids when matches are 25 or fewer, otherwise a menu split by the next filter with counts. That pagination/splitting behavior is exactly what an agent needs and is not in 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?
Three tightly packed sentences with the outcome-relevant behavior front-loaded and the next step last. The parenthetical filter list is dense but every clause carries information; no filler sentences.
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 12-parameter tool with no output schema, the description still covers what the response looks like (one row per line with id, or a capped menu with counts) and what to do next. Nothing needed for correct invocation is absent, other than the sibling-overlap issue noted elsewhere.
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 five parameters are enums with inline descriptions, so the schema does most of the work. The description's paraphrase of filter families (theme, outcome, industry, size, stage, priority, line, kind) adds little; it does not, for example, clarify which filters are valid for which list.
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 concrete verb and resource ('Open one part of the evidence map') and enumerates the six selectable lists behind the required `list` argument. The scope is clear, but the description never distinguishes this tool from sibling lookups such as find_practices, find_company_cases and find_readiness_assessment, which appear to cover the same lists.
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 gives a workflow hint — 'Use the arguments the menus show' and 'Then fetch the rows you pick with get_evidence' — which is useful sequencing. However it never says when to pick `open` versus the find_* siblings, which is the main selection decision an agent faces here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review an AI transformation proposal, business case or rollout memo, for example before it goes to a board. Returns the do-first practices for the company’s size as a checklist, each with its evidence rating and wording that may show it, and how to find similar cases. You read the plan and decide for each practice whether the plan commits to it, rules it out or leaves it out. Pass the size and industry; the plan itself stays with you. For one figure in the plan, use check_ai_figure.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Company size band: micro-small, medium, mid-market, enterprise (1–49, 50–249, 250–999, 1,000+ employees). Or pass employees instead. | |
| industry | No | The site’s industry category, if one fits: professional-services (consulting, accounting, audit, law), agencies (marketing, advertising, creative), ecommerce-retail (online shops, retail, wholesale), manufacturing. Map the user’s words, in any language, to one of these; if none fits (a bank, a hospital, a public body), leave it out. | |
| employees | No | Number of employees, e.g. 120. |
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 the important non-obvious behavior that the plan text is never accepted ('the plan itself stays with you') and that the human does the per-practice judgement. It also discloses the shape of the return (do-first practices as a checklist with evidence rating and supporting wording, plus how to find similar cases). Minor gaps: no note on result caps or what happens when size/industry are omitted.
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 purpose and the board example, and the division-of-labour sentence ('You read the plan and decide...') earns its place. It is on the long side at four sentences, and the 'Pass the size and industry' sentence is the weakest given the schema already covers it.
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?
No output schema exists, and the description compensates well by describing the returned checklist, its evidence ratings and the 'how to find similar cases' component, plus the human-in-the-loop workflow. It is nearly complete for a read-only, three-optional-parameter lookup; only the optionality of size/industry and fallback behavior are left unaddressed.
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%, including enum values and the micro-small/medium/mid-market/enterprise bands, so the schema carries the semantics. The description only says 'Pass the size and industry', adding nothing about the enum mapping or the employees alternative — and it slightly implies both are required when nothing is. 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?
States a specific verb ('Review') and specific resources (AI transformation proposal, business case, rollout memo), plus a concrete timing example ('before it goes to a board'). It also fences itself off from the sibling that handles a narrower job ('For one figure in the plan, use check_ai_figure'), so an agent can distinguish it from check_ai_figure and find_practices without opening either 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?
Names one alternative explicitly with the condition that selects it ('For one figure in the plan, use check_ai_figure'), which is genuine routing guidance rather than an implied hint. It gives clear context for when to reach for this tool, but does not address the other plausible siblings (find_practices, board_brief, find_company_cases) or state what to do when the user has no plan in hand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here for any question about adopting AI in a company: the map of the ai-first.company evidence. Returns the company cases by the kind of work AI was used for (customer service, legal work, office assistant and others), the six themes (with counts of practices, cases and studies), the claim checks of widely repeated AI statistics, the groups of other figures, the company cases by outcome, the assessments by kind, and what each filter value and rating means. Then open the part that fits and fetch records with get_evidence.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent, non-open-world operation. The description adds useful behavioral context by explaining that the tool returns an index/map of categories, counts, checks, groups, and rating meanings rather than raw records. It does not describe response size or pagination, but for a zero-parameter index tool the added context is strong.
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 phrase is front-loaded and immediately tells the agent where to start. The long enumeration of returned map components is dense but largely earns its place because there is no output schema; still, it could be structured more cleanly.
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 input parameters, the description carries the burden of explaining what the tool returns and how it fits into the workflow. It does that thoroughly by listing the map's contents and directing the agent to open the relevant part and use get_evidence for records.
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 input parameters, so there are no parameter semantics for the description to clarify. The empty schema already communicates this, and the baseline for a parameterless 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 states a clear resource and behavior: it is the map/index of ai-first.company evidence and returns grouped cases, themes, claim checks, figures, assessments, and filter meanings. It also distinguishes itself from get_evidence and open by positioning itself as the starting point before fetching records.
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 explicitly says to start here for any question about adopting AI in a company, then open the relevant part and fetch records with get_evidence. This gives both the when-to-use condition and the named alternative for retrieving actual records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
board_briefcheck_ai_figurecheck_vendor_claimfind_company_casesfind_practicesfind_readiness_assessmentget_evidenceopenreview_ai_transformation_planstartSource-traced evidence research for AI agents. We organise the evidence; you decide.
Evidence-weighted decision engines: AI business cases, venture readiness, free soundchecks.
Essays, an enterprise AI map and a skill-matrix gap analysis on AI adoption and junior formation.
Independent AI-agent reviews: trust checks, evidence scorecards, incident registry, recommendations.
Add one secure layer between your agents and this server.
