Live Academy learning and search. OAuth adds scoped personal tools. Explicit --offline snapshot.
Scored across 29 tools
Multiple tool pairs are functionally indistinguishable except for a deprecation note: academy_lessons/academy_legacy_lessons, academy_levels/academy_legacy_levels, academy_start/academy_welcome, academy_teach/academy_tutor_context, and academy_search/search. academy_glossary, academy_concepts, and academy_glossary_term also overlap heavily, and fetch duplicates academy_lesson. The 'deprecated' labels help, but an agent still has to reason about which twin to call, and several descriptions repeat verbatim.
Most tools follow a snake_case academy_* prefix with a readable singular=read / plural=list convention (academy_lesson vs academy_lessons, academy_path vs academy_paths). However, unprefixed generic names fetch and search break the namespace, and several 'read' tools drop any verb (academy_lesson, academy_module, academy_path) while others use an imperative (academy_suggest, academy_search). The 'legacy_' infix further muddies the pattern.
29 tools is heavy for a public content-browsing academy, and roughly six of them are explicitly deprecated aliases retained for one version, inflating the surface to ~35 effective choices. The core domain (paths, modules, lessons, library, recipes, playbooks, prompts, glossary) could be covered by well under 20 tools. Duplicated pairs like start/welcome and search/academy_search add count without adding capability.
The read-only public surface is broad: paths, modules, lessons, library, recipes, playbooks, prompts, glossary, search, suggestions, and a premium catalog/preview pair. Gaps remain in learning lifecycle operations — no progress tracking, no lesson completion or exercise submission, and premiumCatalog/premiumPreview have no accompanying purchase or entitlement tool. Deprecated alias duplication also wastes surface that could serve missing operations.
Read the coaching entry point without unconfirmed prices or durations.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and closed-world, so the safety profile is covered structurally. The description adds one genuinely new behavioral fact: the response deliberately omits unconfirmed prices and durations. That is useful but thin for a tool whose content is otherwise undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the verb and the key content caveat front-loaded; there is no filler. It is efficient rather than padded, though the brevity shades into under-specification.
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, but the description still leaves the agent unable to tell this read apart from academy_start, academy_welcome, or academy_tutor_context. For a zero-required-parameter entry-point tool in a crowded academy namespace, that distinction is the missing piece and it 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% and both parameters (locale, idempotencyKey) are fully described as transport-level concerns in the schema itself. The description contributes nothing about parameters, so the baseline of 3 applies rather than anything higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a verb ('Read') and a nominal resource ('the coaching entry point'), so it is not a tautology of the name. However, 'coaching entry point' is ambiguous and is not distinguished from near-neighbours like academy_start, academy_welcome, academy_teach, or academy_tutor_context, leaving the agent to guess which entry point this is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus the many sibling tools, no prerequisites, and no exclusions. The only implicit guidance is the hint that prices and durations are filtered out, which implies a pre-purchase context but never says so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse and search public concepts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| cursor | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | 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 fully covered structurally. The description adds only the word 'public', with no disclosure of pagination behavior, result ordering, or what 'public' excludes — minimal added value beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single six-word sentence with no filler and the purpose front-loaded, which is structurally clean. However, the brevity crosses into under-specification given five parameters and a large sibling set.
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 shape need not be explained, but the description leaves the three undocumented parameters, the browse-vs-search distinction, and the tool's relationship to academy_search and academy_glossary unaddressed. For a zero-required-param listing tool with paging, this is not enough to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%: locale and idempotencyKey are documented in the schema, but limit, query, and cursor have no description anywhere. The tool description never mentions any parameter, so it does not compensate for the gap — notably the cursor/limit pagination contract and the query syntax are entirely unspecified.
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 verb pair 'Browse and search' plus the resource 'public concepts' gives a workable gist, but 'concepts' is undefined against a crowded sibling set containing academy_glossary, academy_glossary_term, academy_search, and academy_library. Nothing in the sentence tells an agent which of those holds concept data versus glossary terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool rather than academy_search, academy_glossary, or academy_suggest, and no indication of when to browse (cursor paging) versus search (query). The agent must infer the distinction from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse safe public glossary concepts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only the fuzzy qualifier "safe public" and says nothing about pagination behavior (limit/cursor), locale handling, or result ordering — context an agent browsing a catalog would actually need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single efficient sentence with zero filler, which is structurally sound. But the terseness crosses into under-specification — the one sentence carries no operational detail an agent could act on.
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. Still, for a paginated browse tool with four parameters and a locale enum, the description omits how paging works, what "public" excludes, and how it relates to academy_glossary_term — leaving the definition incomplete for correct invocation.
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 50%: locale and idempotencyKey are documented in the schema, but limit and cursor have no descriptions anywhere. The description contributes no parameter meaning at all, so it fails to compensate for the uncovered pagination parameters.
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 verb ("Browse") and a resource ("glossary concepts"), so the basic operation is inferable. However, "safe public" is vague marketing language, and nothing distinguishes it from siblings like academy_glossary_term or academy_concepts, leaving the agent to guess which is the list vs. the detail view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of alternatives, and no exclusions. The agent is not told to use this for listing terms versus academy_glossary_term for fetching a single one, even though both exist in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a public glossary term without internal recipe references.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | 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 one real behavioral fact — results are the public projection, stripped of internal recipe references — but says nothing about missing-term behavior or how locale affects the lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with zero filler and the distinguishing qualifier placed immediately after the verb. It is efficient, though so terse that it borders on under-specification rather than tightness.
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 are covered, and annotations handle safety. What remains unaddressed is meaningful for a 3-parameter lookup tool: what 'public' excludes relative to the premium/recipe siblings, and whether a missing term is an error or an empty result.
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?
With 67% schema coverage and clear schema descriptions for locale ('transport locale; not a service input field') and idempotencyKey, the schema does most of the work. The description adds no meaning to 'term' itself — no format, case-sensitivity, or how the pattern constraint relates to lookup.
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 ('Read a public glossary term') plus a scope qualifier that separates it from internal/recipe-facing data. It does not name the closest sibling (academy_glossary, presumably the listing version), so an agent still has to infer the singular-vs-collection split.
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 phrase 'public glossary term without internal recipe references' implies the lookup case and hints the tool omits non-public content, but it never says when to prefer this over academy_glossary, academy_recipe, or academy_search, nor what to do if the term is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deprecated compatibility listing of original lessons in one numbered level.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false, so safety behavior is covered. The description adds the genuinely useful fact that this is a deprecated compatibility shim, but says nothing about whether output matches the current lessons endpoint or what "original" excludes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact phrase with the most decision-relevant token ("Deprecated") front-loaded and no filler. It is arguably over-compressed, stacking legacy/compatibility/original/level into one clause at some cost in 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?
An output schema exists, so return values need no explanation, and parameters are largely documented in the schema. For a deprecated read-only listing the description covers the essentials: what it returns, its scope, and its lifecycle status.
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 67%; locale and idempotencyKey already carry their own descriptions and are explicitly marked transport-only. The description confirms the level filter ("one numbered level") but adds no detail on the 1–6 range or on how level maps to the legacy numbering. Baseline 3 fits where the schema does most of the work.
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?
"Deprecated compatibility listing of original lessons in one numbered level" names a concrete resource (lessons) and scope (a single numbered level), plus the key status marker "deprecated." It does not name or distinguish itself from the near-identical sibling academy_lessons, so an agent must still infer which listing to prefer.
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?
"Deprecated compatibility" implies a when-not-to-use signal and hints that a current alternative exists, but the description never names that alternative (academy_lessons, academy_legacy_levels) or states under what conditions this tool is still correct to call. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deprecated compatibility view of original numbered content levels; use paths for current learning paths.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds the non-obvious fact that the data is a deprecated compatibility layer rather than the canonical source, which is real behavioral context an agent would otherwise miss.
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 sentence with zero waste, front-loading the deprecation warning and following with the alternative in one clause.
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, full annotations and complete parameter documentation, the only missing piece was deprecation status and the redirect to current paths, both of which are supplied. Nothing material is absent for a zero-required-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (locale, idempotencyKey) are transport-level fields fully documented in the schema. The description adds nothing beyond that, 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 identifies a specific resource ('original numbered content levels') and its status as a deprecated compatibility view, which is more than a restatement of the name. It does not name a retrieval verb explicitly, but 'view' implies read access and the sibling differentiation is present.
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 the alternative explicitly ('use paths for current learning paths') and signals the deprecated/legacy condition that selects against this tool. The exclusions are clear, though it does not spell out any positive scenario in which this tool should still be called.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a public lesson using its unambiguous level and slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| level | Yes | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so safety behavior is well covered. The description adds that the lesson is public and that level and slug together identify it unambiguously, but does not describe errors, access restrictions, or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted wording. It immediately conveys the operation and the identifier method.
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?
The tool has rich annotations and an output schema, so return values and safety do not need to be described. However, the description is still thin on sibling differentiation and level semantics, which an agent needs in order to select and call the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with slug and level lacking descriptive documentation in the schema. The description mentions both required parameters but adds little meaning beyond the schema constraints, and it does not explain what level values represent or how locale/idempotencyKey behave beyond their existing schema notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: read a public lesson. It also identifies the key lookup method, level plus slug. It does not explicitly distinguish itself from sibling tools such as academy_lessons or academy_legacy_lessons, so it falls short of a 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?
The description implies retrieval by level and slug, but gives no explicit guidance on when to use this tool instead of academy_lessons, academy_legacy_lessons, academy_search, or premium-related siblings. The word 'public' hints at scope, but the alternatives and exclusions are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deprecated compatibility listing of original lessons in one numbered level. (Deprecated alias for academy_legacy_lessons; retained for one version.)
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description's genuine addition is lifecycle information (deprecation, one-version retention); it says nothing about what happens when level is omitted or how results are bounded.
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, deprecation status front-loaded, zero filler. The size is proportionate to a deprecated compatibility shim.
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 no explanation, and the tool is a read-only listing. However, optionality of level and the normalization/validation behavior mentioned only in the schema description leave the description a step short for correct invocation.
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 67%: locale and idempotencyKey are documented as transport-only fields in the schema itself. The description's "one numbered level" gives the level parameter meaning, but it never addresses that level is optional (all levels? default level?) — the one semantic gap an agent would actually hit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete scope ("listing of original lessons in one numbered level") and immediately identifies itself as a deprecated alias of the sibling academy_legacy_lessons, so an agent can place it against academy_lesson/academy_levels. It stops short of a crisp verb+resource framing because "listing" is nominalized and the deprecation notice overshadows what it actually returns.
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 signals the preferred alternative by naming academy_legacy_lessons and warning that this shim is "retained for one version," which is usable routing guidance. It does not say positively when this tool is still the right call (i.e., legacy clients pinned to the old name).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deprecated compatibility view of original numbered content levels; use paths for current learning paths. (Deprecated alias for academy_legacy_levels; retained for one version.)
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds the crucial lifecycle fact that this is deprecated and 'retained for one version'. It doesn't say what deprecation means at runtime (warnings, empty results), but the sunset horizon is the key context an agent needs.
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 tightly packed sentences: the deprecation status and the redirect to paths come first, with no filler. Every clause carries decision-relevant 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 zero-required-parameter deprecated alias with full annotations and an output schema, the description covers everything an agent needs: what it is, that it's going away, and where to go instead.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (locale, idempotencyKey) are documented as transport-level fields, so the description carries no burden here. It adds no meaning beyond the schema, which is the expected 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?
Identifies the resource ('original numbered content levels') and its status as a deprecated compatibility view, and explicitly contrasts it with 'paths for current learning paths'. It falls short of a crisp verb+resource statement (the actual operation — list vs. fetch — is only implied), but an agent can still distinguish it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit directive: don't use this, use paths for current learning paths, and names academy_legacy_levels as the canonical tool it aliases. Both the when-not and the alternative are stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse public library metadata, filtered by type and access.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| access | No | ||
| cursor | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| pathId | No | ||
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds only that the catalog is public metadata; it omits pagination/cursor behavior and the meaning of the transport-only params, which matter for a browse operation that could return a large catalog.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with zero waste, front-loading the verb and resource. It is arguably over-compressed for a 7-parameter tool, but nothing is redundant.
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 no explanation, but for a filterable, paginated catalog browse the description leaves cursor pagination, page size defaults, and the pathId dimension entirely unexplained. Given 7 parameters and low schema coverage, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% across 7 parameters, so the description must compensate. It mentions only 'type' and 'access' filtering and says nothing about limit, cursor pagination, pathId, or the transport-only locale/idempotencyKey fields.
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 ('Browse public library metadata') plus the filtering dimensions ('type and access'), which is clear on its own. It implicitly contrasts with the many single-item siblings (academy_prompt, academy_playbook) and the search sibling, but never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Browse' versus the sibling 'academy_search' hints at enumeration-style usage, and 'public' hints at excluding the premium siblings, but neither condition is stated. No when-not guidance or prerequisite is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an existing module and its ordered published content; technical content containers are labelled.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | MCP transport locale; not a service input field. | de |
| pathId | Yes | ||
| moduleId | Yes | ||
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: content is returned in published order and technical containers are labelled. It does not discuss pagination or what happens for unpublished/missing modules.
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 12-word sentence with the primary action front-loaded and no filler. The trailing clause about labelled technical containers is slightly opaque but does carry 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 shape need not be explained, and annotations cover safety. What remains thin is routing guidance among the many academy siblings and the meaning of the two required identifiers, which leaves the definition adequate but not fully self-sufficient.
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%: locale and idempotencyKey are self-documented, but pathId and moduleId carry no descriptions, only enums and a pattern. The description mentions no parameters at all, so it does nothing to compensate for the undocumented required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (read) and resource (module) plus what is returned: its ordered published content. It is distinguishable from content-fetching siblings like academy_lesson or academy_path, though it stops short of clarifying the module-vs-lesson-vs-level hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no exclusion against any of the two dozen academy_* siblings. An agent must infer that this is the module-level read versus academy_lesson or academy_paths, with nothing in the description to confirm that choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current learning path, ordered steps and explicit module mapping status.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | MCP transport locale; not a service input field. | de |
| pathId | Yes | ||
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds that the response includes ordered steps and module mapping status, which is useful, but says nothing about errors for unknown pathIds or how locale/idempotencyKey affect 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?
One front-loaded sentence with no filler. It is efficient, though the final clause about module mapping status is dense enough to need unpacking.
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, and annotations cover the safety profile. However, for a required enum-keyed parameter the description gives no guidance about which pathId to choose or how locale interacts, leaving a modest gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with locale and idempotencyKey documented in-schema; only pathId (enum of four slugs) lacks any schema description. The description does not explain pathId options or what a 'current' path means, so it adds nothing beyond the schema, warranting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb (read) and resource (learning path) plus the payload contents: ordered steps and module mapping status. This distinguishes it from the sibling academy_paths, which lists paths, though 'explicit module mapping status' is somewhat jargon-heavy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'current learning path' suggests retrieving one path by its pathId, as opposed to academy_paths for listing. No explicit when-to-use, when-not, or named alternatives (academy_module, academy_levels) are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the four learning paths with confirmed original references.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | 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 the notion of a curated set ('confirmed original references'), hinting at filtering, but never explains what that means or how many/why four.
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 front-loaded sentence with no padding. Slight loss because the trailing qualifier is ambiguous rather than informative.
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?
Output schema handles return values and annotations handle safety, so the remaining burden is small. Still, the description leaves the agent unsure what makes a reference 'confirmed original' and how this listing relates to academy_path.
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 (locale, idempotencyKey) are explicit transport-level fields documented in the schema, so baseline 3 applies. The description adds nothing about parameters, which is acceptable here.
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 ('learning paths'), which distinguishes it from academy_path (singular detail) and academy_levels. The qualifier 'with confirmed original references' is unexplained jargon, but the core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus academy_path, academy_levels, or academy_start. It implies a catalog/overview listing, but the agent must infer that from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an existing public playbook.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds only that the playbook must exist and be public; it says nothing about authorization, not-found behavior, or response shape. A 3 is appropriate because the annotations carry most of the behavioral burden.
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 sentence with no wasted words, and the core action is front-loaded. It is appropriately terse for a simple read-by-ID tool, though it could have added the list-vs-single routing hint in the same breath.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations cover safety. However, the description omits the distinction from academy_playbooks and does not clarify what the required id refers to. For a simple retrieval tool this is minimally adequate but leaves clear gaps.
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 67%, with locale and idempotencyKey documented as transport fields but the required id parameter lacking a description beyond its pattern. The tool description adds no further meaning about the id format or locale selection. Baseline 3 reflects that the schema does most of the work while the primary identifier remains semantically thin.
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: 'Read' an 'existing public playbook.' This distinguishes it from write operations and implies the plural sibling academy_playbooks is for listing, though the description never names that alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives no explicit guidance on when to use this tool versus academy_playbooks or academy_search. The reader can infer it retrieves a single playbook by ID, but there are no stated preconditions, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List existing public playbooks, optionally filtered by their actual category.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| category | No | ||
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description contributes only the "public" visibility scope; it says nothing about pagination behavior despite limit/cursor parameters, nor about locale affecting 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 front-loaded sentence with the resource and filter stated up front and no filler. It is efficient, though its brevity comes partly at the cost of the missing pagination and locale context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. However, for a 5-parameter tool with 40% schema coverage, the description leaves pagination, the locale default of "de", and the meaning of "actual category" unexplained, which is not enough for an agent to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%: only locale and idempotencyKey carry schema descriptions, while limit, cursor, and category are undocumented. The description mentions the category filter but adds no semantics for it ("actual category" is ambiguous), and it does not explain limit/cursor pagination at all, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List existing public playbooks") plus a scope qualifier (public) and an optional filter (category). The plural form implicitly separates it from the singular academy_playbook sibling, but no sibling is named, so differentiation is inference-based rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Optionally filtered by their actual category" implies a browse-or-filter usage pattern, but there is no statement of when to prefer this over academy_search, academy_playbook, or academy_paths. The agent must infer the browsing scenario from the plural resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an approved public prompt by identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful constraint that only approved public prompts are readable, but says nothing about not-found behavior, auth requirements, or rate limits beyond that.
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 front-loaded sentence with no filler. Every word contributes: verb, resource, qualifier, and selection mechanism.
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 and rich annotations already present, this simple read tool does not need much more prose. The description is sufficient for correct invocation, though it could note the approved/public failure mode to be 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 67%, with id constraints, a locale enum, and an idempotencyKey description already documented structurally. The description reinforces that the operation is driven by the identifier but adds no meaning about locale or retry-key semantics, so it does not materially improve parameter understanding.
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 clear verb and resource: 'Read an approved public prompt by identifier.' This tells an agent it retrieves a single prompt, which is distinguishable from the likely list-oriented sibling academy_prompts, though it does not explicitly name or contrast that sibling.
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?
'By identifier' implies you need a known ID and that this is a lookup rather than a discovery call, but the description never states when to prefer this over academy_prompts or academy_search, nor what to do when the prompt is not approved or public.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List approved prompts; an unpopulated catalog is empty.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | 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 fully covered structurally. The description adds one genuinely useful behavioral fact — that an empty result is a valid state rather than an error — but says nothing about pagination behavior, default/max page size, or filtering semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the primary action front-loaded and the caveat second. No filler, no repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and all parameters are optional. But for a paginated list tool the missing pieces — how to advance with cursor, what limit defaults to, whether results can be filtered by locale, and how it differs from academy_prompt — leave real gaps for an agent that must 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 only 50%: limit and cursor carry no schema descriptions, and the description adds zero meaning for either. Cursor-based pagination is exactly the concept an agent needs explained, and the description is silent on it while consuming its one clause on the empty-case note.
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?
"List approved prompts" gives a specific verb (list) and a scoped resource (approved prompts), which is clearer than a bare name restatement. However, it never distinguishes itself from the singular sibling academy_prompt or from academy_search, which an agent must choose among in a 28-tool namespace.
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 only guidance is "an unpopulated catalog is empty," which addresses result interpretation, not tool selection. There is no statement of when to call this versus academy_prompt (single fetch) or academy_search, and no mention of prerequisites such as authentication or catalog population.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a public recipe; private recipes remain undiscoverable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the description does not need to repeat that. It adds a meaningful access constraint by stating that only public recipes are readable and private recipes remain undiscoverable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. The key scope constraint is stated immediately.
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 and annotations cover the safety profile, so return behavior and mutation risk need not be explained. The description covers public/private access but leaves the required id semantics and sibling alternatives implicit.
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 67%; the transport parameters are documented, but the required 'id' parameter has no schema description. The description only implies that 'id' identifies a public recipe, adding little beyond the schema pattern.
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 ('Read a public recipe') and clarifies that private recipes are excluded. It does not explicitly distinguish this single-recipe reader from the sibling list tool academy_recipes, but the scope is otherwise 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?
It implies usage for public recipes and warns that private recipes cannot be discovered, which is useful context. However, it does not name alternatives such as academy_recipes or academy_search or explain when to choose this tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public free recipes, optionally filtered by their actual phase from 1 to 16.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| phase | No | ||
| cursor | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the scope constraint ('public free') and phase range, but says nothing about pagination behavior for the 'cursor'/'limit' parameters.
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 front-loaded sentence with zero filler that states resource, scope, and the one filter upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations cover safety. However, for a paginated list tool with a cursor the description omits any pagination guidance, leaving a notable gap given sub-50% parameter coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description should compensate for the undocumented 'limit', 'phase', and 'cursor' parameters. It only restates 'phase from 1 to 16', which the schema already constrains via min/max, and says nothing about pagination or result sizing via limit/cursor.
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 uses a clear verb+resource ('List public free recipes') and adds scoping ('public free') plus a filter dimension. It lets an agent distinguish a list operation from the singular 'academy_recipe' sibling implicitly, though it never names the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use/when-not guidance and no mention of the 'academy_recipe' sibling that presumably fetches a single recipe. The only hint is that filtering by phase is optional, from which usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search actual lessons and public library content with stable identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| query | Yes | ||
| cursor | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| pathId | No | ||
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | 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 little beyond them — the phrase "stable identifiers" hints that results carry durable IDs, but nothing is said about pagination via cursor, result ranking, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is efficient, though the brevity shades into under-specification for a seven-parameter tool.
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 seven parameters, a low-coverage schema, and a large sibling set of overlapping search/list tools, the description should route the agent and explain filtering and pagination. It does neither; the existence of an output schema excuses return-value detail but not the routing and parameter gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, and the description compensates for none of it: `query` syntax/length, the `type` enum (including "lesson"), `limit`, `cursor`, and `pathId` are all undocumented. Only `locale` and `idempotencyKey` carry schema descriptions, and the tool text says nothing about any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Search") and resource scope ("lessons and public library content"), which is more precise than the name alone. However "stable identifiers" is unexplained and it doesn't distinguish itself from the sibling `search` or `academy_lessons`, so an agent can't tell why to pick this over them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus `search`, `academy_lessons`, `academy_library`, or `academy_suggest`, all of which plausibly overlap. Usage is only implied by the word "Search"; no exclusions or routing conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the available learning paths and public starting links.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | 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 fully covered without the description. The description adds only the implicit notion that this returns 'public' (unauthenticated) content, and says nothing about pagination, result size, or what a 'starting link' is.
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, front-loaded sentence with no filler or repetition. It is arguably under-specified rather than padded, so it earns credit for economy but not top marks for usefulness-per-word.
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 and annotations covering safety, the description does not need to explain return values or reversibility. What remains missing is routing context: why an agent should call this instead of academy_paths, academy_welcome, or academy_library, which is the main gap for a 28-sibling namespace.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema itself explains that both parameters (locale, idempotencyKey) are transport-level rather than service inputs. The description adds no parameter detail, but with a complete and self-explaining schema the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete verb+resource pair ("Read the available learning paths and public starting links"), which is far more informative than the opaque name 'academy_start'. However, it does not distinguish itself from siblings like academy_paths, academy_path, or academy_welcome, so an agent must guess whether this is the entry-point aggregate or a duplicate of academy_paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, when not to, or which sibling to prefer. The word "start" suggests an entry-point role, but the description never confirms that or points to alternatives such as academy_welcome or academy_paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest matching library items with reasons; the supplied profile is never saved.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | MCP transport locale; not a service input field. | de |
| profile | Yes | ||
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-obvious context — the supplied profile is not persisted — which an agent could not infer from the annotations. It says nothing about matching quality, result size, or latency expectations.
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 compact clauses, front-loaded with the action and followed by the privacy caveat; no wasted words. It is arguably too terse rather than padded, but structurally sound.
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 no explanation, but for a tool taking a nested profile object in a family of 28 similarly named tools the description omits too much. It gives no sense of how suggestions differ from academy_search results, nor what makes the profile well-formed.
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 single required parameter `profile` is a nested object whose sub-fields (goals, constraints, capabilities, environment) have no schema descriptions at all, and the description adds nothing about what belongs in them. Only the transport-level params (locale, idempotencyKey) are documented in the schema, so the semantically important parameter remains undefined.
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 ("Suggest matching library items") plus a differentiator ("with reasons"). However it never distinguishes itself from sibling tools like academy_search or academy_library, so an agent cannot tell from the description alone which retrieval entry point to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no named alternative among the ~28 academy_* siblings. The only conditional information is a privacy constraint ("never saved"), which is not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read teaching steps drawn from the actual lesson headings and exercise.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| level | Yes | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint, idempotentHint, non-destructive behavior, and a closed-world scope, and the description's "Read" is consistent with that safety profile. The description adds only that the content is derived from lesson headings and exercises; it does not disclose pagination, caching, authorization requirements, or whether a missing lesson produces an error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, so it is structurally efficient. It is arguably too terse for a four-parameter tool, but the text itself contains no wasted statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description leaves major agent needs unaddressed: when to choose this tool over academy_lesson, what slug and level mean, and what kind of teaching steps are returned. For a tool in a dense sibling namespace with partial schema coverage, this is materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the two required parameters, slug and level, have no descriptions in the schema. The description does not mention either parameter, so it does not compensate for the missing semantics around what slug identifies or how level constrains the returned teaching steps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb ("Read") and an approximate resource ("teaching steps drawn from the actual lesson headings and exercise"), so an agent can infer the general intent. However, it does not clarify whether this tool fetches existing lesson content, generates a teaching sequence, or returns something else, nor does it distinguish itself from close siblings such as academy_lesson or academy_tutor_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives. With many sibling tools covering lessons, levels, and tutoring, an agent has no explicit signal about when academy_teach is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read teaching steps drawn from the actual lesson headings and exercise. (Deprecated alias for academy_teach; retained for one version.)
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ||
| level | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety and side-effect behavior is fully covered structurally. The description's only genuine addition is lifecycle status — deprecated, survives one version — which is useful but thin; it says nothing about validation, normalization, or failure behavior beyond what the schema description carries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the functional summary first and the deprecation caveat immediately after. Nothing could be cut without losing 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, and the annotation set covers safety. However, for a tool with 4 params at 50% description coverage, the definition leaves the meaning of slug and level unresolved and does not state whether this alias behaves identically to academy_teach.
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%: locale and idempotencyKey are documented in the schema as transport fields, while slug and level have no description anywhere. The tool description offers no compensating detail about what slug refers to (lesson path? module?) or how level 1-6 interacts with it, leaving two core parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource ('Read teaching steps drawn from the actual lesson headings and exercise') and explicitly identifies itself as a deprecated alias of academy_teach, which distinguishes it from the roughly 28 siblings. It stops short of 5 only because the underlying subject matter ('teaching steps') stays somewhat abstract without reference to 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?
The deprecation note ('retained for one version') strongly signals that academy_teach is the preferred tool, which functions as routing guidance. It never explicitly says 'use academy_teach instead', so the agent must infer the switch rather than being told outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the available learning paths and public starting links. (Deprecated alias for academy_start; retained for one version.)
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | 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 fully covered structurally. The description's added value is the deprecation lifecycle note, which annotations cannot express, but it says nothing about legacy field normalization or validation behavior that the schema hints at.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The one structural weakness is that the deprecation warning — the most decision-relevant fact — sits in parentheses after the functional description rather than being 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 values need not be described, and the tool takes no required parameters beyond transport fields. The deprecation status and replacement are stated, which is the key context an agent needs; only the legacy-normalization behavior is left implicit.
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 (locale, idempotencyKey) are documented as transport-level fields, not service inputs. The description adds no parameter meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Read') plus resources ('learning paths and public starting links'), and it explicitly identifies itself as a deprecated alias for academy_start, which disambiguates it from the many sibling academy_* tools. It stops short of 5 because 'public starting links' is vague phrasing that an agent must interpret.
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 preferred alternative (academy_start) and the condition under which this tool is superseded, plus the 'retained for one version' lifetime note. It does not say whether there is any remaining case where this tool is still correct to call, which keeps it out of 5 territory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public item by its exact stable identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| locale | No | MCP transport locale; not a service input field. | de |
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | 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 fully covered by structured data. The description adds two useful behavioral facts beyond that: the item is 'public' (no authorization scoping implied) and the identifier must match exactly (no fuzzy/partial resolution). It says nothing about not-found behavior or whether results are locale-dependent despite a locale parameter existing.
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 twelve-word sentence with no filler, and the key constraint ('exact stable identifier') is front-loaded. It is efficient, though its brevity is part of why other dimensions are thin rather than a virtue in itself.
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?
The output schema and annotations relieve the description of return-value and safety disclosure, but the core ambiguity remains: among 28 siblings the agent cannot tell what kind of 'item' this fetches or what distinguishes it from 'search'. For a nominally generic 'fetch' entry point, that is a material omission.
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 67%, with locale and idempotencyKey self-documented as transport concerns, so the schema carries most of the load. The description only contributes the notion that 'id' is an 'exact stable identifier,' hinting at no partial matching, but it does not state format, where such IDs come from, or how locale affects the returned content. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb+resource pairing is 'Fetch a public item by its exact stable identifier,' which tells the agent it is a single-record lookup keyed by ID. However, 'item' is never resolved into a concrete resource type, and nothing distinguishes it from the sibling 'search' tool or the academy_* family. An agent knows the shape of the operation but not the domain of the data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use statement and no named alternative. The phrase 'exact stable identifier' implicitly suggests it is a precision lookup rather than a discovery tool, but the agent must infer that 'search' is the counterpart for unknown IDs. No prerequisites or failure conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search actual lessons and public library content with stable identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| query | Yes | ||
| cursor | No | ||
| locale | No | MCP transport locale; not a service input field. | de |
| pathId | No | ||
| idempotencyKey | No | Transport retry key, forwarded as Idempotency-Key. |
| Name | Required | Description |
|---|---|---|
| errors | Yes | |
| result | Yes | |
| success | Yes | |
| messages | Yes | |
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only that results come from 'actual' content with 'stable identifiers' but omits pagination behavior despite a cursor parameter and does not explain the limits of the 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?
The description is a single sentence with no wasted words, but it is under-specified rather than appropriately concise. The vague terms 'actual' and 'stable identifiers' do not earn their place because they add little actionable meaning.
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 explanation is not strictly required. However, with seven parameters and only 29% schema coverage, the description should clarify filtering and pagination behavior but instead provides almost no operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, so the schema leaves several parameters undocumented, and the description compensates for none of them. It does not explain the required query semantics, the type filter, limit, cursor, pathId, or locale constraints.
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 (Search) and resource (lessons and public library content), which is more informative than a tautology. However, 'actual lessons' is vague and the description does not distinguish this tool from the similarly named sibling academy_search.
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?
Provides no guidance on when to use this tool versus alternatives such as academy_search, academy_lessons, or academy_library. It also does not state any exclusions or prerequisites.
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.
academy_coachingacademy_conceptsacademy_glossaryacademy_glossary_termacademy_legacy_lessonsacademy_legacy_levelsacademy_lesson11 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / level / typePrevious value: -"number"New value: +"integer"Input schema / properties / locale / defaultAdded value: +"de"Input schema / properties / locale / descriptionPrevious value: -"Language. de=German, en=English, es=Spanish. Default en."New value: +"MCP transport locale; not a service input field."Input schema / properties / slug / descriptionRemoved value: -"Lesson slug, e.g. \"01-was-ist-ai\" (from academy_lessons)"Input schema / properties / slug / maxLengthAdded value: +180Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9][a-z0-9_.-]*$"Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "bodyLocale": {
+ "type": "string"
+ },
+ "bodyPending": {
+ "type": "boolean"
+ },
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "level": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "preview": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "slug",
+ "locale",
+ "title",
+ "order",
+ "body"
+ ],
+ "type": "object"
+ },
+ "content_locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "fallback": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "requestedLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "anyOf": [
+ {
+ "enum": [
+ "draft",
+ "candidate",
+ "active",
+ "deprecated"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "requestedLocale",
+ "content_locale",
+ "fallback",
+ "version",
+ "status",
+ "updated",
+ "content"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_lessons10 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +trueInput schema / descriptionAdded value: +"Deprecated alias: legacy fields are normalized and strictly validated by Academy."Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / level / descriptionRemoved value: -"Level 1-6"Input schema / properties / level / typePrevious value: -"number"New value: +"integer"Input schema / properties / locale / defaultAdded value: +"de"Input schema / properties / locale / descriptionPrevious value: -"Language. de=German, en=English, es=Spanish. Default en."New value: +"MCP transport locale; not a service input field."Input schema / requiredPrevious value: -[
- "level"
-]New value: +[]Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "lessons": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "pattern": "^lesson:-?\\d+(?:\\.\\d+)?:[\\s\\S]{0,}$",
+ "type": "string"
+ },
+ "level": {
+ "type": "number"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "level",
+ "slug",
+ "locale",
+ "title",
+ "description",
+ "href"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "lessons"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_levels8 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +trueInput schema / descriptionAdded value: +"Deprecated alias: legacy fields are normalized and strictly validated by Academy."Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / locale / defaultAdded value: +"de"Input schema / properties / locale / descriptionPrevious value: -"Language. de=German, en=English, es=Spanish. Default en."New value: +"MCP transport locale; not a service input field."Input schema / requiredAdded value: +[]Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "levels": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "lessonCount": {
+ "type": "number"
+ },
+ "level": {
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "title",
+ "href",
+ "lessonCount"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "levels"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_libraryacademy_moduleacademy_pathacademy_pathsacademy_playbook9 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / idAdded value: +{
+ "maxLength": 240,
+ "minLength": 1,
+ "pattern": "^[a-zA-Z0-9][a-zA-Z0-9:_.-]*$",
+ "type": "string"
+}Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / locale / defaultAdded value: +"de"Input schema / properties / locale / descriptionPrevious value: -"Language. de=German, en=English, es=Spanish. Default en."New value: +"MCP transport locale; not a service input field."Input schema / properties / slugRemoved value: -{
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "slug"
-]New value: +[
+ "id"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "bodyLocale": {
+ "type": "string"
+ },
+ "bodyPending": {
+ "type": "boolean"
+ },
+ "category": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "published": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "updated": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "locale",
+ "title",
+ "order",
+ "body"
+ ],
+ "type": "object"
+ },
+ "content_locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "fallback": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "requestedLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "anyOf": [
+ {
+ "enum": [
+ "draft",
+ "candidate",
+ "active",
+ "deprecated"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "requestedLocale",
+ "content_locale",
+ "fallback",
+ "version",
+ "status",
+ "updated",
+ "content"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_playbooks11 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / category / descriptionRemoved value: -"Optional, e.g. \"build\", \"use\""Input schema / properties / category / maxLengthAdded value: +160Input schema / properties / category / minLengthAdded value: +1Input schema / properties / cursorAdded value: +{
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / locale / defaultAdded value: +"de"Input schema / properties / locale / descriptionPrevious value: -"Language. de=German, en=English, es=Spanish. Default en."New value: +"MCP transport locale; not a service input field."Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "access": {
+ "enum": [
+ "free",
+ "premium"
+ ],
+ "type": "string"
+ },
+ "categories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "contentLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "creditPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "euroPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "playbook",
+ "concept"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "href",
+ "label"
+ ],
+ "type": "object"
+ },
+ "title": {
+ "type": "string"
+ },
+ "translationPending": {
+ "type": "boolean"
+ },
+ "type": {
+ "enum": [
+ "prompt",
+ "playbook",
+ "skill",
+ "tool",
+ "agent",
+ "guide",
+ "glossary"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "type",
+ "title",
+ "description",
+ "href",
+ "access",
+ "creditPrice",
+ "euroPrice",
+ "categories",
+ "locale",
+ "contentLocale",
+ "translationPending",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextCursor": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "items",
+ "nextCursor"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_premium_catalogacademy_premium_previewacademy_promptacademy_promptsacademy_recipe8 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / idAdded value: +{
+ "maxLength": 240,
+ "minLength": 1,
+ "pattern": "^[a-zA-Z0-9][a-zA-Z0-9:_.-]*$",
+ "type": "string"
+}Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / localeAdded value: +{
+ "default": "de",
+ "description": "MCP transport locale; not a service input field.",
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+}Input schema / properties / slugRemoved value: -{
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "slug"
-]New value: +[
+ "id"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "contentHash": {
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "phase": {
+ "maximum": 16,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "published": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "updated": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "phase",
+ "order",
+ "title",
+ "description",
+ "duration"
+ ],
+ "type": "object"
+ },
+ "steps": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "index": {
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ },
+ "validatorId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "index",
+ "title",
+ "body"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "meta",
+ "body",
+ "steps",
+ "contentHash"
+ ],
+ "type": "object"
+ },
+ "content_locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "fallback": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "requestedLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "anyOf": [
+ {
+ "enum": [
+ "draft",
+ "candidate",
+ "active",
+ "deprecated"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "requestedLocale",
+ "content_locale",
+ "fallback",
+ "version",
+ "status",
+ "updated",
+ "content"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_recipes11 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / cursorAdded value: +{
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / localeAdded value: +{
+ "default": "de",
+ "description": "MCP transport locale; not a service input field.",
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+}Input schema / properties / phase / descriptionRemoved value: -"Optional phase number 1-16"Input schema / properties / phase / maximumAdded value: +16Input schema / properties / phase / minimumAdded value: +1Input schema / properties / phase / typePrevious value: -"number"New value: +"integer"Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "contentHash": {
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "phase": {
+ "maximum": 16,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "published": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "updated": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "phase",
+ "order",
+ "title",
+ "description",
+ "duration"
+ ],
+ "type": "object"
+ },
+ "steps": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "index": {
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ },
+ "validatorId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "index",
+ "title",
+ "body"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "meta",
+ "body",
+ "steps",
+ "contentHash"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextCursor": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "items",
+ "nextCursor"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_search15 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / cursorAdded value: +{
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / limit / defaultRemoved value: -10Input schema / properties / limit / maximumPrevious value: -50New value: +100Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / locale / defaultAdded value: +"de"Input schema / properties / locale / descriptionPrevious value: -"Language. de=German, en=English, es=Spanish. Default en."New value: +"MCP transport locale; not a service input field."Input schema / properties / pathIdAdded value: +{
+ "enum": [
+ "loslegen",
+ "ki-im-alltag",
+ "ki-im-job",
+ "fuer-entwickler"
+ ],
+ "type": "string"
+}Input schema / properties / query / descriptionRemoved value: -"Search keywords"Input schema / properties / query / maxLengthAdded value: +160Input schema / properties / query / minLengthAdded value: +1Input schema / properties / typeAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "prompt",
+ "playbook",
+ "skill",
+ "tool",
+ "agent",
+ "guide",
+ "glossary"
+ ],
+ "type": "string"
+ },
+ {
+ "const": "lesson",
+ "type": "string"
+ }
+ ]
+}Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "items": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "access": {
+ "enum": [
+ "free",
+ "premium"
+ ],
+ "type": "string"
+ },
+ "categories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "contentLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "creditPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "euroPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "playbook",
+ "concept"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "href",
+ "label"
+ ],
+ "type": "object"
+ },
+ "title": {
+ "type": "string"
+ },
+ "translationPending": {
+ "type": "boolean"
+ },
+ "type": {
+ "enum": [
+ "prompt",
+ "playbook",
+ "skill",
+ "tool",
+ "agent",
+ "guide",
+ "glossary"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "type",
+ "title",
+ "description",
+ "href",
+ "access",
+ "creditPrice",
+ "euroPrice",
+ "categories",
+ "locale",
+ "contentLocale",
+ "translationPending",
+ "source"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "access": {
+ "enum": [
+ "free",
+ "premium"
+ ],
+ "type": "string"
+ },
+ "categories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "contentLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "creditPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "euroPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "lesson",
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "level": {
+ "maximum": 6,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "level",
+ "slug",
+ "href",
+ "label"
+ ],
+ "type": "object"
+ },
+ "title": {
+ "type": "string"
+ },
+ "translationPending": {
+ "type": "boolean"
+ },
+ "type": {
+ "const": "lesson",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "description",
+ "href",
+ "access",
+ "creditPrice",
+ "euroPrice",
+ "categories",
+ "locale",
+ "contentLocale",
+ "translationPending",
+ "type",
+ "source"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ "nextCursor": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "items",
+ "nextCursor"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_startacademy_suggestacademy_teachacademy_tutor_context12 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +trueInput schema / descriptionAdded value: +"Deprecated alias: legacy fields are normalized and strictly validated by Academy."Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / level / typePrevious value: -"number"New value: +"integer"Input schema / properties / locale / defaultAdded value: +"de"Input schema / properties / locale / descriptionPrevious value: -"Language. de=German, en=English, es=Spanish. Default en."New value: +"MCP transport locale; not a service input field."Input schema / properties / slug / maxLengthAdded value: +180Input schema / properties / slug / minLengthAdded value: +1Input schema / properties / slug / patternAdded value: +"^[a-z0-9][a-z0-9_.-]*$"Input schema / requiredPrevious value: -[
- "level",
- "slug"
-]New value: +[]Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "additionalProperties": false,
+ "properties": {
+ "exercise": {
+ "type": "string"
+ },
+ "lessonId": {
+ "pattern": "^lesson:-?\\d+(?:\\.\\d+)?:[\\s\\S]{0,}$",
+ "type": "string"
+ },
+ "objectives": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "steps": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "lessonId",
+ "objectives",
+ "steps",
+ "exercise"
+ ],
+ "type": "object"
+ },
+ "content_locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "fallback": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "requestedLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "anyOf": [
+ {
+ "enum": [
+ "draft",
+ "candidate",
+ "active",
+ "deprecated"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "requestedLocale",
+ "content_locale",
+ "fallback",
+ "version",
+ "status",
+ "updated",
+ "content"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_welcome8 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +trueInput schema / descriptionAdded value: +"Deprecated alias: legacy fields are normalized and strictly validated by Academy."Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / locale / defaultAdded value: +"de"Input schema / properties / locale / descriptionPrevious value: -"Language. de=German, en=English, es=Spanish. Default en."New value: +"MCP transport locale; not a service input field."Input schema / requiredAdded value: +[]Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "links": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "method": {
+ "enum": [
+ "GET",
+ "POST",
+ "PATCH",
+ "DELETE"
+ ],
+ "type": "string"
+ },
+ "rel": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "rel",
+ "method",
+ "href"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "paths": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "capstone": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "bodyLocale": {
+ "type": "string"
+ },
+ "bodyPending": {
+ "type": "boolean"
+ },
+ "deepDiveOf": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "lesson",
+ "playbook"
+ ],
+ "type": "string"
+ },
+ "level": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "moduleId": {
+ "type": "string"
+ },
+ "optional": {
+ "type": "boolean"
+ },
+ "order": {
+ "type": "number"
+ },
+ "originalHref": {
+ "type": "string"
+ },
+ "originalReference": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "lesson",
+ "type": "string"
+ },
+ "level": {
+ "type": "number"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "level",
+ "slug",
+ "locale",
+ "href"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "lesson",
+ "playbook",
+ "capstone"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "type",
+ "slug",
+ "level",
+ "locale",
+ "title",
+ "moduleId",
+ "order",
+ "optional",
+ "deepDiveOf",
+ "href",
+ "originalHref",
+ "originalReference"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "enum": [
+ "loslegen",
+ "ki-im-alltag",
+ "ki-im-job",
+ "fuer-entwickler"
+ ],
+ "type": "string"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "mappingNote": {
+ "type": "string"
+ },
+ "mappingStatus": {
+ "enum": [
+ "pending",
+ "confirmed"
+ ],
+ "type": "string"
+ },
+ "moduleMapping": {
+ "enum": [
+ "pending",
+ "confirmed"
+ ],
+ "type": "string"
+ },
+ "modules": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "isContentContainer": {
+ "type": "boolean"
+ },
+ "lessons": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "bodyLocale": {
+ "type": "string"
+ },
+ "bodyPending": {
+ "type": "boolean"
+ },
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "level": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "originLabel": {
+ "type": "string"
+ },
+ "originalReference": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "lesson",
+ "type": "string"
+ },
+ "level": {
+ "type": "number"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "level",
+ "slug",
+ "locale",
+ "href"
+ ],
+ "type": "object"
+ },
+ "preview": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "status": {
+ "const": "available",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "slug",
+ "locale",
+ "title",
+ "order",
+ "id",
+ "href",
+ "status",
+ "originLabel",
+ "originalReference"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "order": {
+ "type": "number"
+ },
+ "originalReferences": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "lesson",
+ "type": "string"
+ },
+ "level": {
+ "type": "number"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "level",
+ "slug",
+ "locale",
+ "href"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "enum": [
+ "available",
+ "planned"
+ ],
+ "type": "string"
+ },
+ "steps": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "bodyLocale": {
+ "type": "string"
+ },
+ "bodyPending": {
+ "type": "boolean"
+ },
+ "deepDiveOf": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "lesson",
+ "playbook"
+ ],
+ "type": "string"
+ },
+ "level": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "moduleId": {
+ "type": "string"
+ },
+ "optional": {
+ "type": "boolean"
+ },
+ "order": {
+ "type": "number"
+ },
+ "originalHref": {
+ "type": "string"
+ },
+ "originalReference": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "lesson",
+ "type": "string"
+ },
+ "level": {
+ "type": "number"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "level",
+ "slug",
+ "locale",
+ "href"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "lesson",
+ "playbook",
+ "capstone"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "type",
+ "slug",
+ "level",
+ "locale",
+ "title",
+ "moduleId",
+ "order",
+ "optional",
+ "deepDiveOf",
+ "href",
+ "originalHref",
+ "originalReference"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "order",
+ "title",
+ "description",
+ "status",
+ "lessons",
+ "originalReferences",
+ "steps",
+ "isContentContainer"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextPathIds": {
+ "items": {
+ "enum": [
+ "loslegen",
+ "ki-im-alltag",
+ "ki-im-job",
+ "fuer-entwickler"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "originalReferences": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "lesson",
+ "type": "string"
+ },
+ "level": {
+ "type": "number"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "level",
+ "slug",
+ "locale",
+ "href"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "recommendedEntry": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "bodyLocale": {
+ "type": "string"
+ },
+ "bodyPending": {
+ "type": "boolean"
+ },
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "level": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "originLabel": {
+ "type": "string"
+ },
+ "originalReference": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "lesson",
+ "type": "string"
+ },
+ "level": {
+ "type": "number"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "level",
+ "slug",
+ "locale",
+ "href"
+ ],
+ "type": "object"
+ },
+ "preview": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "status": {
+ "const": "available",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "slug",
+ "locale",
+ "title",
+ "order",
+ "id",
+ "href",
+ "status",
+ "originLabel",
+ "originalReference"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "enum": [
+ "available",
+ "planned"
+ ],
+ "type": "string"
+ },
+ "steps": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "bodyLocale": {
+ "type": "string"
+ },
+ "bodyPending": {
+ "type": "boolean"
+ },
+ "deepDiveOf": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "lesson",
+ "playbook"
+ ],
+ "type": "string"
+ },
+ "level": {
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "moduleId": {
+ "type": "string"
+ },
+ "optional": {
+ "type": "boolean"
+ },
+ "order": {
+ "type": "number"
+ },
+ "originalHref": {
+ "type": "string"
+ },
+ "originalReference": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "lesson",
+ "type": "string"
+ },
+ "level": {
+ "type": "number"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "level",
+ "slug",
+ "locale",
+ "href"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "lesson",
+ "playbook",
+ "capstone"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "type",
+ "slug",
+ "level",
+ "locale",
+ "title",
+ "moduleId",
+ "order",
+ "optional",
+ "deepDiveOf",
+ "href",
+ "originalHref",
+ "originalReference"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "locale",
+ "title",
+ "description",
+ "href",
+ "status",
+ "mappingStatus",
+ "mappingNote",
+ "modules",
+ "steps",
+ "capstone",
+ "moduleMapping",
+ "nextPathIds",
+ "recommendedEntry",
+ "originalReferences"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "paths",
+ "links"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}fetch9 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / id / descriptionRemoved value: -"Item id from search results"Input schema / properties / id / maxLengthAdded value: +240Input schema / properties / id / minLengthAdded value: +1Input schema / properties / id / patternAdded value: +"^[a-zA-Z0-9][a-zA-Z0-9:_.-]*$"Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / localeAdded value: +{
+ "default": "de",
+ "description": "MCP transport locale; not a service input field.",
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "bodyLocale": {
+ "type": "string"
+ },
+ "bodyPending": {
+ "type": "boolean"
+ },
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "level": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "preview": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "slug",
+ "locale",
+ "title",
+ "order",
+ "body"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "bodyLocale": {
+ "type": "string"
+ },
+ "bodyPending": {
+ "type": "boolean"
+ },
+ "category": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "published": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "updated": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "locale",
+ "title",
+ "order",
+ "body"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "contentHash": {
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "duration": {
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "phase": {
+ "maximum": 16,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "published": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "updated": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "phase",
+ "order",
+ "title",
+ "description",
+ "duration"
+ ],
+ "type": "object"
+ },
+ "steps": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "index": {
+ "type": "number"
+ },
+ "title": {
+ "type": "string"
+ },
+ "validatorId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "index",
+ "title",
+ "body"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "meta",
+ "body",
+ "steps",
+ "contentHash"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "body": {
+ "type": "string"
+ },
+ "conceptType": {
+ "enum": [
+ "config_file",
+ "pattern",
+ "tool",
+ "service",
+ "command",
+ "mcp_server",
+ "feature"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "sourceUrl": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "slug",
+ "conceptType",
+ "name",
+ "summary",
+ "body",
+ "tags"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "playbookId": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "text",
+ "playbookId"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "content_locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "fallback": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "requestedLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "anyOf": [
+ {
+ "enum": [
+ "draft",
+ "candidate",
+ "active",
+ "deprecated"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "updated": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "version": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "requestedLocale",
+ "content_locale",
+ "fallback",
+ "version",
+ "status",
+ "updated",
+ "content"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}search12 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / cursorAdded value: +{
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / idempotencyKeyAdded value: +{
+ "description": "Transport retry key, forwarded as Idempotency-Key.",
+ "maxLength": 200,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / localeAdded value: +{
+ "default": "de",
+ "description": "MCP transport locale; not a service input field.",
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+}Input schema / properties / pathIdAdded value: +{
+ "enum": [
+ "loslegen",
+ "ki-im-alltag",
+ "ki-im-job",
+ "fuer-entwickler"
+ ],
+ "type": "string"
+}Input schema / properties / query / descriptionRemoved value: -"Search query"Input schema / properties / query / maxLengthAdded value: +160Input schema / properties / query / minLengthAdded value: +1Input schema / properties / typeAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "prompt",
+ "playbook",
+ "skill",
+ "tool",
+ "agent",
+ "guide",
+ "glossary"
+ ],
+ "type": "string"
+ },
+ {
+ "const": "lesson",
+ "type": "string"
+ }
+ ]
+}Output schema / (root)Previous value: -nullNew value: +{
+ "oneOf": [
+ {
+ "properties": {
+ "errors": {
+ "maxItems": 0
+ },
+ "result": {
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "items": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "access": {
+ "enum": [
+ "free",
+ "premium"
+ ],
+ "type": "string"
+ },
+ "categories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "contentLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "creditPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "euroPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "playbook",
+ "concept"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "slug",
+ "href",
+ "label"
+ ],
+ "type": "object"
+ },
+ "title": {
+ "type": "string"
+ },
+ "translationPending": {
+ "type": "boolean"
+ },
+ "type": {
+ "enum": [
+ "prompt",
+ "playbook",
+ "skill",
+ "tool",
+ "agent",
+ "guide",
+ "glossary"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "type",
+ "title",
+ "description",
+ "href",
+ "access",
+ "creditPrice",
+ "euroPrice",
+ "categories",
+ "locale",
+ "contentLocale",
+ "translationPending",
+ "source"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "access": {
+ "enum": [
+ "free",
+ "premium"
+ ],
+ "type": "string"
+ },
+ "categories": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "contentLocale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "creditPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "euroPrice": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "href": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "locale": {
+ "enum": [
+ "de",
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "additionalProperties": false,
+ "properties": {
+ "href": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "lesson",
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "level": {
+ "maximum": 6,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "level",
+ "slug",
+ "href",
+ "label"
+ ],
+ "type": "object"
+ },
+ "title": {
+ "type": "string"
+ },
+ "translationPending": {
+ "type": "boolean"
+ },
+ "type": {
+ "const": "lesson",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "description",
+ "href",
+ "access",
+ "creditPrice",
+ "euroPrice",
+ "categories",
+ "locale",
+ "contentLocale",
+ "translationPending",
+ "type",
+ "source"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ "nextCursor": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "items",
+ "nextCursor"
+ ],
+ "type": "object"
+ },
+ "success": {
+ "const": true
+ }
+ }
+ },
+ {
+ "properties": {
+ "errors": {
+ "minItems": 1
+ },
+ "result": {
+ "type": "null"
+ },
+ "success": {
+ "const": false
+ }
+ }
+ }
+ ],
+ "properties": {
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "number"
+ },
+ "documentation_url": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "hint": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "message": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "slug": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "slug",
+ "message",
+ "hint",
+ "documentation_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messages": {
+ "type": "array"
+ },
+ "request_id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "result": {},
+ "success": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "result",
+ "errors",
+ "messages",
+ "request_id"
+ ],
+ "type": "object"
+}academy_lessonacademy_lessonsacademy_levelsacademy_playbookacademy_playbooksacademy_recipeacademy_recipesacademy_searchacademy_tutor_contextacademy_welcomefetchsearchWeb search, page reading, site crawling, data extraction and cited research. OAuth sign-in.
OAuth 2.1 short-link tools for AI agents with scoped tokens, approvals, audit logs, and revocation.
Web search, data extraction and controlled browser automation for AI assistants via OAuth.
Taskade projects, tasks and AI agents. Hosted OAuth server or local stdio package.
Add one secure layer between your agents and this server.
