job_score_matchScores resumes against job descriptions to show match quality and skill gaps, helping you decide whether to apply or tailor your resume.
旧版工具名，等价于 resume_score_match。
| Name | Required | Description | Default |
|---|---|---|---|
| jdText | Yes |
Changes observed during successful MCP inspections.
v1.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 burden, and it discloses almost nothing: not whether the call still works, whether it is deprecated, what it returns, or any auth/rate constraints. The only trait conveyed is that it is a legacy alias, which is identity metadata rather than behavior.
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 single short sentence is front-loaded and contains no filler, but its brevity reflects under-specification rather than disciplined conciseness — it earns little beyond the alias mapping.
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?
For a low-complexity one-parameter compatibility alias, the description identifies the equivalent tool, which is the core need. However it omits whether the tool is deprecated, whether it should still be called, and any parameter detail, leaving meaningful gaps for an agent deciding between it and resume_score_match.
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?
There is one parameter (jdText) with 0% schema description coverage, and the description says nothing about it. The name is fairly self-explanatory, but no added meaning, format, or source guidance is supplied to compensate for the empty schema.
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 never states a verb+resource directly; it only says this is the legacy name for resume_score_match. An agent can infer the resume-to-JD scoring purpose by proxy, but the description itself does not describe what the tool does, and it relies on the reader knowing the sibling.
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?
'旧版工具名' implies this is a deprecated/compatibility alias, which hints the agent should prefer resume_score_match, but it never explicitly says to use that tool instead or when this one is still appropriate. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.