Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pdf-chart-parser Extract the usage chart from my electricity bill PDF."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server and Python library that extracts energy-usage charts from utility-bill PDFs. It locates the chart, calibrates the axes from the PDF's text layer, and returns structured time-series data alongside an annotated PNG for visual verification — entirely deterministic, no LLM required.
Bar, line, and hybrid (bar + line, dual y-axis) chart types
Vector-first extraction via PyMuPDF get_drawings() / get_text("dict"); OpenCV raster fallback for scanned PDFs
Scanned-PDF support via an OCRmyPDF text-layer step (optional [ocr] extra): image-only pages get a searchable text layer so they flow through the same high-accuracy text-layer calibration as digital PDFs
Full page text returned as LLM-friendly Markdown (via pymupdf4llm)
MCP tool (extract_usage_chart) compatible with Claude and other MCP-aware LLMs
Supports stdio transport (local) and streamable-http (containerized deployment)
Returns structured JSON + annotated PNG; numeric data is always text content
Related MCP server: DeepSeek PDF Reader
Python 3.12+
uv package manager
Tesseract OCR (required only for the [raster] extra): apt-get install tesseract-ocr or brew install tesseract
OCRmyPDF system tools (required only for the [ocr] extra, which adds a searchable text layer to scanned PDFs): apt-get install ghostscript qpdf unpaper pngquant tesseract-ocr or brew install ocrmypdf
# Install (vector path only)
uv sync
# Install with raster fallback
uv sync --extra raster
# Install with the OCR text-layer step for scanned PDFs
uv sync --extra ocr
# Install everything
uv sync --extra raster --extra ocr
# Run the CLI
uv run pdf-chart-parser --help
# Run the MCP server (stdio)
uv run python -m pdf_chart_parser.serverfrom pdf_chart_parser.pipeline import extract_usage_chart
result = extract_usage_chart(pdf_path="bill.pdf", return_annotated_image=True)
print(result["chart_type"]) # "bar" | "line" | "hybrid"
for series in result["series"]:
print(series["label"], series["points"])uv run pdf-chart-parser extract bill.pdf --output result.jsonAdd to your MCP config (~/.claude/claude_desktop_config.json or similar):
{
"mcpServers": {
"pdf-chart-parser": {
"command": "uv",
"args": ["run", "python", "-m", "pdf_chart_parser.server"],
"cwd": "/path/to/pdf-chart-parser"
}
}
}The server exposes the extract_usage_chart tool. It returns:
Page text — full page as Markdown
Chart reading — structured JSON (series, axes, confidence, warnings)
Annotated PNG — cropped chart with calibrated gridlines and data-point markers
# Build and run locally
./scripts/run_local_server.sh
# Build and push to ECR (set ECR_REPO first)
export ECR_REPO=<account>.dkr.ecr.<region>.amazonaws.com/pdf-chart-parser
./scripts/build_and_push.shThe container starts the server on streamable-http at port 8000. A local PDF directory can be bind-mounted to /data for ad-hoc testing (see docker/docker-compose.yml).
# In-process test against fixtures
uv run python scripts/run_manual_tests.py
# Against a running HTTP server
uv run python scripts/run_manual_tests.py --http http://localhost:8000Output is written to manual_test_output/.
AGPL-3.0-or-later. This license is required because the project links against PyMuPDF, which is itself AGPL-3.0 licensed.
Extract energy-usage chart data from a utility-bill PDF.
Returns the full page text as Markdown, structured chart data as JSON, and optionally an annotated PNG of the chart region.
Provide exactly one of pdf_path, pdf_base64, or pdf_url.
The result includes a 'series' list. When the chart contains multiple utility types (e.g. electricity and gas on the same chart), each type is returned as a separate Series entry with its own 'id' ('s0', 's1', …) and 'color'. The caller is responsible for determining which series corresponds to which utility — use the bar colors, the series order, and the page Markdown context to make that determination.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_path | No | ||
| pdf_base64 | No | ||
| pdf_url | No | ||
| page | No | ||
| chart_type | No | auto | |
| value_unit | No | auto | |
| return_annotated_image | No | ||
| render_dpi | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must disclose behavioral traits. It explains the output structure (Markdown, JSON, optional image) and highlights a key non-determinism: the caller must determine which series corresponds to which utility. It does not mention error handling or authentication, but the core behavior is well-described.
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 concise and well-structured: first sentence states purpose, second lists outputs, third gives input constraint, then addresses output ambiguity. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.
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 has 8 parameters, no schema descriptions, no annotations, and no output schema, the description covers the essential aspects: input requirements, output structure, and an important ambiguity resolution. It falls short only by not describing all parameters (page, chart_type, value_unit, render_dpi) and not specifying error cases. Still, it provides substantial context for an AI agent.
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?
The input schema has 8 parameters with 0% description coverage. The description adds meaning for a few parameters: the mutual exclusivity of pdf_path, pdf_base64, and pdf_url, and the optionality of return_annotated_image. However, it does not explain page, chart_type, value_unit, or render_dpi, leaving the agent to infer their purposes from the schema enums and defaults.
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's purpose: 'Extract energy-usage chart data from a utility-bill PDF.' It specifies the input (PDF) and outputs (Markdown, JSON, optional annotated PNG), leaving no ambiguity about what the tool does.
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 provides explicit guidance on input: 'Provide exactly one of pdf_path, pdf_base64, or pdf_url.' It also explains how to interpret the output series when multiple utilities are present. However, it does not mention when to avoid using this tool or any prerequisites, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0extract_usage_chartOnly one tool exists, so there is zero ambiguity. An agent cannot confuse it with any other tool in the set.
With a single tool, naming consistency is trivially maintained. The name 'extract_usage_chart' follows a clear verb_noun pattern.
A single tool is appropriate for the narrow, focused domain of extracting chart data from utility bill PDFs. Adding more tools would likely be unnecessary.
For its stated purpose of extracting energy-usage chart data, the tool provides text, structured JSON, and optional annotated images. There are no obvious gaps in the surface for this specific task.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
MCP server for detecting and redacting PII (Personally Identifiable Information) in PDF documents.
An MCP server that provides congressional transcripts
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/haoxinm/pdf-chart-parser'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
