Matches a student's natural-language goal or keywords to the top recommended application material tracks for competitions, research grants, or scholarships, returning ranked options for each request.
根据学生的意图或诉求描述（如“我想写一个计算机视觉的大创”、“准备申请国家奖学金”），
智能匹配并推荐最合适的前 N 个申报材料赛道。
参数:
query: 用户的自然语言诉求或关键词
top_n: 返回推荐赛道的数量（默认 3）
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_n | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
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 behavioral-disclosure burden. It implies a read-only recommendation operation, but does not state whether it has side effects, what permissions are needed, whether results are deterministic, or how it behaves with vague queries. The default top_n=3 is the only concrete behavioral detail.
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?
The purpose and examples are front-loaded, then the two parameters are listed compactly. The parameter section is useful because the schema lacks descriptions, though it repeats names already visible in the schema. Overall it is appropriately sized.
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?
The tool is simple, has only two parameters, and has an output schema, so return-value explanation is not required. The description covers purpose and parameter meaning adequately. However, it does not explain how this routing step relates to sibling workflow tools such as generate_student_doc, nor does it provide behavioral caveats.
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%, so the description is the only source of parameter meaning. It explains query as natural-language intent/keywords and top_n as the number of recommended tracks, including the default of 3. It does not state top_n bounds or query length limits, so it is strong but not complete.
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 states a specific action and resource: matching a student's intent/query to the top N suitable application material tracks. The examples clarify the intended input domain. It does not explicitly distinguish itself from sibling tools such as list_student_skills or get_skill_info, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples imply when to use the tool, namely when a student describes a goal or need in natural language. However, it gives no explicit when-not guidance or comparison with alternative sibling tools. Usage is inferable but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.