[WALK · internal] Coach — adaptive 'what's next' in a subject: given completed unit ids, the next lesson whose prerequisites are met (grows with the student). Found, never generated.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | No | ||
| completed | No |
Changes observed during successful MCP inspections.
Input schema / additionalPropertiesAdded value: +falseInput schema / properties / completed / itemsAdded value: +{
+ "maxLength": 4000,
+ "type": "string"
+}Input schema / properties / completed / maxItemsAdded value: +200Input schema / properties / subject / maxLengthAdded value: +4000Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Found, never generated' is genuinely useful behavioral disclosure (deterministic lookup, not model generation) and 'grows with the student' signals adaptivity. It omits what happens when no lesson qualifies, whether the result is cached, and any auth/permission 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?
A single dense sentence plus a bracketed tag; the key constraint (prerequisite filtering) is front-loaded. Nothing is padded, though the notation 'WALK · internal' and embedded quotes add slight parsing friction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema, so the description must stand alone. It does explain the return conceptually ('the next lesson'), but for a tool with no required parameters it leaves the empty/no-match case and the expected id format unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does reference both parameters informally ('in a subject', 'completed unit ids'), which is meaningful, but gives no format guidance such as how unit ids are shaped or that completed is an array of up to 200 strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: it returns the next lesson whose prerequisites are met given completed unit ids, within a subject. That is clear enough to distinguish it from most siblings, but it does not differentiate itself from the very similar coach_next or coach_guidance in the sibling list, leaving ambiguity about which 'next' tool to pick.
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 'given completed unit ids, the next lesson whose prerequisites are met' implies the calling context, and '[WALK · internal]' hints at internal usage. However, there is no explicit when-to-use vs when-not, and no reference to the near-duplicate coach_next, so routing relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.