Read-only search of Catherine Ives-Yim's writing on AI, IoT and the CRA, and scoring of four checks.
Scored across 6 tools
Each tool has a distinct purpose: retrieval by slug (get_article), keyword search (search_articles), listing articles, listing themes, listing assessments, and scoring an assessment. The only mild overlap is that list_themes could appear redundant with list_articles' theme field, and search_articles vs get_article require reading descriptions to separate retrieval from search.
All six tools follow a clean verb_noun pattern (get_article, list_articles, list_assessments, list_themes, score_assessment, search_articles) with consistent snake_case throughout.
Six tools is well-scoped for a personal writing-and-assessment site, with each tool (retrieve, search, list, score) earning its place and no filler tools.
The read-only surface covers the domain well: listing and fetching articles, browsing themes, discovering assessments, inspecting their questions, and scoring them. There is no obvious lifecycle gap, though a tool to report or export a scored result set is a minor missing convenience.
The full text of an article or site page by slug, with citation and source labels. About describes stated experience; Services describes the offering; articles describe published views. None is independent verification. Cite the address.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The article slug from list_articles, or "about" or "services". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses content-level behavior (what about/services/articles represent) and a verification caveat, plus a usage instruction ('Cite the address'). It says nothing about permissions, rate limits, or failure behavior for an invalid slug, so behavioral coverage is partial.
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 short sentences with the purpose front-loaded and no filler. The final imperative ('Cite the address') is terse and slightly ambiguous in phrasing, but overall the text is lean and scannable.
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 one parameter, no annotations, and no output schema, the description covers what is returned at a high level ('full text ... with citation and source labels') and how to interpret the special slugs. That is close to sufficient for a simple fetch tool; only failure modes and permission requirements remain 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 description coverage is 100% and the single slug parameter is already documented as coming from list_articles or being 'about'/'services'. The description's discussion of slug semantics largely mirrors the schema, so it meets the baseline without adding new syntactic or formatting detail.
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 retrieval mode: 'the full text of an article or site page by slug'. It also clarifies the three slug classes (about, services, articles), which is meaningful scope beyond the name. It does not explicitly name a sibling to contrast with, so it sits at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains what each slug type means, which implicitly guides when to call this versus other listing tools, and adds a caveat ('None is independent verification') about interpreting results. However, it never names an alternative (e.g., search_articles to find a slug) or states an explicit when-not-to-use condition, so guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Catherine Ives-Yim's published articles (slug, title, standfirst, theme, publication label, address, length), optionally filtered by theme or a word in the title. Free to call; no model involved.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | Only articles in this theme (see list_themes). | |
| contains | No | Only articles whose title or standfirst contains this text (case-insensitive). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses cost/latency characteristics ('free to call; no model involved') and the fields returned, but says nothing about ordering, pagination, result limits, or auth requirements for a list endpoint that could return unbounded results.
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 dense sentence that front-loads the resource and its fields before the filters and cost note. Nothing is wasted, though the parenthetical field list is long enough to slightly bury the filtering behavior.
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 simple two-parameter list tool with a fully documented schema, this is nearly complete: the description supplies the return field inventory (there is no output schema) and the cost profile. Missing only ordering/pagination behavior and sibling routing.
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 both parameters are already documented, including the case-insensitivity note and the list_themes cross-reference. The description adds no format or syntax detail beyond restating the filters, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (Catherine Ives-Yim's published articles), and enumerates the returned fields plus the two optional filters. It does not, however, differentiate itself from the sibling search_articles or get_article, leaving the agent to guess when a keyword search should be used instead.
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 optional theme/title filters imply usage, and 'Free to call; no model involved' signals this is a cheap lookup rather than a model-backed operation. But no explicit when-to-use or when-not-to-use guidance is given, and neither search_articles nor list_themes is named as an alternative despite being obvious candidates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The free questionnaire tools on the site and, for one of them, its full question set: modules, questions, answer anchors or options, and the conditions under which a question applies. Use this to put the questions to a user before calling score_assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | No | A pack id (ladder, snapshot, strategy, cra) to get its questions; omit for the list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does well: it explains the branching behavior (omit pack = list, supply pack = that pack's full question set) and enumerates the returned content (modules, questions, anchors/options, applicability conditions). It says nothing about auth, rate limits, or errors, so it is not exhaustive.
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, no filler, and the one-vs-list distinction is front-loaded. The first sentence is burdened by a long appositive enumeration, which slightly hurts readability but is not 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 zero-required-param tool with no output schema and no annotations, the description covers both call modes, the return payload contents, and the downstream workflow with score_assessment. Only error/edge behavior and the contents of the list mode itself are 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 description coverage is 100%, so the schema already documents the single 'pack' parameter. The description adds only indirect meaning by describing what the pack path returns; it does not name valid pack values or the default omitting behavior beyond what the schema states. 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?
The description states a specific resource (the site's free questionnaire tools) and spells out the two shapes of output: the bare list, or one pack's full question set with modules, questions, anchors and applicability conditions. It is distinguishable from siblings by its pairing note with score_assessment, though the listing verb is only implied rather than stated.
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 an explicit usage moment and ordering: 'put the questions to a user before calling score_assessment.' That is clear sequencing guidance against a named sibling. It does not state when-not to use it or what to do instead for a score-only need, so it falls short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The themes the articles are grouped under, with counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It conveys one behavioral fact—the response includes counts per theme—but doesn't state whether the list is static, complete, or whether themes can be empty. Thin for a zero-annotation tool.
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 clause, front-loaded with the resource and value-add (counts). No waste.
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 simple zero-param enumeration tool, the description is minimally adequate and even mentions the return shape (counts). However, with no annotations and no output schema, a bit more on what a 'theme' is and how to use the result would improve 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?
Zero parameters, so baseline 4. Nothing to describe and the description correctly adds no misleading parameter talk.
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 (themes) and adds the scoping detail that they are the grouping categories for articles, with counts. That distinguishes it from siblings like list_articles. It lacks the 'list all' verb emphasis but the intent is clear.
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 an agent should call this versus search_articles or list_articles, nor that it's a discovery/categorization step. Sibling differentiation is implicit at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the same deterministic rules engine the website uses for one of the assessments and returns the headline, module scores, flags and the plan. No model is involved: the result is computed from published rules, exactly as a visitor to the site would get. Answers: scale questions take 0 to 3 (worst to best anchor) or "dk" for don't know; single-choice questions take the option value; multi-select questions take an array of option values, e.g. {"CTX-markets": ["eu", "uk"]}. Unknown question ids or invalid values are rejected with an error listing them. Unanswered questions lower confidence rather than the score, and the result carries an "evidence" field: with no scored questions answered the headline is "Not enough answers", and below half confidence the headline is marked provisional. The result is a diagnostic to guide a conversation, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | Yes | ||
| answers | Yes | Question id to answer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses that no model is involved, that results are deterministic, that unknown ids or invalid values are rejected with an error listing them, that unanswered questions lower confidence rather than score, and the exact headline behavior for empty and sub-half-confidence results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the core purpose and return shape come first, then answer formats, then validation and confidence behavior. Every sentence adds information, though the run-on answer-format sentence could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description properly names the returned fields (headline, module scores, flags, plan, evidence). For a computation tool with nested free-form answers, this is nearly complete; only the pack enum meaning 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 only 50%, and the description compensates strongly by specifying answer formats per question type (0-3 or "dk" for scale, option value for single-choice, array for multi-select) with a concrete example. The pack enum values are left unexplained, though they are largely self-descriptive.
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 — runs the deterministic rules engine for one assessment pack and returns headline, module scores, flags and the plan. It also distinguishes itself from the sibling list_* tools by making clear it computes a result rather than enumerating resources.
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 context is implied (score one of the assessments, diagnostic to guide a conversation, not advice), but there is no explicit statement of when to call this versus list_assessments or how it relates to other siblings. The agent must infer the trigger condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over the bundled writing and site pages. Accepts questions or keywords, excludes further-reading sections, and returns a best passage per source before additional passages. Includes citation and source labels. Read get_article before making broader claims. No model is involved; this is retrieval, not an answer or independent verification.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Words or a short phrase. Up to 300 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses exclusions (further-reading sections), return ordering (best passage per source first), inclusion of citation/source labels, and that no model is involved so results are retrieval, not verified answers. Missing only operational details like result limits or auth, which is minor for a read-only search.
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 tight sentences, front-loaded with the core action and scope before the routing advice and behavioral caveats. Dense but each sentence carries distinct 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 output schema, the description appropriately explains what comes back (a best passage per source, additional passages after, with citation and source labels) and sets expectations about verification. Only the limit parameter's behavior is 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 50% — query is documented in the schema (up to 300 chars) and the description adds that it accepts questions or keywords. The limit parameter (default 6, max 12) is never explained in the description, so the coverage gap is only partly compensated.
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 (keyword search over bundled writing and site pages) and scopes it by noting what it excludes (further-reading sections). It also distinguishes itself from the sibling get_article by directing broader-claim work there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells the agent it accepts questions or keywords and explicitly routes deeper reading to get_article before 'making broader claims.' Clear context, but there is no explicit when-not-to-use statement or treatment of the other siblings (list_articles, score_assessment).
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.
score_assessment1 field changedInput schema / properties / pack / enumPrevious value: -[
- "ladder",
- "snapshot",
- "strategy",
- "cra"
-]New value: +[
+ "ladder",
+ "snapshot",
+ "strategy",
+ "cra",
+ "cto"
+]get_articlelist_articleslist_assessmentslist_themesscore_assessmentsearch_articlesChecks whether a website is readable and citable by AI systems (ChatGPT, Claude, Perplexity, etc.)
Compliance lint for AI, scraping, and privacy law. Cited findings in 200 or more jurisdictions.
Inspect selected project excerpts and screen user-confirmed facts for bounded EU AI Act readiness.
Read-only AI search visibility data: citations, AEO audits, and advisor insights from AI-Advisors.
Add one secure layer between your agents and this server.
