easyaccesspdf-mcp

Name: easyaccesspdf-mcp
Author: luotwo

by luotwo

Overview Schema Related Servers Score Discussions

JavaScript

EasyAccessPDF — MCP Server Examples

English | Deutsch | Français | Español | 日本語

🌐 Official website: easyaccesspdf.com · Free PDF Checker · Pricing · MCP setup guide

Connect AI clients (Claude Code, Claude Desktop, Cursor, Codex) to the EasyAccessPDF MCP server: convert documents to Markdown, export PDFs to JSON/HTML/text, run veraPDF accessibility checks, and auto-fix PDF/UA issues — directly from your AI workflow.

Endpoint: https://easyaccesspdf.com/wp-json/easy/v1/mcp
Protocol: MCP over Streamable HTTP (JSON-RPC 2.0, protocol version 2025-03-26)
Auth: HTTP Basic — your EasyAccessPDF account email + a WordPress application password
Introspection: initialize, ping and tools/list answer without auth — only tools/call requires credentials
Site: https://easyaccesspdf.com/mcp/

Tools (5)

Tool	What it does	Cost
`eap_convert_to_markdown`	Document (PDF, DOCX, DOC, PPT, XLS, HTML, EPUB, RTF, ODT, TXT) → clean Markdown	Included with membership
`eap_export_pdf`	PDF → `json` (structured tree), `html`, `text`, or `annotated-pdf` (layout visualization, 24h download URL)	Included with membership
`eap_check_pdf`	veraPDF PDF/UA-1 (ISO 14289-1) accessibility audit: pages, grade A/B/C/F, issue list, tag coverage	Included with membership
`eap_get_account_status`	Plan, expiry, credit balance, current prices	Included with membership
`eap_fix_pdf`	Auto-tag + metadata injection + veraPDF re-audit → 24h download URL for a zip (tagged PDF + report + manual-review checklist)	1 credit per document — billed for members and non-members alike

All tools take a publicly accessible URL of the document (max 50MB). Documents are processed in the EU (Frankfurt) and not stored.

Input schemas (live from `tools/list`)

// eap_convert_to_markdown
{ "type": "object", "properties": { "url": { "type": "string" } }, "required": ["url"] }

// eap_export_pdf
{ "type": "object",
  "properties": {
    "url": { "type": "string" },
    "format": { "type": "string", "enum": ["json", "html", "text", "annotated-pdf"] } },
  "required": ["url", "format"] }

// eap_check_pdf
{ "type": "object", "properties": { "url": { "type": "string" } }, "required": ["url"] }

// eap_fix_pdf
{ "type": "object",
  "properties": { "url": { "type": "string" }, "title": { "type": "string" } },
  "required": ["url"] }

// eap_get_account_status
{ "type": "object", "properties": [] }

Related MCP server: MD-PDF MCP Server

1. Get your credentials

Create an account at https://easyaccesspdf.com/my-account/ and verify your email (6-digit code).
Buy the MCP Membership ($19.90 / 32 days, no auto-renewal — purchases stack) or credit packs for eap_fix_pdf.
In My Account → Profile → Application Passwords, create a new application password (e.g. named claude).
Build the Basic token: base64( youremail@example.com : your-application-password ).

# Linux / macOS
printf 'you@example.com:xxxx xxxx xxxx xxxx xxxx xxxx' | base64
# Windows PowerShell
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('you@example.com:xxxx xxxx xxxx xxxx xxxx xxxx'))

Keep the token private — it can spend your credits. Revoke any time in your WP profile.

2. Client setup

Claude Code

claude mcp add --transport http easyaccesspdf \
  https://easyaccesspdf.com/wp-json/easy/v1/mcp \
  --header "Authorization: Basic <BASE64>"
claude mcp list   # should show easyaccesspdf with 5 tools

Claude Desktop

%APPDATA%\Claude\claude_desktop_config.json (Windows) / ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "easyaccesspdf": {
      "type": "http",
      "url": "https://easyaccesspdf.com/wp-json/easy/v1/mcp",
      "headers": { "Authorization": "Basic <BASE64>" }
    }
  }
}

Cursor

~/.cursor/mcp.json (or project .cursor/mcp.json):

{
  "mcpServers": {
    "easyaccesspdf": {
      "type": "streamable-http",
      "url": "https://easyaccesspdf.com/wp-json/easy/v1/mcp",
      "headers": { "Authorization": "Basic <BASE64>" }
    }
  }
}

Codex (OpenAI)

~/.codex/config.toml:

[mcp_servers.easyaccesspdf]
url = "https://easyaccesspdf.com/wp-json/easy/v1/mcp"
http_headers = { "Authorization" = "Basic <BASE64>" }

Verify with codex mcp list.

Any stdio-only client (bridge)

Clients that only speak stdio MCP can use bridge/eap-mcp-bridge.mjs — a zero-dependency Node 18+ script that forwards stdio JSON-RPC to the hosted endpoint. A Dockerfile is included for containerized runners.

{
  "mcpServers": {
    "easyaccesspdf": {
      "command": "node",
      "args": ["bridge/eap-mcp-bridge.mjs"],
      "env": { "EAP_TOKEN": "<BASE64>" }
    }
  }
}

Or with Docker: docker build -t eap-mcp-bridge . && docker run -i --rm -e EAP_TOKEN=<BASE64> eap-mcp-bridge. Without EAP_TOKEN the bridge still answers initialize / tools/list (introspection is open); tools/call then returns the upstream 401.

3. Minimal clients (no SDK)

See examples/python_client.py and examples/node_client.mjs — plain HTTP/JSON-RPC, no dependencies beyond requests / Node 18+.

python examples/python_client.py
node examples/node_client.mjs

Both run: initialize → tools/list → eap_get_account_status and print the results.

Billing transparency

Membership ($19.90 / 32 days, stacking, no auto-renewal) includes unlimited conversions, exports, checks, and account status.
eap_fix_pdf always costs 1 remediation credit per document ($2.99 single-fix value; credit packs bring it to $0.67) — for members and non-members alike. Membership has no fix privilege.
Credits never expire. Pricing: https://easyaccesspdf.com/pricing/

License

MIT — see LICENSE. Examples only; EasyAccessPDF is a commercial service operated by HEPA Zweigniederlassung der RUBIX GmbH, Germany.

Available Tools

5 tools

eap_check_pdfAInspect

Check a PDF for accessibility compliance (PDF/UA-1, ISO 14289-1) using veraPDF. Included with membership — no credits charged. Returns pages, grade (A/B/C/F), issue list, tag coverage. Pass a publicly accessible URL of the PDF.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Publicly accessible URL of the PDF (max 50MB)

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description bears the full burden. It explains the tool returns pages, grade, issue list, and tag coverage, and clarifies it uses veraPDF. The cost behavior is also disclosed ('no credits charged'). There is no contradiction with annotations.

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 brief (two sentences) and well-structured. It fronts the purpose, then lists key outputs and requirements. No unnecessary 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?

For a single-parameter tool with no output schema, the description adequately covers inputs (URL constraints) and outputs (grade, issues, etc.). It mentions standards and cost. Lacks error handling details, but overall sufficient.

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%, but the description adds value by specifying that the URL must be publicly accessible and has a 50MB size limit, which is not in the schema description alone.

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 checks PDF accessibility compliance using specific standards (PDF/UA-1, ISO 14289-1) and lists the outputs (pages, grade, issue list, tag coverage). It distinguishes from sibling tools (e.g., convert, fix) by focusing on checking/analysis.

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 specifies that a publicly accessible URL is required and mentions the 50MB limit. It also notes 'included with membership — no credits charged'. However, it does not explicitly state when to use this tool versus alternatives, though the sibling tools are clearly different in function.

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

eap_convert_to_markdownAInspect

Convert a document to clean Markdown (included with membership, no credits). Formats: PDF, Word (.docx/.doc), PowerPoint, Excel, HTML, EPUB, RTF, ODT, TXT. Pass a publicly accessible URL of the document.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Publicly accessible URL of the document (max 50MB)

TDQS

A4/5.0

Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It mentions the tool is free and has a 50MB size limit, but does not disclose what happens on failure, whether it is read-only, or any authentication requirements. The lack of such details hinders safe invocation.

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 a single, well-structured sentence that front-loads the core action and includes a clear list of supported formats. Every word contributes to understanding, with no 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?

For a tool with one parameter and no output schema, the description covers the essential aspects: purpose, supported formats, cost, and input requirement (public URL). It does not explicitly state the output format (Markdown is implied by the name), but it is sufficient for an agent to use correctly. Minor omission: no mention of return type or error behavior.

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% for the single parameter 'url', which the schema describes as 'Publicly accessible URL'. The description adds value by listing supported document formats (PDF, Word, etc.), which is not in the schema, thus helping the agent understand what types of URLs are acceptable.

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 converts documents to Markdown, specifies supported formats, and distinguishes itself from siblings which are PDF-specific operations. The verb 'convert' and resource 'document to Markdown' are explicit.

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 tells when to use (to convert documents to Markdown), the required input (a publicly accessible URL), and lists supported formats. It lacks explicit alternatives or when-not-to-use, but the sibling tools are obviously different, providing implicit guidance.

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

eap_export_pdfAInspect

Export a PDF to another format (included with membership, no credits). Formats: json (structured document tree), html, text (plain text), annotated-pdf (layout visualization with labeled structure boxes — returned as a 24h download URL). Pass a publicly accessible URL of the PDF.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Publicly accessible URL of the PDF (max 50MB)
`format`	Yes	Output format

TDQS

A4.5/5.0

Behavior4/5

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

Discloses that the tool is included with membership and uses no credits, which is valuable behavioral context. Also explains the annotated-pdf output format (24h download URL). However, it does not describe return types for json, html, or text outputs, nor mention any side effects or rate limits. With no annotations, the description reasonably covers the key aspects.

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?

Two sentences with no wasted words. The key action and formats are front-loaded. Every sentence adds value—the first gives purpose and membership info, the second details formats. Highly efficient.

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?

Given the tool has 2 parameters, no output schema, and no annotations, the description covers the core purpose and parameter details well. It lacks explicit description of return values for json, html, and text formats, but the schema's explainability and the tool's simplicity (likely returns the converted file directly) make it mostly complete. The missing return details are a minor gap.

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?

Adds significant meaning beyond the input schema by explaining each format: 'json (structured document tree)', 'annotated-pdf (layout visualization with labeled structure boxes — returned as a 24h download URL)'. The schema only gives enum names and basic descriptions, so the description enriches parameter understanding.

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?

Clearly states 'Export a PDF to another format' and lists the specific formats (json, html, text, annotated-pdf). The verb 'Export' and resource 'PDF' are explicit, and the tool name and description distinguish it from siblings like eap_check_pdf, eap_convert_to_markdown, etc.

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?

Provides clear context: 'Pass a publicly accessible URL of the PDF' and notes membership inclusion. Does not explicitly state when not to use or compare with alternatives, but the specificity of formats and the mention of membership provide sufficient guidance for typical use.

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

eap_fix_pdfAInspect

Auto-fix a PDF for accessibility: injects metadata, auto-tags the document, re-audits with veraPDF. Costs 1 remediation credit per document ($2.99 single-fix value) — billed for members and non-members alike; membership does not include auto-fix. Returns a 24h download URL for a zip package (tagged PDF + veraPDF report + manual-review checklist). Pass a publicly accessible URL of the PDF.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Publicly accessible URL of the PDF (max 50MB)
`title`	No	Optional document title used for metadata and file naming

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses actions, return format (24h URL with zip), and cost. Missing details on failure modes, whether original PDF is unchanged, and auth requirements.

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?

Description is concise with three sentences, front-loading the purpose. Includes relevant billing info. No unnecessary verbiage.

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?

Covers input (URL), process (auto-fix, re-audit), output (zip with three files), and constraints (cost, 24h URL). Lacks details on error handling but is sufficient given no output schema.

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 coverage is 100% with descriptions for both url and title. Description adds only the 'publicly accessible' constraint for url, which is already in schema. No significant extra meaning.

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?

Clearly states the tool auto-fixes PDFs for accessibility, listing specific actions (inject metadata, auto-tag, re-audit). Distinguishes from siblings like eap_check_pdf (check only) and eap_convert_to_markdown (conversion).

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?

States cost and that membership does not include auto-fix, and requires a publicly accessible URL. Does not explicitly say when to use or not, but purpose is clear enough to infer.

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

eap_get_account_statusAInspect

Get the EasyAccessPDF account status: membership plan, expiry date, remaining PDF credits, current service prices.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It describes what information is retrieved but does not state that the operation is read-only or provide any safety or authorization notes.

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?

Single sentence that is front-loaded with the verb and resource, concise with no unnecessary 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?

For a tool with no parameters and no output schema, the description adequately lists the information returned. Could be improved by explicitly stating it is a read-only operation.

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?

No parameters exist; schema coverage is 100% (empty). Description adds meaning by listing the account status fields returned, going beyond the schema's lack of parameters.

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?

Description clearly states the tool retrieves account status and lists specific fields (membership plan, expiry, credits, prices). It distinguishes from sibling tools which operate on PDF files.

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?

Description implies usage for checking account status but does not explicitly state when to use it versus alternatives, nor provides when-not guidance. Sibling tools are contextually distinct, but no explicit usage guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.0.0Jul 22, 2026
- First observedeap_check_pdf
- First observedeap_convert_to_markdown
- First observedeap_export_pdf
- First observedeap_fix_pdf
- First observedeap_get_account_status

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: checking accessibility, converting to Markdown, exporting to various formats, auto-fixing, and account status. There is no functional overlap.

Naming Consistency5/5

All tools follow a consistent 'eap_verb_noun' pattern, making it easy to predict tool names and their actions.

Tool Count5/5

Five tools is well-scoped for a PDF accessibility service, covering core operations without unnecessary bloat.

Completeness5/5

The toolset covers the full lifecycle: checking, fixing, exporting, converting, and account management. No obvious gaps for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

Mdkit A
online.mdkit
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Developer Tools RAG Systems Data Platforms
31
PDF to Markdown (pdf2md.dev)
dev.pdf2md
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
AI & Machine Learning Image & Video Processing
2
blinkpdfOAuth
io.blinkpdf
Render Markdown and LLM output into accessible PDF/UA-1 PDFs. No headless Chromium.
Developer Tools
2
api2pdf A
io.usefulapi
MCP server for Api2Pdf — generate PDFs & images from HTML, URLs or office files; merge, barcodes.
Developer Tools File Systems
162

Related MCP Servers

doc-ops-mcp
Documentation Access Content Management Systems
Tele-AI
A
license
B
quality
D
maintenance
A universal MCP server for document processing, conversion, and automation. Handle PDF, DOCX, HTML, Markdown, and more through a unified API and toolset.
Updated 6 days ago (2026-08-31 09:18 UTC)
13
33
139
MIT
MD-PDF MCP Server
Developer Tools File Systems
kareemaly
F
license
A
quality
D
maintenance
An MCP server that enables bidirectional conversion between Markdown and PDF formats, including text extraction from specific pages and metadata retrieval. It supports customizable PDF output sizes and document processing through standard MCP tools.
Updated a year ago (2025-06-26 16:46 UTC)
5
1
-
pymupdf4llm-mcpofficial
File Systems
pymupdf
A
license
Not graded
quality
B
maintenance
MCP server for exporting PDF to markdown, optimized for LLM consumption.
Updated 2 months ago (2026-07-02 13:12 UTC)
72
AGPL 3.0
polydoc-mcpofficial
Browser Automation File Systems
polydoc-tech
A
license
Not graded
quality
C
maintenance
MCP server that converts HTML or URLs to PDF, captures screenshots, and generates EU-compliant e-invoices (Factur-X/ZUGFeRD).
Updated a month ago (2026-07-31 23:17 UTC)
65
MIT

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/luotwo/easyaccesspdf-mcp'

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

EasyAccessPDF — MCP Server Examples

Tools (5)

Input schemas (live from tools/list)

1. Get your credentials

2. Client setup

Claude Code

Claude Desktop

Cursor

Codex (OpenAI)

Any stdio-only client (bridge)

3. Minimal clients (no SDK)

Billing transparency

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

pymupdf4llm-mcpofficial

polydoc-mcpofficial

Latest Blog Posts

MCP directory API

Input schemas (live from `tools/list`)