raumnebenan.de is a resource hub focused on actionable product thinking for product owners, product designers, business analysts, product managers, agile coaches, and user researchers. The site provides clear, structured guides and tools to help teams understand users, identify opportunities, validate ideas, and deliver products that create real user and business value.
Scored across 10 tools
Tools are mostly distinct and the descriptions give explicit guidance on when to prefer one over another (e.g. get_article_details_by_slugs vs by_uuids, list_articles vs search_articles). There is mild overlap between list_stories/get_stories_by_category and list_articles/search_articles, but the descriptions resolve the boundary clearly.
Every tool follows a clean snake_case verb_noun pattern (get_*, list_*, search_*), with parallel naming for the slug/uuid detail variants. No mixing of conventions or vague verbs anywhere.
Ten tools is well-scoped for a content/CMS server, with each tool covering a distinct access pattern (browse, search, filter by tag/category, glossary, details). Nothing feels redundant or bolted on.
The surface fully covers a read/consumption lifecycle: listing, searching, tag/category filtering, story hierarchy, glossary, and full article detail by both slug and UUID. No obvious dead ends for the stated purpose of exploring published Product Thinking content.
Fetches complete article details (full markdown body content, author, publishing dates, tags, and related article links) for an array of friendly-URL slugs (e.g. ["kano-model", "overview"]). Slugs can be obtained from list_articles, search_articles, get_stories_by_category, or get_articles_by_tag. If slugs are unknown, prefer finding them with search_articles or list_articles. Use get_article_details_by_uuids only when you have UUIDs instead of slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| article_slugs | Yes | A list of 1–10 article slugs |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed-world profile, so the safety burden is lifted. The description adds that the response is 'complete' with 'full markdown body content', hinting at a large payload, but says nothing about behavior on unknown/invalid slugs or per-slug failure handling. Adequate but not rich beyond the structured hints.
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, zero filler, and front-loaded: what is returned comes first, provenance and disambiguation follow. Every sentence carries routing or payload 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?
An output schema exists, so return values need not be explained; the description still names the high-value fields an agent would care about. Combined with the sibling routing, an agent has everything needed to select and call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: concrete slug examples (["kano-model", "overview"]) clarifying format, and the provenance of valid slugs via four sibling tools. It does not restate the 1–10 bound, which the schema already carries.
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 (fetches) plus resource (complete article details) with an explicit enumeration of payload contents (markdown body, author, dates, tags, related links). It also states the input shape (array of friendly-URL slugs) and names the sibling it is not (get_article_details_by_uuids), so an agent can distinguish it 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 routes the agent: slugs come from list_articles, search_articles, get_stories_by_category, or get_articles_by_tag; if unknown, prefer search_articles or list_articles; use get_article_details_by_uuids only when UUIDs are held. Both the when and the alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches complete article details (full markdown body content, author, publishing dates, tags, and related article links) for an array of article UUID strings. Prefer get_article_details_by_slugs when slugs are known; use this tool when you already have article UUIDs (e.g. from list_articles or previous lookups).
| Name | Required | Description | Default |
|---|---|---|---|
| article_uuids | Yes | An array of 1–10 article UUIDs to fetch details for. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
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 genuine behavioral value by specifying the returned payload contents (full markdown body, related links), which goes beyond 'details', though it says nothing about batching cost or why the 1–10 cap exists.
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, with the core purpose first and the sibling-routing rule second. Every clause earns 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?
An output schema exists, so return values needn't be explained, and the input is a single fully-documented parameter. The description still names the key payload fields and the disambiguation rule, leaving nothing an agent needs in order to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single array parameter already documents its UUID items, min/max items, and uniqueness. The description only restates 'array of article UUID strings', adding no format or edge-case guidance beyond the schema — 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 (fetches) and resource (complete article details) and enumerates the payload (markdown body, author, publishing dates, tags, related links). It also names the sibling it is not — get_article_details_by_slugs — so an agent can discriminate 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?
Explicit routing rule: prefer the slug variant when slugs are known, use this one when UUIDs are already in hand, with concrete sources ('e.g. from list_articles or previous lookups'). Both the when and the alternative are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists published articles that carry the specified tag (e.g. "dual-track"). Tag matching is case-insensitive. Discover available tags using list_tags, or inspect the tags array on search results and article details. Call get_article_details_by_slugs with the returned article_slug values to read full content. Optional page/per return a slice and next_page while more remain; without them the complete list is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| per | No | Optional items per page (default 20 when page is set, max 100). | |
| tag | Yes | The tag to fetch articles for. | |
| page | No | Optional 1-based page. Omit both page and per to receive the complete list. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
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 behavior the annotations don't: case-insensitive tag matching, published-only filtering, and the pagination contract (`next_page` while more remain, complete list without page/per). No rate limits or ordering guarantees, but the additions are substantive.
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 core action, then discovery path, then follow-up call, then pagination nuance. Four dense sentences with no filler; every clause conveys a distinct operational fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is unnecessary, and the description still notes next_page semantics. Combined with a fully documented schema and read-only annotations, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema for `tag` by documenting case-insensitive matching (the schema only says "the tag to fetch articles for") and by tying page/per to the returned next_page, adding meaning the field descriptions do not carry.
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 precise verb and resource ("Lists published articles that carry the specified tag") plus the scope qualifier "published". This is clearly distinguishable from list_articles, search_articles, and list_tags in the sibling set without opening any 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 to alternatives: use list_tags (or the `tags` array on results) to discover tags, and use get_article_details_by_slugs with the returned article_slug to read full content. Both when-to-use and the downstream follow-up call are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the published stories of one category with their nested articles (slug, title, summary, dates, and URLs). category must be one of: foundation, sense, focus, discover, deliver. Use this tool when exploring articles within a known Product Thinking category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The category to fetch stories for. Must be one of: foundation, sense, discover, focus, deliver. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds little there. It does clarify that only 'published' stories are returned and that articles are nested, but it says nothing about ordering, pagination, or behavior for a category with no stories.
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 with the core purpose front-loaded and the usage note second. The only waste is the re-listing of the enum values, which the schema already contains.
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 a rich annotation set, a fully described enum parameter, and an output schema covering return values, the description supplies everything an agent needs to select and call it. A bit more routing guidance against the nine sibling list/search tools would make it fully complete.
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 single enum parameter is fully documented in the schema itself. The description merely repeats the same five allowed values, adding no syntax, format, or semantic meaning beyond what the schema already provides, 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?
The description gives a specific verb and resource ('Lists the published stories of one category') and even enumerates the nested article fields returned. It implicitly separates itself from siblings like list_stories (all stories) or get_articles_by_tag, though it never names an alternative to make the distinction airtight.
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 states a clear usage context: 'Use this tool when exploring articles within a known Product Thinking category.' That is a usable trigger condition, but it gives no exclusions and never says when to prefer get_articles_by_tag, list_articles, or list_stories instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists published articles as a compact index (slug, uuid, title, category, story slug). Use it to browse available articles. Filter with optional category (foundation, sense, discover, focus, deliver). Set include_summary: true to include the summary excerpt for each article. For finding articles on a specific topic or method, prefer search_articles. To read full article body markdown, call get_article_details_by_slugs with the returned article_slug values. Optional page/per return a slice and next_page while more remain; without them the complete list is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| per | No | Optional items per page (default 20 when page is set, max 100). | |
| page | No | Optional 1-based page. Omit both page and per to receive the complete list. | |
| category | No | Optional category filter to restrict articles to one topic (foundation, sense, discover, focus, deliver). | |
| include_summary | No | When true, includes the 1-2 sentence summary for each article. Defaults to false for a lean compact index. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the exact return shape, the include_summary toggle, and pagination via next_page when page/per are supplied.
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 core purpose and return shape, then routing guidance. It is somewhat long but each sentence carries actionable information with 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?
With an output schema present, return values need no further explanation. The description covers purpose, filters, pagination, and sibling routing, leaving no gap an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes further by explaining the include_summary effect ('summary excerpt'), the page/per slice semantics, and the next_page return signal, adding value beyond the 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 ('Lists published articles as a compact index') and enumerates the returned fields (slug, uuid, title, category, story slug). It clearly distinguishes itself from search_articles and get_article_details_by_slugs.
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 when to use it ('browse available articles') and when not to ('For finding articles on a specific topic or method, prefer search_articles'), plus a hand-off instruction to get_article_details_by_slugs for full bodies. Alternatives and conditions are fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the raumnebenan content categories (pillars of Product Thinking) with their title and a scope description, as maintained in the CMS. Use this tool to decide which category fits the user's question, then call get_stories_by_category with the matching category value.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful context: the data is CMS-maintained and each entry includes a scope description, which explains what the agent will receive. It stops short of describing ordering or pagination, so a 4 rather than 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?
Two sentences, purpose front-loaded, followed by the workflow directive. No redundant or filler content; every clause earns 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?
For a zero-param listing tool with an output schema and full annotation coverage, the description supplies everything needed: what it returns, its domain, and how it chains into get_stories_by_category. No explanation of return values is required given the output 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?
The tool takes zero parameters, so the baseline is 4. There is nothing to document and the description correctly does not invent parameter details.
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 (Lists) and resource (raumnebenan content categories / pillars of Product Thinking), and specifies the returned fields (title and a scope description). This clearly differentiates it from sibling list tools like list_tags, list_articles, and list_glossary.
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 states when to use it ('to decide which category fits the user's question') and names the follow-up tool (get_stories_by_category) with the value to pass. This is a complete routing instruction with no inferential gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists published glossary entries covering product management, agile delivery, user research, and product thinking terminology, including term names, comprehensive definitions, and metadata. Returns all glossary entries in one unpaginated response. Use it for term definition questions ("what is X?"). For articles explaining or applying a method, prefer search_articles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world, so the safety profile is covered. The description adds a genuinely useful behavioral detail beyond the annotations: the response is unpaginated and returns all entries at once, which matters for payload sizing. It stops short of describing entry count or any filtering 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?
Three sentences, each earning its place: what is returned, in what volume, and when to choose this vs. the sibling. The routing constraint is placed last but the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-field details need not be repeated, and the description still notes the unpaginated-all-entries behavior, which is the one return trait an agent must anticipate. For a zero-parameter read tool, nothing needed 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is a 4. The description instead spends its words on output shape rather than inventing nonexistent parameters, which 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 (Lists) plus resource (published glossary entries) and enumerates the terminology domains covered, along with what each entry contains (term, definition, metadata). This clearly distinguishes it from article-oriented siblings like search_articles and list_articles.
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 triggering case ('term definition questions — "what is X?"') and routes the agent to the correct alternative when a method explanation is wanted ('prefer search_articles'). Both when-to-use and when-to-use-something-else are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all published stories (thematic groups of articles) with their nested articles (slug, title, summary, category, dates, and URLs). Use it to explore the complete content hierarchy and thematic structure. Large response; use page/per to read it in slices, or get_stories_by_category when a category is already known. Optional page/per return a slice and next_page while more remain; without them the complete list is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| per | No | Optional items per page (default 20 when page is set, max 100). | |
| page | No | Optional 1-based page. Omit both page and per to receive the complete list. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds valuable behavioral context: responses are large, page/per yield slices with a next_page token while more remain, and omitting both returns the complete list. It does not quantify size or mention rate limits, but the pagination contract is clearly 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?
Three tightly packed sentences: purpose and contents first, then usage, then pagination mechanics. Every clause carries information (nested fields listed, sizing warning, alternative tool, token behavior) with 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?
With zero required parameters, an output schema present, and full schema coverage, the remaining agent questions are response size and pagination behavior, both of which are answered. Nothing needed to invoke 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%, so the baseline is 3, but the description adds semantics the schema lacks: the next_page token is returned while more results remain, and omitting both parameters changes behavior to 'complete list' rather than a default page.
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 (Lists) plus resource (published stories) and even disambiguates the domain term by defining stories as 'thematic groups of articles' with nested article fields. It is immediately distinguishable from siblings like list_articles and list_categories.
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 alternative route ('get_stories_by_category when a category is already known') and states the intended use ('explore the complete content hierarchy'). It also tells the agent when to paginate versus request everything.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists content tags with the number of published articles per tag. Use it to discover available topics and exact tag spellings, then call get_articles_by_tag to list the articles of a tag. Optional page/per return a slice and next_page while more remain; without them the complete list is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| per | No | Optional items per page (default 20 when page is set, max 100). | |
| page | No | Optional 1-based page. Omit both page and per to receive the complete list. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
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 real behavioral context beyond that: the pagination contract (page/per return a slice with next_page while more remain; omitting both returns the complete list). It does not mention auth needs or rate limits, so it falls just short of 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?
Three front-loaded sentences that reach the purpose immediately; the closing pagination clause is dense but earns its place. Slight redundancy with the schema's parameter descriptions keeps it from a 5.
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 annotations covering the safety profile and an output schema covering return values, the description only needs purpose, routing and pagination semantics — all of which it supplies. Nothing an agent needs to call this 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%, so both parameters are already documented, including the identical guidance that omitting page and per returns the complete list. The description restates this joint behavior with little added syntax or default detail beyond the schema's own text, 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 ('Lists content tags') plus the payload ('with the number of published articles per tag'), which distinguishes it from siblings like list_categories and list_glossary. An agent can identify 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 names the use case ('discover available topics and exact tag spellings') and routes the agent forward to the correct sibling, get_articles_by_tag, to fetch the articles of a tag. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs case-insensitive full-text search across published articles. Returns matching articles with summary metadata, category, tags, and URLs (no body markdown). Use it when the user asks about a specific topic or method (e.g. "kano model", "customer journey"). Then call get_article_details_by_slugs with the returned article_slug values to read full content. Optional page/per return a slice and next_page while more remain; without them the complete list is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| per | No | Optional items per page (default 20 when page is set, max 100). | |
| page | No | Optional 1-based page. Omit both page and per to receive the complete list. | |
| query | Yes | The search query string |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| source | Yes | |
| retrieved_at | Yes | |
| copyright_holder | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive safety, so the bar is lower, but the description adds real behavior: matches are case-insensitive, results carry summary metadata/category/tags/URLs and explicitly NOT body markdown. It also discloses pagination semantics (next_page while more remain; complete list when page/per omitted). Minor gap: no note on match ranking or empty-result behavior.
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, front-loaded paragraph that goes purpose -> output shape -> when to use -> next step -> pagination in that order, with no filler sentences. Every clause carries actionable 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?
For a 3-param search tool with annotations covering the safety profile and an output schema covering return values, the description supplies the missing pieces: search breadth, result contents, pagination contract, and the follow-up tool. Nothing an agent needs to invoke it correctly is absent.
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 baseline is 3, but the description adds semantics the schema does not carry: the returned next_page field and the contrast between sliced and complete-list modes. It largely restates the schema's page/per default behavior rather than adding new syntax detail, keeping it just above baseline.
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 (case-insensitive full-text search over published articles) and constrains it to published articles, which separates it from list_articles and get_articles_by_tag. The agent knows exactly what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('when the user asks about a specific topic or method', with concrete examples) and prescribes the follow-up call to get_article_details_by_slugs for full content. This is a clear when-to-use plus a named next step, leaving nothing to inference.
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.
get_article_details_by_slugs3 fields changedOutput schema / properties / data / properties / next_pageAdded value: +{
+ "description": "The next page number; absent on the last page.",
+ "minimum": 2,
+ "type": "integer"
+}Output schema / properties / data / properties / pageAdded value: +{
+ "description": "The returned page (1-based).",
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / perAdded value: +{
+ "description": "Items per page.",
+ "minimum": 1,
+ "type": "integer"
+}get_article_details_by_uuids3 fields changedOutput schema / properties / data / properties / next_pageAdded value: +{
+ "description": "The next page number; absent on the last page.",
+ "minimum": 2,
+ "type": "integer"
+}Output schema / properties / data / properties / pageAdded value: +{
+ "description": "The returned page (1-based).",
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / perAdded value: +{
+ "description": "Items per page.",
+ "minimum": 1,
+ "type": "integer"
+}get_articles_by_tag5 fields changedInput schema / properties / pageAdded value: +{
+ "description": "Optional 1-based page. Omit both page and per to receive the complete list.",
+ "maximum": 10000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / perAdded value: +{
+ "description": "Optional items per page (default 20 when page is set, max 100).",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / next_pageAdded value: +{
+ "description": "The next page number; absent on the last page.",
+ "minimum": 2,
+ "type": "integer"
+}Output schema / properties / data / properties / pageAdded value: +{
+ "description": "The returned page (1-based).",
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / perAdded value: +{
+ "description": "Items per page.",
+ "minimum": 1,
+ "type": "integer"
+}get_stories_by_category3 fields changedOutput schema / properties / data / properties / next_pageAdded value: +{
+ "description": "The next page number; absent on the last page.",
+ "minimum": 2,
+ "type": "integer"
+}Output schema / properties / data / properties / pageAdded value: +{
+ "description": "The returned page (1-based).",
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / perAdded value: +{
+ "description": "Items per page.",
+ "minimum": 1,
+ "type": "integer"
+}list_articles5 fields changedInput schema / properties / pageAdded value: +{
+ "description": "Optional 1-based page. Omit both page and per to receive the complete list.",
+ "maximum": 10000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / perAdded value: +{
+ "description": "Optional items per page (default 20 when page is set, max 100).",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / next_pageAdded value: +{
+ "description": "The next page number; absent on the last page.",
+ "minimum": 2,
+ "type": "integer"
+}Output schema / properties / data / properties / pageAdded value: +{
+ "description": "The returned page (1-based).",
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / perAdded value: +{
+ "description": "Items per page.",
+ "minimum": 1,
+ "type": "integer"
+}list_stories5 fields changedInput schema / properties / pageAdded value: +{
+ "description": "Optional 1-based page. Omit both page and per to receive the complete list.",
+ "maximum": 10000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / perAdded value: +{
+ "description": "Optional items per page (default 20 when page is set, max 100).",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / next_pageAdded value: +{
+ "description": "The next page number; absent on the last page.",
+ "minimum": 2,
+ "type": "integer"
+}Output schema / properties / data / properties / pageAdded value: +{
+ "description": "The returned page (1-based).",
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / perAdded value: +{
+ "description": "Items per page.",
+ "minimum": 1,
+ "type": "integer"
+}list_tags5 fields changedInput schema / properties / pageAdded value: +{
+ "description": "Optional 1-based page. Omit both page and per to receive the complete list.",
+ "maximum": 10000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / perAdded value: +{
+ "description": "Optional items per page (default 20 when page is set, max 100).",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / next_pageAdded value: +{
+ "description": "The next page number; absent on the last page.",
+ "minimum": 2,
+ "type": "integer"
+}Output schema / properties / data / properties / pageAdded value: +{
+ "description": "The returned page (1-based).",
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / perAdded value: +{
+ "description": "Items per page.",
+ "minimum": 1,
+ "type": "integer"
+}search_articles5 fields changedInput schema / properties / pageAdded value: +{
+ "description": "Optional 1-based page. Omit both page and per to receive the complete list.",
+ "maximum": 10000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / perAdded value: +{
+ "description": "Optional items per page (default 20 when page is set, max 100).",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / next_pageAdded value: +{
+ "description": "The next page number; absent on the last page.",
+ "minimum": 2,
+ "type": "integer"
+}Output schema / properties / data / properties / pageAdded value: +{
+ "description": "The returned page (1-based).",
+ "minimum": 1,
+ "type": "integer"
+}Output schema / properties / data / properties / perAdded value: +{
+ "description": "Items per page.",
+ "minimum": 1,
+ "type": "integer"
+}get_article_details_by_slugs4 fields changedInput schema / properties / article_slugs / items / minLengthAdded value: +1Input schema / properties / article_slugs / minItemsAdded value: +1Input schema / properties / article_slugs / uniqueItemsAdded value: +trueOutput schema / properties / data / properties / hint / descriptionPrevious value: -"Guidance for the agent when no articles were found."New value: +"Guidance for the agent when no articles were found or some requested identifiers could not be resolved."get_article_details_by_uuids5 fields changedInput schema / properties / article_uuids / items / formatAdded value: +"uuid"Input schema / properties / article_uuids / items / minLengthAdded value: +1Input schema / properties / article_uuids / minItemsAdded value: +1Input schema / properties / article_uuids / uniqueItemsAdded value: +trueOutput schema / properties / data / properties / hint / descriptionPrevious value: -"Guidance for the agent when no articles were found."New value: +"Guidance for the agent when no articles were found or some requested identifiers could not be resolved."get_articles_by_tag2 fields changedInput schema / properties / tag / minLengthAdded value: +1Output schema / properties / data / properties / hint / descriptionPrevious value: -"Guidance for the agent when no articles were found."New value: +"Guidance for the agent when no articles were found or some requested identifiers could not be resolved."get_stories_by_category1 field changedInput schema / properties / category / minLengthAdded value: +1list_articles1 field changedInput schema / properties / category / minLengthAdded value: +1search_articles2 fields changedInput schema / properties / query / minLengthAdded value: +1Output schema / properties / data / properties / hint / descriptionPrevious value: -"Guidance for the agent when no articles were found."New value: +"Guidance for the agent when no articles were found or some requested identifiers could not be resolved."get_article_details_by_slugs9 fields changedInput schema / properties / article_slugs / descriptionPrevious value: -"A list of article slugs"New value: +"A list of 1–10 article slugs"Input schema / properties / article_slugs / items / maxLengthAdded value: +120Input schema / properties / article_slugs / maxItemsAdded value: +10Output schema / properties / articlesRemoved value: -{
- "items": {
- "properties": {
- "article_slug": {
- "type": "string"
- },
- "article_uuid": {
- "type": "string"
- },
- "author": {
- "type": "string"
- },
- "body_markdown": {
- "type": "string"
- },
- "category": {
- "type": "string"
- },
- "copyright_holder": {
- "type": "string"
- },
- "is_part_of_story": {
- "type": "string"
- },
- "last_article_update": {
- "type": "string"
- },
- "original_publishing_date": {
- "type": "string"
- },
- "related_articles_by_friendly_url": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "source_url": {
- "type": "string"
- },
- "summary": {
- "type": "string"
- },
- "tags": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / copyright_holderAdded value: +{
+ "type": "string"
+}Output schema / properties / dataAdded value: +{
+ "properties": {
+ "articles": {
+ "description": "The list of articles.",
+ "items": {
+ "properties": {
+ "article_slug": {
+ "type": "string"
+ },
+ "article_uuid": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "author": {
+ "type": "string"
+ },
+ "body_markdown": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "copyright_holder": {
+ "type": "string"
+ },
+ "is_part_of_story": {
+ "type": "string"
+ },
+ "last_article_update": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "original_publishing_date": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "related_articles_by_friendly_url": {
+ "description": "Slugs of related articles.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags for the article.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "source_url",
+ "copyright_holder",
+ "original_publishing_date",
+ "last_article_update",
+ "title",
+ "summary",
+ "article_slug",
+ "related_articles_by_friendly_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "hint": {
+ "description": "Guidance for the agent when no articles were found.",
+ "type": "string"
+ },
+ "invalid": {
+ "description": "List of requested identifiers that were invalid.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "not_found": {
+ "description": "List of requested identifiers that were not found.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of articles.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unavailable": {
+ "description": "List of requested identifiers that could not be fetched due to upstream issues.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "total",
+ "articles"
+ ],
+ "type": "object"
+}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / sourceAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]get_article_details_by_uuids9 fields changedInput schema / properties / article_uuids / descriptionAdded value: +"An array of 1–10 article UUIDs to fetch details for."Input schema / properties / article_uuids / items / maxLengthAdded value: +36Input schema / properties / article_uuids / maxItemsAdded value: +10Output schema / properties / articlesRemoved value: -{
- "items": {
- "properties": {
- "article_slug": {
- "type": "string"
- },
- "article_uuid": {
- "type": "string"
- },
- "author": {
- "type": "string"
- },
- "body_markdown": {
- "type": "string"
- },
- "category": {
- "type": "string"
- },
- "copyright_holder": {
- "type": "string"
- },
- "is_part_of_story": {
- "type": "string"
- },
- "last_article_update": {
- "type": "string"
- },
- "original_publishing_date": {
- "type": "string"
- },
- "related_articles_by_friendly_url": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "source_url": {
- "type": "string"
- },
- "summary": {
- "type": "string"
- },
- "tags": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / copyright_holderAdded value: +{
+ "type": "string"
+}Output schema / properties / dataAdded value: +{
+ "properties": {
+ "articles": {
+ "description": "The list of articles.",
+ "items": {
+ "properties": {
+ "article_slug": {
+ "type": "string"
+ },
+ "article_uuid": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "author": {
+ "type": "string"
+ },
+ "body_markdown": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "copyright_holder": {
+ "type": "string"
+ },
+ "is_part_of_story": {
+ "type": "string"
+ },
+ "last_article_update": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "original_publishing_date": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "related_articles_by_friendly_url": {
+ "description": "Slugs of related articles.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags for the article.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "source_url",
+ "copyright_holder",
+ "original_publishing_date",
+ "last_article_update",
+ "title",
+ "summary",
+ "article_slug",
+ "related_articles_by_friendly_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "hint": {
+ "description": "Guidance for the agent when no articles were found.",
+ "type": "string"
+ },
+ "invalid": {
+ "description": "List of requested identifiers that were invalid.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "not_found": {
+ "description": "List of requested identifiers that were not found.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of articles.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unavailable": {
+ "description": "List of requested identifiers that could not be fetched due to upstream issues.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "total",
+ "articles"
+ ],
+ "type": "object"
+}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / sourceAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]get_articles_by_tag6 fields changedInput schema / properties / tag / maxLengthAdded value: +60Output schema / properties / copyright_holderAdded value: +{
+ "type": "string"
+}Output schema / properties / dataAdded value: +{
+ "properties": {
+ "articles": {
+ "description": "The list of articles.",
+ "items": {
+ "properties": {
+ "article_slug": {
+ "type": "string"
+ },
+ "article_uuid": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "author": {
+ "type": "string"
+ },
+ "body_markdown": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "copyright_holder": {
+ "type": "string"
+ },
+ "is_part_of_story": {
+ "type": "string"
+ },
+ "last_article_update": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "original_publishing_date": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "related_articles_by_friendly_url": {
+ "description": "Slugs of related articles.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags for the article.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "source_url",
+ "copyright_holder",
+ "original_publishing_date",
+ "last_article_update",
+ "title",
+ "summary",
+ "article_slug",
+ "related_articles_by_friendly_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "hint": {
+ "description": "Guidance for the agent when no articles were found.",
+ "type": "string"
+ },
+ "invalid": {
+ "description": "List of requested identifiers that were invalid.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "not_found": {
+ "description": "List of requested identifiers that were not found.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of articles.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unavailable": {
+ "description": "List of requested identifiers that could not be fetched due to upstream issues.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "total",
+ "articles"
+ ],
+ "type": "object"
+}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / sourceAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]get_stories_by_category6 fields changedInput schema / properties / category / maxLengthAdded value: +50Output schema / properties / copyright_holderAdded value: +{
+ "type": "string"
+}Output schema / properties / dataAdded value: +{
+ "properties": {
+ "stories": {
+ "description": "The list of stories.",
+ "items": {
+ "properties": {
+ "articles": {
+ "description": "Articles in this story.",
+ "items": {
+ "properties": {
+ "article_slug": {
+ "type": "string"
+ },
+ "article_uuid": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "story_slug": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "article_slug",
+ "article_uuid",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": "string"
+ },
+ "last_story_update": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "original_publishing_date": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "story_slug": {
+ "type": "string"
+ },
+ "story_uuid": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "original_publishing_date",
+ "last_story_update",
+ "title",
+ "summary",
+ "story_slug",
+ "source_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of stories.",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "stories"
+ ],
+ "type": "object"
+}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / sourceAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]list_articles7 fields changedInput schema / properties / categoryAdded value: +{
+ "description": "Optional category filter to restrict articles to one topic (foundation, sense, discover, focus, deliver).",
+ "enum": [
+ "foundation",
+ "sense",
+ "discover",
+ "focus",
+ "deliver"
+ ],
+ "maxLength": 50,
+ "type": "string"
+}Input schema / properties / include_summaryAdded value: +{
+ "description": "When true, includes the 1-2 sentence summary for each article. Defaults to false for a lean compact index.",
+ "type": "boolean"
+}Output schema / properties / dataAdded value: +{
+ "properties": {
+ "articles": {
+ "description": "The list of article overviews.",
+ "items": {
+ "properties": {
+ "article_slug": {
+ "type": "string"
+ },
+ "article_uuid": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "story_slug": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "article_slug",
+ "article_uuid",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of articles.",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "articles"
+ ],
+ "type": "object"
+}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / source_friendly_urlRemoved value: -{
- "type": "string"
-}Output schema / properties / storiesRemoved value: -{
- "items": {
- "properties": [],
- "required": [],
- "type": "object"
- },
- "type": "array"
-}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]list_categories6 fields changedOutput schema / properties / categoriesRemoved value: -{
- "items": {
- "properties": {
- "category": {
- "type": "string"
- },
- "details": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "order": {
- "type": "integer"
- },
- "summary": {
- "type": "string"
- }
- },
- "required": [
- "category",
- "summary"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / dataAdded value: +{
+ "properties": {
+ "categories": {
+ "description": "The list of categories.",
+ "items": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "details": {
+ "type": "string"
+ },
+ "id": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "order": {
+ "description": "Display order of the category.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "category",
+ "summary"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of categories.",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "categories"
+ ],
+ "type": "object"
+}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / source_friendly_urlRemoved value: -{
- "type": "string"
-}Output schema / properties / totalRemoved value: -{
- "type": "integer"
-}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]list_glossary6 fields changedOutput schema / properties / dataAdded value: +{
+ "properties": {
+ "entries": {
+ "description": "The list of glossary entries.",
+ "items": {
+ "properties": {
+ "createdAt": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "definition": {
+ "type": "string"
+ },
+ "id": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "term": {
+ "type": "string"
+ },
+ "updatedAt": {
+ "format": "date-time",
+ "type": "string"
+ }
+ },
+ "required": [
+ "term",
+ "definition",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of glossary entries.",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "entries"
+ ],
+ "type": "object"
+}Output schema / properties / entriesRemoved value: -{
- "items": {
- "properties": {
- "createdAt": {
- "type": "string"
- },
- "definition": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "status": {
- "type": "string"
- },
- "term": {
- "type": "string"
- },
- "updatedAt": {
- "type": "string"
- }
- },
- "required": [
- "term",
- "definition"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / source_friendly_urlRemoved value: -{
- "type": "string"
-}Output schema / properties / totalRemoved value: -{
- "type": "integer"
-}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]list_stories5 fields changedOutput schema / properties / dataAdded value: +{
+ "properties": {
+ "stories": {
+ "description": "The list of stories.",
+ "items": {
+ "properties": {
+ "articles": {
+ "description": "Articles in this story.",
+ "items": {
+ "properties": {
+ "article_slug": {
+ "type": "string"
+ },
+ "article_uuid": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "story_slug": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "article_slug",
+ "article_uuid",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": "string"
+ },
+ "last_story_update": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "original_publishing_date": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "story_slug": {
+ "type": "string"
+ },
+ "story_uuid": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "original_publishing_date",
+ "last_story_update",
+ "title",
+ "summary",
+ "story_slug",
+ "source_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of stories.",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "stories"
+ ],
+ "type": "object"
+}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / source_friendly_urlRemoved value: -{
- "type": "string"
-}Output schema / properties / storiesRemoved value: -{
- "items": {
- "properties": {
- "articles": {
- "items": {
- "properties": {
- "article_slug": {
- "type": "string"
- },
- "article_uuid": {
- "type": "string"
- },
- "last_article_update": {
- "type": "string"
- },
- "original_publishing_date": {
- "type": "string"
- },
- "summary": {
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [],
- "type": "object"
- },
- "type": "array"
- },
- "last_story_update": {
- "type": "string"
- },
- "original_publishing_date": {
- "type": "string"
- },
- "story_slug": {
- "type": "string"
- },
- "story_uuid": {
- "type": "string"
- },
- "summary": {
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [],
- "type": "object"
- },
- "type": "array"
-}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]list_tags6 fields changedOutput schema / properties / dataAdded value: +{
+ "properties": {
+ "tags": {
+ "description": "The list of tags.",
+ "items": {
+ "properties": {
+ "articleCount": {
+ "description": "Number of articles with this tag.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "articles": {
+ "description": "UUIDs of articles with this tag.",
+ "items": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "tag": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tag"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of tags.",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "tags"
+ ],
+ "type": "object"
+}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / source_friendly_urlRemoved value: -{
- "type": "string"
-}Output schema / properties / tagsRemoved value: -{
- "items": {
- "properties": {
- "articleCount": {
- "type": "integer"
- },
- "articles": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "id": {
- "type": "string"
- },
- "tag": {
- "type": "string"
- }
- },
- "required": [
- "tag"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / totalRemoved value: -{
- "type": "integer"
-}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]search_articles7 fields changedInput schema / properties / query / maxLengthAdded value: +200Output schema / properties / articlesRemoved value: -{
- "items": {
- "properties": {
- "article_slug": {
- "type": "string"
- },
- "article_uuid": {
- "type": "string"
- },
- "author": {
- "type": "string"
- },
- "category": {
- "type": "string"
- },
- "copyright_holder": {
- "type": "string"
- },
- "is_part_of_story": {
- "type": "string"
- },
- "last_article_update": {
- "type": "string"
- },
- "original_publishing_date": {
- "type": "string"
- },
- "related_articles_by_friendly_url": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "source_url": {
- "type": "string"
- },
- "summary": {
- "type": "string"
- },
- "tags": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [],
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / copyright_holderAdded value: +{
+ "type": "string"
+}Output schema / properties / dataAdded value: +{
+ "properties": {
+ "articles": {
+ "description": "The list of articles.",
+ "items": {
+ "properties": {
+ "article_slug": {
+ "type": "string"
+ },
+ "article_uuid": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "author": {
+ "type": "string"
+ },
+ "body_markdown": {
+ "type": "string"
+ },
+ "category": {
+ "type": "string"
+ },
+ "copyright_holder": {
+ "type": "string"
+ },
+ "is_part_of_story": {
+ "type": "string"
+ },
+ "last_article_update": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "original_publishing_date": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "related_articles_by_friendly_url": {
+ "description": "Slugs of related articles.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "description": "Tags for the article.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "source_url",
+ "copyright_holder",
+ "original_publishing_date",
+ "last_article_update",
+ "title",
+ "summary",
+ "article_slug",
+ "related_articles_by_friendly_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "hint": {
+ "description": "Guidance for the agent when no articles were found.",
+ "type": "string"
+ },
+ "invalid": {
+ "description": "List of requested identifiers that were invalid.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "not_found": {
+ "description": "List of requested identifiers that were not found.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "The total number of articles.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unavailable": {
+ "description": "List of requested identifiers that could not be fetched due to upstream issues.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "total",
+ "articles"
+ ],
+ "type": "object"
+}Output schema / properties / retrieved_atAdded value: +{
+ "format": "date-time",
+ "type": "string"
+}Output schema / properties / sourceAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[]New value: +[
+ "source",
+ "copyright_holder",
+ "retrieved_at",
+ "data"
+]list_categories5 fields changedOutput schema / properties / categoriesAdded value: +{
+ "items": {
+ "properties": {
+ "category": {
+ "type": "string"
+ },
+ "details": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "order": {
+ "type": "integer"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "category",
+ "summary"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / copyright_holderAdded value: +{
+ "type": "string"
+}Output schema / properties / sourceAdded value: +{
+ "type": "string"
+}Output schema / properties / source_friendly_urlAdded value: +{
+ "type": "string"
+}Output schema / properties / totalAdded value: +{
+ "type": "integer"
+}list_glossarylist_tagsget_article_details_by_slugsget_article_details_by_uuidsget_articles_by_tagget_stories_by_categorylist_articleslist_categorieslist_storiessearch_articles
Add one secure layer between your agents and this server.