Submit a session ID and an A/B/C/D reply or switch/abandon command to advance a Socratic coaching session, returning the next question or final result.
继续一个进行中的 Socratic 多轮辅导会话。
回复选项字母 (A/B/C/D) 来推进对话，或输入
「直接说」切换到简单模式、「别问了」放弃本轮。
Args:
session_id: 由 start_coaching 返回的会话 ID
user_input: 用户对当前问题的回答（选项字母或指令文本）
Returns:
dict: 下一轮问题或最终结果
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| user_input | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full behavioral burden. It usefully discloses that 「别问了」 abandons the round and 「直接说」 downgrades to simple mode, which is real behavioral context. However, it doesn't state session-state effects (does abandoning end the session?), persistence, or error behavior for an invalid session_id.
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?
Front-loads the core action, then the reply protocol, then Args/Returns. Efficient overall, though the Args/Returns block partly restates the intro (the reply options reappear in user_input).
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 no output schema, the description briefly notes the return (next question or final result), and with no annotations it explains the interactive protocol. Sufficient for an agent to call it correctly, though session lifecycle and error handling remain unstated.
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 0%, so the description must compensate, and it does: session_id is explained as originating from start_coaching, and user_input is defined as either an option letter or instruction text. This meaningfully exceeds the bare schema, though exact accepted command strings are only illustrated, not enumerated.
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 (continue an in-progress Socratic multi-turn coaching session) and clearly distinguishes itself from coaching_start_coaching and coaching_abandon_coaching by implying an active session is required. An agent can tell what this does without opening 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?
Gives clear usage context: advance by replying with option letter (A/B/C/D), switch to simple mode with 「直接说」, or abandon with 「别问了」. It doesn't explicitly name sibling tools as alternatives, but the when-to-use condition (an in-progress session) is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.