md24de-mcp
This MCP server provides access to heating and hot-water consumption data from the German utility portal messdienst24.de.
Tools:
get_last_available_month— Retrieve the year and month of the most recently published consumption report.get_consumption_report— Obtain the full structured consumption report, including your kWh usage vs. average comparable households, comparisons to previous month and previous year, historical monthly readings, and property/object information.save_pdf— Download the official monthly UVI (unterjährige Verbrauchsinformation) PDF and save it to a local directory (default:~/Downloads), returning the file path, filename, reporting period, and file size.
Resources:
md24de://latest-report/pdf— Access the latest monthly UVI PDF directly in-memory (asapplication/pdf) without saving to disk.
Additional notes:
Results are cached in memory (default 30 minutes) to minimize portal requests; the PDF cache is shared between
save_pdfand the resource.Credentials are never logged; all communication is over HTTPS.
Supports natural-language queries like "How much heating energy did I use last month?" or "Compare my usage to last year."
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., "@md24de-mcpShow me my latest heating and hot water consumption."
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.
md24de-mcp
Unofficial Model Context Protocol (MCP) server for the messdienst24.de utility-consumption portal.
Wraps python-md24de to expose heating and hot-water consumption data as MCP tools that any MCP-compatible AI client can invoke.
Disclaimer — This project is not affiliated with, endorsed by, or in any way officially connected with messdienst24.de or its operators. Use at your own risk.
Resources
Resource URI | Description |
| The monthly UVI PDF document (application/pdf) |
Related MCP server: mastr-mcp-server
Tools
Tool | Description |
| Returns the year/month for which the portal currently provides data |
| Returns the full heating and hot-water consumption report |
| Saves the monthly consumption PDF to a local directory on disk |
get_last_available_month
Returns { "year": int, "month": int }.
get_consumption_report
Returns structured consumption data with the following shape:
{
"year": 2025,
"month": 4,
"object_info": { "object_number": "…", "address": "…" },
"heating": {
"your_kwh": 111.1,
"average_kwh": 222.2,
"vs_average": "less",
"vs_previous_month": "more",
"vs_previous_year": null,
"history": [
{ "year": 2025, "month": 4, "your_kwh": 111.1, "average_kwh": 222.2 },
{ "year": 2025, "month": 3, "your_kwh": 333.3, "average_kwh": 444.4 }
]
},
"hot_water": { "…": "…" }
}Comparison values are "less", "more", "equal", or null when unavailable.
save_pdf
Renders the PDF locally and saves it to a local directory on disk, returning:
{
"saved_to": "/Users/you/Downloads/verbrauch-2025-04.pdf",
"filename": "verbrauch-2025-04.pdf",
"year": 2025,
"month": 4,
"size_bytes": 123456
}The optional directory parameter controls where the file is saved (default: ~/Downloads).
To read the PDF content directly without saving to disk, use the resource
md24de://latest-report/pdf instead.
Note: The messdienst24.de portal no longer offers a downloadable PDF, so both the
save_pdftool and themd24de://latest-report/pdfresource render the UVI document locally via python-md24de (reportlab/Pillow, pulled in through its[pdf]extra — already a required dependency of this server, no extra setup needed).
Example prompts
Once connected to Claude Desktop, you can ask:
"How much heating energy did I use last month?"
"Am I using more or less heating than comparable households?"
"Show me my hot-water consumption trend over the past months."
"Compare my heating usage to last year's same month."
"Give me a summary of my energy consumption."
"Save my monthly consumption PDF to my Downloads folder."
"Save my monthly consumption PDF to my Desktop."
"Read my monthly UVI PDF document."
"Which month's data is currently available on messdienst24.de?"
Client lifecycle and caching
Each tool creates a fresh Md24deClient, performs the minimum required requests, then
closes the connection. This avoids server-side session timeouts for long-running processes.
Results are cached in memory for a configurable TTL (default 30 minutes):
Tool / Resource | Caches |
| available month |
| available month + consumption report |
| available month + PDF bytes |
| available month (if not already warm) + PDF bytes |
The save_pdf tool and the md24de://latest-report/pdf resource share the same PDF cache.
Reading one and then calling the other makes only one portal request.
Configuration
All configuration is provided via environment variables.
Variable | Required | Default | Description |
| ✓ | — | Short portal ID (the |
| ✓ | — | Portal login username |
| ✓ | — | Portal login password |
|
| HTTP request timeout in seconds | |
|
| Cache time-to-live in seconds | |
|
| Python logging level ( |
Installation
This package is not published on PyPI. The recommended way to install it for use with
Claude Desktop or other MCP clients is pipx, which installs
the md24de-mcp command globally while keeping its dependencies isolated:
pipx install "git+https://github.com/volsch/md24de-mcp.git@vX.Y.Z"Or with uv:
uv tool install "git+https://github.com/volsch/md24de-mcp.git@vX.Y.Z"Both put md24de-mcp on your PATH so MCP clients can launch it by name.
To upgrade to a newer version, replace vX.Y.Z and run pipx upgrade md24de-mcp or
uv tool upgrade md24de-mcp.
Running
export MD24DE_TENANT=xy
export MD24DE_USERNAME=your_user
export MD24DE_PASSWORD=your_pass
md24de-mcpMCP client configuration
Claude Desktop
1. Install the server (see Installation above, e.g. with pipx):
pipx install "git+https://github.com/volsch/md24de-mcp.git@vX.Y.Z"2. Add it to the Claude Desktop config.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"md24de": {
"command": "md24de-mcp",
"env": {
"MD24DE_TENANT": "xy",
"MD24DE_USERNAME": "your_user",
"MD24DE_PASSWORD": "your_pass"
}
}
}
}Replace xy, your_user, and your_pass with your actual messdienst24.de credentials.
The tenant ID is the md= value from your portal login URL (e.g. https://messdienst24.de/?md=xy).
3. Restart Claude Desktop.
4. Verify the connection.
A 🔧 icon in the chat input bar confirms the server is connected.
Click it to see the list of available tools (get_last_available_month, get_consumption_report, save_pdf) and the resource (md24de://latest-report/pdf).
5. Try an example prompt (see Example prompts above), e.g.:
"How much heating energy did I use last month?"
Logging
The server uses Python's standard logging module under the md24de_mcp logger hierarchy
and registers a NullHandler so no output appears unless the calling process configures
logging explicitly.
Set the LOG_LEVEL environment variable to control verbosity:
{
"mcpServers": {
"md24de": {
"command": "md24de-mcp",
"env": {
"MD24DE_TENANT": "xy",
"MD24DE_USERNAME": "your_user",
"MD24DE_PASSWORD": "your_pass",
"LOG_LEVEL": "DEBUG"
}
}
}
}Debug messages include cache hits/misses, available month/year values, and byte counts.
The underlying md24de library also emits debug messages (HTTP status codes, parsed dates).
Credentials (username, password) are never written to any log message.
Development
git clone https://github.com/volsch/md24de-mcp.git
cd md24de-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"Run the test suite:
pytestType-check:
pyright src/Lint and format:
ruff check src/ tests/
ruff format src/ tests/Legal
Legal context for the data
The monthly consumption report accessed through this server is the unterjährige Verbrauchsinformation (UVI) — a legally mandated document under §6a of the German Heating Cost Ordinance (Heizkostenverordnung, HeizkostenV). Under §6b HeizkostenV, consumption data may only be collected and used for billing purposes and to fulfil the legal information obligations. This server retrieves your own data from the portal provided for exactly that purpose.
Unofficial project
This server is not an official product of messdienst24.de. It was built by observing the portal's web interface for personal and educational use. It does not circumvent any technical protection measures and only uses credentials that the account holder provides themselves.
Credentials and privacy
Your username and password are passed directly to the messdienst24.de servers over HTTPS via the underlying python-md24de library. This server does not store or log credentials. However, any direct or indirect dependency — such as HTTP client internals, logging back-ends, or network proxies configured in your environment — is outside this server's control and may handle the data differently.
Consumption data fetched from the portal is held in memory only for the duration of the cache TTL and is never written to disk by this server.
No warranty
The portal's HTML structure can change at any time without notice, which may break the underlying library. The software is provided "as is" — see the LICENSE for full terms.
Terms of service
Before using this server, ensure your use complies with the messdienst24.de terms of service. Automated access may be restricted by those terms.
License
MIT © 2026 Volker Schmidt
Available Tools
3 toolsget_consumption_reportA
Return the heating and hot-water consumption report from messdienst24.de.
messdienst24.de is a German utility-consumption portal. This tool retrieves the full structured consumption data for your residential property. The report covers the most recently published month (returned as year/month at the top level) and also includes a history of several previous months so that trends can be analysed.
The response includes: year, month: The current reporting period (e.g. year=2025, month=4 for April 2025). object_info: Property address and object number assigned by the service provider. heating: Heating consumption data (see below). hot_water: Hot-water consumption data (same structure as heating).
Each meter section (heating / hot_water) contains: your_kwh: Your consumption for the current reporting month in kWh equivalent. average_kwh: Average consumption of comparable households in kWh equivalent. vs_average: How your usage compares to similar households this month. "less" = you used less, "more" = you used more, "equal" = same. null if the comparison is unavailable. vs_previous_month: How your usage compares to the previous month (same values). null if unavailable. vs_previous_year: How your usage compares to the same month last year (same values). null if unavailable. history: List of monthly readings for several past months, newest first. Each entry has year, month, your_kwh, average_kwh. history[0] always corresponds to the current reporting month.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details response structure and null handling. However, it does not explicitly state it is read-only or mention authentication or rate limits.
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?
Well-structured with bullet points and front-loaded purpose. Slightly verbose given an output schema exists, but every sentence adds value.
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?
Complete for a no-parameter tool with output schema. Covers purpose, data source, response structure, and null handling. No missing essential information.
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?
No parameters exist, so schema coverage is 100%. The description adds meaning by explaining the output structure in detail, which enriches understanding beyond the empty schema.
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 returns a heating and hot-water consumption report from messdienst24.de. It specifies the resource and distinguishes from siblings like get_last_available_month and save_pdf.
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?
Usage is implied but not explicit. No instructions on when to use this vs alternatives or when not to use it. Siblings suggest differentiation but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_last_available_monthA
Return the month and year of the most recently published consumption report.
messdienst24.de is a German utility-consumption portal that provides the legally mandated monthly heating and hot-water consumption report (Verbrauchsinformation) for residential properties. The portal publishes one report per calendar month (always a previous month, never the current one). This tool returns which month that currently published report covers.
Call this tool when you only need to know the current reporting month without fetching the full report. The full report (get_consumption_report), the PDF resource (md24de://latest-report/pdf), and the save_pdf tool all include this information as well.
Returns: year: Four-digit year of the current reporting month (e.g. 2025). month: Month number 1–12 of the current reporting month (e.g. 4 for April).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only operation but does not explicitly state safety or side effect absence. For a simple query tool, this is adequate but lacks explicit behavioral disclosure.
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 well-structured with a clear summary, context, usage guidance, and return details. It is slightly verbose with background information, but overall efficient and front-loaded.
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?
Despite no parameters and no annotations, the description completely covers the tool's functionality. It explains the context, lists return fields with formats, and references sibling tools, making it self-contained for a simple query tool.
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?
There are no parameters, so the baseline is 4. The description adds value by detailing the return structure (year and month with formats), which goes beyond the empty schema.
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 identifies the tool's purpose: returning the month and year of the most recently published consumption report. It uses specific verbs ('Return') and resources ('consumption report'), and distinguishes from sibling tools by noting that the full report includes this information.
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 explicitly states when to use this tool ('when you only need to know the current reporting month without fetching the full report') and mentions alternatives that contain the same information (get_consumption_report, PDF resource, save_pdf).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_pdfA
Download the monthly consumption PDF and save it to disk.
This is the legally mandated unterjährige Verbrauchsinformation (UVI) document — a German statutory heating-cost information notice that property owners are required to provide to tenants under §6a HeizkostenV. The document is generated by the messdienst24.de portal and covers the same month returned by get_last_available_month.
Use this tool when the user explicitly wants the PDF saved to a local directory on disk. To read or forward the PDF content directly, use the resource md24de://latest-report/pdf instead.
Args: directory: Directory where the PDF will be saved. Defaults to ~/Downloads. The filename is set automatically to e.g. "verbrauch-2025-04.pdf".
Returns: saved_to: Full path of the saved file. filename: The filename used, e.g. "verbrauch-2025-04.pdf". year, month: The period the document covers. size_bytes: Size of the saved PDF in bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | ~/Downloads |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool downloads and saves a file, with automatic filename generation. It does not cover potential side effects like overwriting existing files, required permissions, or network dependencies, 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 well-structured with a summary, context, usage guidance, parameter docs, and returns. It is front-loaded with the key action. While slightly verbose with legal details, every sentence adds value.
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's simplicity (one optional parameter, no annotations), the description covers legal context, relation to sibling tool, and alternative resource. It includes return fields. It does not mention error conditions or file overwrite behavior, but is fairly complete for its purpose.
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 description adds minimal meaning beyond the schema for the only parameter (directory). It repeats the default and adds that the filename is set automatically, but does not elaborate on constraints like valid directories or error handling. Since schema coverage is 0%, more detail would improve usability.
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 specific action: downloading and saving a PDF of the monthly consumption report. It identifies the document as the legally mandated UVI under German law, ties it to get_last_available_month, and distinguishes it from the resource alternative for reading/forwarding. This leaves 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?
Explicitly states when to use this tool ('when the user explicitly wants the PDF saved to a local directory') and when not to ('use the resource ... instead'). Provides a clear alternative, making it easy for the agent to decide.
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.
3 tool updates
v0.1.0- First observed
get_consumption_report - First observed
get_last_available_month - First observed
save_pdf
TDQS
Each tool has a clearly distinct purpose: get_consumption_report returns full structured data, get_last_available_month returns only the month metadata, and save_pdf downloads the PDF. No overlap in functionality.
All tool names follow a verb_noun pattern using snake_case (get_consumption_report, get_last_available_month, save_pdf). Naming is predictable and clear.
With 3 tools, the server covers the essential operations for accessing consumption report data: fetching structured data, checking the latest month, and saving the PDF. The count is appropriate for the narrow domain.
The tool set covers all necessary operations for the server's purpose: retrieving consumption data (full report), obtaining metadata (latest month), and persisting the PDF. No obvious gaps given the domain scope.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for Withings health data — sleep, activity, heart, and body metrics.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server providing attendance data queries via the CloudTime API.
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server for managing Yazio user & nutrition data (unofficial)1531359MIT
- AlicenseAqualityDmaintenanceMCP server for the German energy market master data register (MaStR), enabling querying of energy units, actors, grid connections, and more via 21 SOAP and public tools.76MIT
- AlicenseNot gradedqualityCmaintenanceRead-only MCP server for Tanita Health Planet measurements, providing tools for profile, health reporting, and measurement reads.MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for the air-Q Cloud API, enabling remote retrieval of air quality sensor data and historical analysis through read-only tools like listing devices, fetching readings, and exporting charts or data.Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/volsch/md24de-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server