kookmin-campus-mcp

Overview Schema Source Related Servers Discussions Admin

render_material_page

Render a PDF page as a PNG image to inspect equations, tables, diagrams, or scanned content. Use when you need visual verification, not automatic OCR.

Instructions

PDF 한 페이지를 PNG 이미지로 렌더링해 반환합니다. 수식·표·그림·스캔 페이지 확인에 사용합니다. 자동 OCR이 아닙니다.

Tool call template

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": {
      "id": "<id>"
    },
    "name": "render_material_page"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`page`	No
`fileId`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.0Oct 19, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), and the description adds the return format (PNG) plus the OCR caveat. It does not explain the id-vs-fileId distinction, the 1-600 page bound, or why the operation is marked non-idempotent/non-read-only, leaving behavioral gaps.

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?

Three short sentences with the core action front-loaded, and the final 'not automatic OCR' line earns its place by preventing a common misuse. No filler.

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

Completeness3/5

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

For a 3-parameter tool with no output schema, the description covers the return format and usage intent, but with 0% schema coverage and no output schema it should at least distinguish id from fileId. Adequate but with a clear gap around parameter meaning.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the full burden, and it says nothing about the required id parameter, the optional fileId, or how page numbering works. Merely implying 'one page of a PDF' does not clarify the two identifier schemes at all.

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 states a concrete verb and resource ('render one PDF page as a PNG image and return it') and pins the scope to a single page, which cleanly separates it from sibling text-extraction tools like read_material or download_material.

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 gives positive usage context (checking formulas, tables, figures, scanned pages) and an explicit exclusion ('not automatic OCR'), so an agent knows when this beats text-reading siblings. It stops short of naming the alternative tool to use instead for OCR/text needs.

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