Skip to main content
Glama
achuthc1298

Fastcat Literature MCP

by achuthc1298

save_ranking

Records ranked DOIs chosen by the language model during literature search, ordered by title and abstract relevance for later citation-backed responses.

Instructions

Record the main LLM's chosen DOIs in descending relevance order. Does not run an LLM.

Rank using titles and abstracts from search_papers; do not imply you read full texts yet. You may select a relevant subset. Unknown and duplicate DOIs are rejected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
run_idYes
ranked_papersYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose real behavior: it does not invoke an LLM, it rejects unknown and duplicate DOIs, and a subset is acceptable. It omits persistence semantics (does a new ranking replace or append to prior rankings?) and any permission/auth requirements, leaving a gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Short and front-loaded: the core action and its key constraint come first, with caveats following. Four compact sentences, though the trailing 'Unknown and duplicate DOIs are rejected' is somewhat bolted on rather than integrated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter write tool with no output schema and no annotations, the description covers the essential call-time concerns: what to rank, what inputs are valid, and that it does not run an LLM. The main missing piece is run_id semantics and overwrite/append behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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. It adds ordering semantics for ranked_papers ('descending relevance order') and subset allowance, but run_id is never explained and the rejection rule for bad DOIs is the only validation detail given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a precise verb+resource ('Record the main LLM's chosen DOIs in descending relevance order') and immediately clarifies the boundary 'Does not run an LLM,' which separates it from the search/read siblings. An agent can identify exactly what artifact this tool persists without inspecting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the input basis ('Rank using titles and abstracts from search_papers') and the constraint 'do not imply you read full texts yet,' plus permission to select a subset. It never names an explicit alternative tool or a when-not-to-use case, but the procedural context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.