Nearest papers by embedding for a paper id. [Free · 1 credit]
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"paper_id": "<paper_id>"
},
"name": "similar_papers"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| paper_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does disclose two useful traits beyond the schema: the retrieval method (embedding nearest neighbors) and the cost ("Free · 1 credit"), which implies this is a cheap, side-effect-free lookup. It says nothing about ordering guarantees, error behavior for an unknown paper id, or what happens at the limit boundary.
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?
One sentence plus a bracketed cost tag, front-loaded with the core operation and free of filler. It is efficient, though the extreme terseness leaves no room for the missing parameter and output details.
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 read-only, two-parameter lookup this is close to adequate: the seed input, method, and cost are all covered. The gaps are the undocumented `limit` semantics and the total absence of output information (no output schema either), which an agent would need to interpret result size and ranking.
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 must compensate and largely does not. It clarifies that paper_id identifies the seed paper for the similarity search, but `limit` is never mentioned in the description and its meaning (max number of similar papers returned, default 10) must be inferred from the bare integer constraints in the 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?
"Nearest papers by embedding for a paper id" names the resource (papers), the retrieval mechanism (embedding similarity), and the required input, so an agent knows exactly what it returns. It does not distinguish itself from embedding-adjacent siblings such as citation_graph or cocitation_recommendations, which is what keeps it below 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?
There is no when-to-use guidance: no statement of when embedding-based similarity is preferable to citation-based alternatives, no prerequisites, and no exclusions. The only contextual hint is the cost tag, which informs budgeting rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.