Skip to main content
Glama
Sign In
Codemm

Codemm

by iignaite
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

next_step

Recommends the learner's next coding-tutor action—setup, lesson, practice, review, authoring, stuck, or done—and flags when a lesson must be taught before an activity.

Instructions

What to do next: setup (install the track), practice an existing exercise, review a mastered concept on an exercise (a check keeps it mastered), author a new one (concept, difficulty, style, track; review: true when it's for a review), learn (lessons only), stuck, or done. On learn, lesson is null when a lesson needs writing, otherwise the earliest unread lesson id. On practice and author, lesson is null when the concept needs a lesson first, or the id of a lesson the learner hasn't read yet; teach before the activity until it's gone.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "next_step"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations and no output schema, the description carries the full burden and largely meets it: it defines the possible return states and explains the conditional meaning of the lesson field (null vs. earliest unread lesson id) plus the 'teach before the activity' rule. It stops short of saying whether the call has any side effects or what other fields accompany the state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening is front-loaded and every clause carries real state-machine information, but the single run-on paragraph with nested parentheticals ('author a new one (concept, difficulty, style, track; review: true when it's for a review)') is hard to parse. Bullet-style enumeration of the states would deliver the same content far more legibly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description is the only contract and it does explain the state vocabulary and the lesson-null semantics. It is slightly incomplete on the full shape of the returned object (e.g., accompanying ids or fields for each state), which matters because nothing else documents the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'What to do next' and enumerates the full state vocabulary (setup, practice, review, author, learn, stuck, done), so an agent can tell this is a routing/recommendation tool rather than a retrieval tool like get_exercise or progress. It is a fragment rather than a clean verb+resource sentence, and the sibling differentiation is only implicit in the state list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The enumeration of states implies when the tool's answers apply, but there is no explicit guidance on when to call next_step versus siblings such as progress, get_roadmap, or get_lesson. No exclusions or preconditions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools