get_trackGet one track with its full lesson list, so you can see the structure of a course and pick the right lesson to read.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Track slug, e.g. "rag" |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that the response includes the 'full lesson list', which is useful return-content context. It does not disclose error behavior or edge cases, but for a read-only getter this is acceptable.
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 that front-loads the verb and resource, then gives the purpose. Every word earns its place; no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description is complete: it states input slug, output (full lesson list), and the purpose. No output schema exists, but the description adequately conveys the return shape. Slightly more detail on lesson-list contents would push it to 5, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the slug parameter already described as 'Track slug, e.g. "rag"'. The description adds no additional parameter meaning beyond what the schema provides, so 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 description opens with 'Get one track with its full lesson list', a specific verb and resource that clearly states what the tool does. It implicitly distinguishes itself from siblings: list_tracks returns multiple tracks, read_lesson returns a lesson, search_lessons searches; this tool returns a single track with its lesson structure.
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 gives a clear when-to-use context: 'so you can see the structure of a course and pick the right lesson to read'. It doesn't explicitly name alternatives or exclusions, but the intended use case is evident and sufficient for an agent to route correctly.
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.
Each tool targets a clearly distinct entity and action: tracks are discovered and inspected via list_tracks/get_track, while lessons are searched and read via search_lessons/read_lesson. The descriptions explicitly guide when to use each tool, so there is no meaningful overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with appropriate singular/plural usage: get_track, list_tracks, read_lesson, search_lessons. The naming style is uniform, predictable, and immediately conveys each tool's purpose.
Four tools is a well-scoped count for a read-only course content server: two for tracks and two for lessons. Each tool earns its place, and adding more would risk redundancy while removing any would create a discovery or reading gap.
The tool surface covers the full user journey for this domain: find a track, inspect its lesson list, search lessons across the curriculum, and read a lesson's full text. For a read-only educational content server, there are no obvious dead ends or missing operations.