pdf-inspector-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
detect_pdf and classify_pdf are nearly identical, both returning type, page count, and OCR pages, with only minor differences in speed/confidence. process_pdf also overlaps with all extraction tools, making tool boundaries unclear.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern (e.g., process_pdf, extract_text, extract_pages_markdown). No mixed conventions or vague verbs.
Tool Count4/5
Seven tools is within a reasonable range, but the redundancy between detect_pdf and classify_pdf suggests the count could be trimmed. Still, it does not feel overwhelming.
Completeness4/5
The set covers detection, classification, plain text extraction, positioned text extraction, region-based extraction, and markdown conversion. Minor gaps like PDF metadata or OCR output are not critical to the inspection purpose.
Average 3.7/5 across 7 of 7 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavior. It only describes inputs and does not mention limitations (e.g., scanned PDFs, file size), error behavior, or output format, leaving the agent without expectations beyond the apparent read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, with a one-line summary followed by a short Args block. Every sentence contributes, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the basic operation is clear and an output schema exists so return values need not be documented, the description omits usage context among the sibling tools and any limitations. For a simple tool this is minimal but not fully contextual.
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?
Both parameters receive meaningful descriptions: path is an absolute local file path, and data is base64-encoded PDF bytes. This fully compensates for the 0% schema coverage, though it does not clarify whether the parameters are mutually exclusive or can be combined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool extracts plain text from a PDF, naming both the resource and the output type. The phrase 'plain text' distinguishes it from sibling tools that extract with positions or regions, though it could explicitly mention full-document extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like extract_text_with_positions or extract_pages_markdown. The description only documents the arguments and leaves the agent to infer usage context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It does not mention any behavioral details such as output format, failure modes, coordinate system, ordering of results, or resource limits. The one-line summary does not explain what the tool does beyond the basic action, leaving the agent to guess at runtime behavior.
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?
The description is compact and front-loaded with the action summary. The Args section is clearly formatted as a list, providing structural separation. It earns high marks for brevity, but loses a point for the redundancy of restating the schema property names without additional context and for the lack of any semantic grouping (e.g., input source vs. region specification).
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?
With three parameters and a nested object structure, the description provides enough to construct a basic invocation, but it lacks important contextual information such as the output schema's return format (even though an output schema exists, it is not shown), the coordinate system used (e.g., PDF points vs pixels), and any constraints or edge cases. The lack of usage alternatives further reduces completeness for an agent operating alongside sibling PDF tools.
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 description coverage is 0%, meaning the schema provides no descriptions. The description compensates by explicitly explaining the purpose of each parameter: 'path' as absolute filesystem path, 'data' as base64-encoded PDF bytes, and 'page_regions' with a detailed structure including page index and region coordinates. This adds genuine meaning beyond the bare type definitions, though it does not clarify the mutuality between path and data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Extract text from specific bounding-box regions on pages' clearly specifies a distinct verb, resource, and scope, distinguishing itself from sibling tools like extract_text or extract_text_with_positions which likely operate on entire pages or different position granularity. However, it does not explicitly name alternatives, so it stops short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus sibling tools. There is no mention of prerequisites, when to choose region-based extraction over full-page extraction, or any constraints on the PDF source (e.g., local file vs base64 data). The Args section implies two mutually exclusive input methods but does not clarify the choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists operations but omits critical details such as how path and data inputs are resolved (precedence or mutual exclusivity), error handling, and behavior when neither input is provided. This is a significant transparency gap for a composite 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?
The description is compact and well-structured, starting with a clear overview followed by a brief parameter list. It is front-loaded and avoids verbosity, though the parameter section could be slightly expanded without losing conciseness.
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?
Given the tool's composite nature and lack of annotations, the description is adequate but incomplete. The output schema covers return values, but the description does not address input conflict resolution or provide usage context relative to siblings. The absence of annotations raises the bar for behavioral disclosure, which the description only partially meets.
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?
The description manually explains all parameters: path as absolute filesystem path, data as base64-encoded bytes, and pages as optional 0-indexed list. This adds meaning beyond the schema's bare type/nullable definitions. However, it does not clarify the relationship or precedence between path and data, which is a minor omission.
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 clearly states the tool's full scope: 'detect type, extract text, and convert to Markdown.' This specific verb+resource combination distinguishes it from sibling tools like extract_text or detect_pdf, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for combined PDF processing but does not explicitly state when to use it instead of siblings. No alternatives or exclusions are mentioned, leaving usage context inferred from the listed operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the tool's non-extraction nature and mentions 'fast' behavior, but lacks details on error handling, file access implications, or parameter precedence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose and output. The argument documentation is concise and directly useful, with no filler words.
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?
The tool is simple and has an output schema, and the description covers purpose, usage, and parameter meanings. It lacks edge-case details and explicit guidance on choosing between path and data, but is generally adequate for a lightweight detection tool.
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?
With 0% schema coverage, the description compensates by explaining both parameters: path as an absolute filesystem path and data as base64-encoded bytes. It does not clarify mutual exclusivity or which takes precedence, but provides meaningful definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool detects PDFs and returns type, page count, and pages needing OCR. It clearly distinguishes from full-text extraction tools by emphasizing 'quick classification', but does not explicitly differentiate from the sibling classify_pdf.
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 explicitly says 'Use this for quick classification without full text extraction', providing a clear when-to-use context. However, it does not name specific alternatives, leaving the distinction from classify_pdf implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses useful behavioral details such as the 0-indexed input vs. 1-indexed output page numbers and the inclusion of layout metadata. However, it omits other behaviors like error handling, whether path and data are mutually exclusive, or performance implications, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, leading with the core purpose, then a crucial indexing note, followed by a simple bulleted Args list. Every sentence contributes meaningful information, and there is no redundancy or filler.
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?
The description covers the essential input parameters, output content type, and the indexing nuance, which is sufficient given the presence of an output schema. It falls short on practical usage details like when to use path vs. data, and does not mention potential error scenarios, but overall it provides a solid foundation for using the tool.
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?
The input schema has zero description coverage, so the description's Args section is essential. It provides clear semantics for 'path' (absolute local path), 'data' (base64 PDF bytes), and 'pages' (optional 0-indexed list), adding value beyond the raw schema. It does not, however, clarify the relationship between path and data (e.g., if exactly one must be provided).
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 clearly states a specific action: 'Extract per-page Markdown with layout metadata.' It distinguishes itself from siblings like extract_text and extract_text_with_positions by specifying Markdown output with tables, columns, and OCR info, making the tool's unique purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its clear purpose but provides no explicit guidance on when to choose this tool over alternatives like extract_text or extract_text_with_positions, nor does it mention exclusions or prerequisites. The context is clear enough to infer typical use, but no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return structure (TextItem fields) and parameter types, but does not address behavioral details such as error handling, mutual exclusivity of path/data, or read-only guarantees. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: clear purpose, return type, and Args. Each sentence adds necessary information without redundancy.
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?
The description covers the main invocation requirements and output, but it leaves ambiguity about whether path and data are mutually exclusive or if at least one is required. This could cause incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions, but the Args section fully explains each parameter: path (absolute path), data (Base64 bytes), pages (optional zero-indexed list). This compensates completely for the missing schema descriptions.
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 uses a specific action ('Extract text items') on a PDF resource, with explicit qualifiers ('with position, font, and style metadata') that differentiate it from sibling tools like extract_text. It clearly states the tool's scope and distinct value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by highlighting the positional and style metadata, but it does not explicitly state when to use this tool instead of alternatives like extract_text or extract_text_in_regions. No exclusions or preferred contexts are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the return type and output fields, plus performance characteristics ('lightweight', 'faster'), but does not mention input requirements (e.g., whether path or data is required, precedence if both given), error conditions, or side effects. This is adequate but has clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single-sentence summary, one comparison sentence, and a short Args list. Every sentence adds value with no redundancy or filler.
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?
The tool has simple parameters and an output schema (so return details are covered). The description explains purpose, performance trade-off, and parameter formats. Minor missing piece is guidance on choosing between path and data, but overall it is reasonably complete for the tool's complexity.
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 0%, so the description must explain parameters. It provides useful semantic details: path is an absolute local filesystem path, data is base64-encoded PDF bytes. This goes beyond the schema, though it does not clarify the relationship or requiredness between the two optional-looking params.
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 uses a specific verb ('classify') with a clear resource ('PDF') and lists concrete outputs (type, page count, OCR pages, confidence). It also distinguishes itself from the sibling detect_pdf by noting it is 'faster' and returns a PdfClassification without full analysis, making its scope clear.
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?
The description provides clear context by explicitly comparing to detect_pdf and framing this as the lightweight/faster alternative. It does not enumerate every sibling exclusion, but the 'Faster than detect_pdf — returns a PdfClassification without full analysis' implies when to choose this tool over full analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pdf-inspector-mcp MCP server](https://glama.ai/mcp/servers/jayluxferro/pdf-inspector-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jayluxferro/pdf-inspector-mcp)

Score Badge

Copy to your README.md:

[![pdf-inspector-mcp MCP server](https://glama.ai/mcp/servers/jayluxferro/pdf-inspector-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jayluxferro/pdf-inspector-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jayluxferro/pdf-inspector-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server