Skip to main content
Glama

AI 课堂思维导图

ykt_mind_map

Retrieve a lesson's automatically generated mind map as a hierarchical tree for a given lesson ID and region.

Instructions

获取平台为这节课自动生成的思维导图(树形结构,含层级)。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "lessonId": "<lessonId>"
    },
    "name": "ykt_mind_map"
  }
}

Input Schema

NameRequiredDescriptionDefault
regionNostandard
lessonIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description still discloses meaningful behavior: the content is platform-generated (so the caller does not build it) and is returned as a tree with hierarchy rather than a flat list. It omits permission needs, whether the map can be absent for a lesson, and any size or depth limits.

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

Conciseness4/5

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

One front-loaded sentence with no filler, and the return shape is grouped into a parenthetical. It is efficient, though quite thin, with no structural elaboration beyond the single clause.

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

Completeness2/5

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

No output schema and no annotations mean the description carries the full burden, yet it leaves both parameters undocumented — especially the unexplained region enum — and says nothing about failure when no map exists. Return shape is the only covered aspect.

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

Parameters2/5

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

Schema coverage is 0% for two parameters. '这节课' only hints that lessonId is the target; the four-value region enum (standard/hetang/changjiang/huanghe) and its default are entirely unexplained, so the description does not compensate for the coverage gap.

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 names a specific verb (获取) and resource (思维导图), and scopes it to the lesson, so an agent can tell it apart from ykt_slides or ykt_lesson_summary. It does not explicitly disambiguate against those siblings, though, so it stops 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.

Usage Guidelines2/5

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

There is no guidance on when to call this versus related tools (ykt_lesson_summary, ykt_slides, ykt_notes), nor any note about prerequisites such as the map only existing after the platform has generated it. Usage is only implied by the word 获取 (retrieve).

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