Retrieve recent coaching scenario records to review past investment coaching sessions, including triggers, variables, causal chains, and conclusions. Set a limit to control how many records return.
列出最近的学习辅导情景记录。
每次辅导结束（无论是简单模式还是复杂模式）都会自动归档到情景库，
包括触发事件、变量结构、因果链和最终结论。
Args:
limit: 返回的记录数量，默认 20
Returns:
dict: {"count": N, "scenarios": [...]}
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that records are auto-generated on session completion and what each record contains (triggering event, variable structure, causal chain, conclusion), which is real context about the data. However it omits ordering, pagination, and any access/prerequisite behavior for a list operation.
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?
Purpose is front-loaded in the first line, followed by useful archive context and the argument/return sections. No filler; the Returns line is a compact supplement to the missing output schema.
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 supplies the return shape ({"count": N, "scenarios": [...]}) and explains what a scenario record consists of, which is what an agent needs to consume the result. Missing only minor operational details such as sort order.
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% and there is only one parameter, yet the description documents it directly ('limit: number of records, default 20'). This fully compensates for the schema gap, though it adds no detail beyond count semantics (e.g. no max or ordering interaction).
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 first line states a specific verb (列出/list) and resource (学习辅导情景记录/coaching scenario records), so an agent knows exactly what it fetches. It does not explicitly contrast with siblings like coaching_compare_history, but the resource is distinct enough to be actionable.
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?
There is no explicit when-to-use guidance or naming of alternatives. The second sentence describes how records are created ('auto-archived after every coaching session'), which implies the tool is for reviewing past sessions, but the agent must infer that this is the read/retrieval counterpart to the coaching_* write verbs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.