结束模拟面试并复盘
mock_interview_endEnd a specified mock interview session by summarizing all Q&A and generating a deep review report prompt.
Instructions
结束指定模拟面试会话,汇总全部问答并生成深度复盘报告 prompt。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
mock_interview_endEnd a specified mock interview session by summarizing all Q&A and generating a deep review report prompt.
结束指定模拟面试会话,汇总全部问答并生成深度复盘报告 prompt。
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the summarizing and report-prompt generation behavior, but omits critical terminal-operation details: whether the session is closed/deleted or merely finalized, whether it is reversible, whether an in-progress session is required, and any permission prerequisites.
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 front-loaded sentence led by the action verb, with no filler. It is efficiently sized for the tool, though it could have spent one more clause on state/reversibility instead of stopping short.
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?
No output schema and no annotations, so the description should do more. It hints at a generated 'report prompt' (useful, since no output schema exists) but leaves the session-state outcome and prerequisites undefined, an important gap for a terminal mutation tool.
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, but with only one obvious parameter (sessionId) there is little to clarify. '指定...会话' loosely points at sessionId but adds no format, id-scheme, or validity information beyond the schema's type declaration.
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 gives a specific verb (结束/end), a specific resource (指定模拟面试会话/the specified mock interview session), and the resulting side effects (summarize all Q&A and generate a deep review report prompt). This clearly separates it from siblings like mock_interview_start and mock_interview_answer, though it never names those siblings explicitly.
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/when-not-to-use guidance nor any named alternative. The only signal is the implicit interview lifecycle (start → answer → end), which the agent must infer from the name rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.