Retrieve a compact outline of an arXiv paper's LaTeX section headings. Pass a paper ID and optional start index to view the structure of specific sections.
Return a compact outline of headings from original LaTeX source.
| Name | Required | Description | Default |
|---|---|---|---|
| start | No | Zero-based section index (default 0) | |
| paper_id | Yes | Validated modern or legacy arXiv paper ID | |
| max_sections | No | Maximum headings to return (default 100) |
Changes observed during successful MCP inspections.
v0.6.3v0.6.1v0.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse: readOnlyHint is false (implying possible side effects, but the tool appears read-only), and openWorldHint is true (suggesting external effects, but none are described). The description provides no insight into behavior beyond the basic function, such as whether it may access external resources, handle missing LaTeX, or have performance implications. It does not contradict annotations, but it does not add meaningful context.
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 description is a single, concise sentence that front-loads the core purpose. It contains no fluff and is easy to scan. It earns its place by being clear and direct without extraneous information.
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?
Given the tool's complexity (3 params, no output schema), the description is minimally acceptable. The schema covers parameters well, but the description lacks details on the output format (e.g., how headings are structured) and edge cases (e.g., papers without LaTeX). For a tool that returns a list of headings, an agent might need more context, but it is not severely deficient.
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?
Parameter descriptions in the schema cover all three parameters (paper_id, start, max_sections) with reasonable details, achieving 100% coverage. However, the description itself adds little beyond the schema; it doesn't explain how start and max_sections affect the outline or provide examples. The baseline of 3 is appropriate since the schema does the heavy lifting.
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 clearly states the tool returns a compact outline of headings from LaTeX source, which is specific and distinguishes it from sibling tools like get_paper_latex_section (which likely fetches a single section) and get_paper_latex (which likely returns the full source). The verb 'list' and resource 'headings' are precise.
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 description implies the tool is for obtaining a structural overview of a paper's LaTeX source, but it does not explicitly state when to prefer this over get_paper_latex or get_paper_latex_section, nor does it mention when not to use it (e.g., for papers without LaTeX source). The sibling names provide some context, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.