Skip to main content
Glama
Sign In

Kaiku

by tech.kaiku.mcp
OverviewDiscussionsAdmin

Read pdf text

read_pdf_text
Read-only

The text of a PDF article as Mathpix read it and people put it right, page by page — Markdown with $…$ formulas, each piece with the page of the original it is from, at most 30 pages a call ('nextPage' says where to go on). Each page has its 'version' and its 'state': 'machine' (as Mathpix read it), 'checked' (a person checked it against the original), 'human' (edited by a person) or 'agent' (edited by an agent); 'front' marks a cover or title page; each page's 'viewUrl' opens the text at that page over its wiki page — the link to cite it by in a comment or a «Literature». Name the file by 'fileId' (list_pdf_copies, search_pdf_texts) or by 'pageId' + 'filename'. The original is what counts — check a formula you rely on against pdf_page_image of the same page, and put a page right with update_pdf_text. A file not yet read says so.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "read_pdf_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
pagesNoA page or a range: '5', '3-7', '12-'. Every page without.
fileIdNoThe file's id.
pageIdNoWiki page id, with 'filename', instead of fileId.
filenameNoThe PDF's name on that page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description still adds substantive behavior: per-page 'version' and 'state' semantics (machine/checked/human/agent), the 'front' flag for cover pages, the 'viewUrl' citation link, the 30-page cap, and that an unread file reports so. None of this is recoverable from the annotations or schema.

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?

Content is front-loaded (what the text is, then pagination, then page states, then how to address the file, then verification guidance) and every clause carries information. It is dense and heavily punctuated as one long chain, which costs a little readability but not enough to warrant trimming.

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

Completeness5/5

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

With no output schema, the description still explains the return shape (Markdown text, per-page provenance, version/state, viewUrl) and the truncation behavior. For a read-only, four-parameter retrieval tool it covers everything an agent needs to call and interpret it correctly.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description earns more by clarifying the two mutually exclusive file-addressing paths (fileId versus pageId + filename) and by pointing to 'nextPage' for continuation. The 'pages' range syntax itself ('3-7', '12-') is left entirely to the schema.

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?

States a specific verb+resource: returns the text of a PDF as Mathpix read it, in Markdown with $…$ formulas, page by page with page provenance. It is clearly distinguishable from search_pdf_texts (search), pdf_page_image (image of a page) and update_pdf_text (correcting pages), all of which it names.

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

Usage Guidelines5/5

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

Explicitly routes the agent: verify a formula against pdf_page_image of the same page, correct a page with update_pdf_text, and resolve the file via list_pdf_copies or search_pdf_texts. It also explains the 30-page-per-call limit and that 'nextPage' indicates where to continue, so an agent knows when to call again.

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

All Kaiku toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources