einvoice-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: generating a ZUGFeRD PDF versus generating an XRechnung XML, validating each format, parsing both, and checking compliance. There is no overlap between generation, validation, parsing, or compliance checking.
Naming Consistency4/5
All tools use the einvoice_ prefix followed by a verb. The generate and validate tools follow a consistent verb_format pattern (e.g., einvoice_generate_zugferd), while einvoice_parse and einvoice_check_compliance use verb_noun. This is a minor deviation but overall predictable.
Tool Count5/5
Six tools is well-scoped for the e-invoicing domain, covering generation, validation, parsing, and compliance checking for both XRechnung and ZUGFeRD. Each tool earns its place without unnecessary redundancy.
Completeness5/5
The tool surface covers the full lifecycle of e-invoice handling: create both formats, validate both formats, parse either format, and perform compliance checks. No obvious gaps exist for the stated purpose of generating and verifying e-invoices.
Average 4.1/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds that the tool creates a hybrid PDF with embedded CII-XML, which is useful behavioral context. However, it does not disclose behaviors such as validation failures, file output handling, or side effects beyond the annotations. It avoids contradicting the annotations.
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 appropriately structured: a one-sentence purpose statement followed by an 'Args:' list. Every parameter earns a line because the schema lacks descriptions. It is long due to the tool's 96 parameters, but not verbose or redundant, making it efficient for the complexity involved.
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 96 parameters, an existing output schema, and annotations, the description covers the core purpose and all parameter semantics thoroughly. It does not explain when to use ZUGFeRD vs. XRechnung or describe profile options in depth, but the output schema covers return values and the parameter details are nearly exhaustive. Minor gaps remain in usage context and behavioral edge cases.
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?
Schema description coverage is 0%, so the description carries full responsibility for parameter understanding. It provides a comprehensive list of all 96 parameters with German explanations, BT-code mappings, and examples (e.g., type_code '380/381/384', vat_point_date_code values). This adds significant meaning beyond the schema's bare property titles and defaults.
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 first sentence states the exact purpose with a specific verb and resource: 'Erstellt eine ZUGFeRD-Hybrid-PDF (visuelle PDF + eingebettetes CII-XML).' This clearly distinguishes it from sibling tools like einvoice_generate_xrechnung and einvoice_validate_* by naming the output format (ZUGFeRD) and its hybrid nature.
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 its use case: generating a ZUGFeRD invoice. However, it does not explicitly state when to choose this tool over alternatives (e.g., einvoice_generate_xrechnung) or provide any exclusion criteria. No explicit when-to-use/when-not-to-use guidance is given, but the tool name and purpose make the primary scenario clear.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the KoSIT-validator scope and the return of errors/warnings/profile, but it does not disclose potential external dependencies, network usage, or rate limits. This is acceptable but not particularly rich.
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 with three focused sentences: purpose, return value, and parameter explanation. No fluff, well-structured, and front-loaded with the main action.
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's simplicity (one required parameter, output schema exists), the description covers purpose and parameter well. It lacks explicit usage guidance and does not mention potential external service behavior, but it is sufficient for an agent to select and invoke the tool correctly.
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 schema provides no description for xml_content (0% coverage), but the description compensates with an Args block: 'xml_content: Der vollständige XRechnung-XML-Inhalt als String.' This clarifies that the parameter expects the full XRechnung XML content as a string, adding meaningful semantics beyond the schema.
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 specific action: 'Validiert eine XRechnung (CII XML) gegen den KoSIT-Validator.' This clearly identifies the resource (XRechnung/CII XML) and the target (KoSIT validator), distinguishing it from siblings like einvoice_validate_zugferd or einvoice_generate_xrechnung.
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 when needing to validate XRechnung XML, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The sibling tool list offers context, but the description itself lacks direct guidance on choosing this validator.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the method of validation (extracting embedded XML) but does not disclose potential failure modes or side effects. It is consistent with the 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 one sentence plus an Args list, with no redundant text. It is front-loaded with the purpose and directly explains the parameter.
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 simple tool with one parameter, a read-only annotation, and an output schema, the description covers the core purpose and input. It does not include usage comparisons, but for a basic validation tool, the essential information is present.
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 schema has no description for pdf_base64, and the description's Args section provides the necessary meaning: the ZUGFeRD-PDF as a Base64-encoded string. This compensates for the 0% schema description coverage.
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 validates a ZUGFeRD-PDF by extracting and checking the embedded XML. This distinguishes it from sibling tools like einvoice_generate_zugferd and einvoice_validate_xrechnung, which deal with generation or a different validation format.
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 for validating ZUGFeRD PDFs but does not explicitly state when to prefer this over alternatives. No mention of exclusions or comparison with sibling tools like einvoice_validate_xrechnung or einvoice_check_compliance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context by listing specific rule sets checked (e.g., EN 16931, BR-DE rules, SEPA checks) and noting the output is in German. This goes beyond annotations without contradicting them.
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 well-structured: a clear purpose statement, followed by a rule list and parameter explanations. It is somewhat long due to the detailed rule enumeration, but every section serves a purpose and it is front-loaded with the key functionality.
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?
With annotations and a present output schema, the description covers the tool's purpose, key rules, parameters, and output language. It does not explicitly reference sibling tools or edge cases, but the information provided is sufficient for an agent to select and invoke the tool correctly in most scenarios.
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?
Schema coverage is 0%, so the description fully compensates. The 'Args' section explains xml_content as the CII-XML string and target_profile with its allowed values ('XRECHNUNG' or 'ZUGFERD'), providing semantics the schema lacks. This is critical for correct invocation.
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 purpose: checking e-invoice compliance against XRechnung or ZUGFeRD. It specifies the exact resource (E-Rechnung) and verb (Prüft die Konformität), and distinguishes itself from siblings by mentioning combined KoSIT validation, mandatory field checks, and German improvement suggestions.
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 context (compliance checking with rule lists and suggestions) but does not explicitly compare to sibling tools like einvoice_validate_xrechnung or state when to use this instead. It provides clear context but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: automatic validation against the KoSIT validator ('Die Rechnung wird automatisch gegen den KoSIT-Validator geprüft'). This goes beyond the annotations (idempotentHint=true, readOnlyHint=false) and provides useful context about expected validation behavior. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and validation notice, then provides an organized and comprehensive parameter list. While very long, each parameter entry is concise and necessary given the 96-parameter schema with zero schema-level descriptions. There is minimal fluff, though the sheer length is a burden.
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 high complexity (96 params) and the presence of an output schema, the description is largely complete. It covers all parameters with semantic details and discloses validation behavior. It does not explicitly address failure cases or output format, but the output schema covers return values, so this is sufficient.
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?
With schema description coverage at 0%, the description fully compensates by explaining every parameter with examples, formats, and BT codes. It clarifies that fields like 'items', 'allowances_charges', and 'supporting_documents' are JSON arrays, which the schema does not specify. This is rich semantic addition beyond the input schema.
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 'Erstellt eine XRechnung-konforme CII-XML-Rechnung' (Creates an XRechnung-compliant CII-XML invoice), which is a specific verb + resource. It clearly distinguishes from sibling tools like validation, parsing, and ZUGFeRD generation by specifying the XRechnung/CII format and the generation action.
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 for generating XRechnung invoices but does not explicitly state when to use this tool versus the ZUGFeRD variant or validation tools. No exclusions or alternatives are mentioned. The context is clear from the name and purpose, but guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds valuable context by specifying that PDF input must be base64-encoded, that both XML and PDF formats are accepted, and by detailing the JSON output structure. This goes beyond the annotations and helps the agent correctly prepare input.
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 with a front-loaded summary sentence, a detailed but organized bullet list of output fields, and a clear Args section. Every element provides useful information without filler, and the format makes the tool's capabilities easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input formats, parameter encoding, and the full structure of extracted data. Given the tool's complexity (multiple file types, many return fields), this is complete even though an output schema exists. It adds key details (like Base64 for PDFs) that the schema input lacks.
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 input schema has 0% description coverage, but the description's 'Args' section thoroughly explains both parameters: file_content accepts an XML string or base64-encoded PDF, and file_type is 'xml' or 'pdf'. This fully compensates for the schema's lack of parameter 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 opens with 'Parst eine E-Rechnung (XML oder PDF) und gibt strukturierte Daten zurück', clearly stating the tool parses e-invoices and returns structured data. It explicitly names supported formats (CII-XML, ZUGFeRD/Factur-X PDFs) and is distinct from the sibling generate/validate tools, which focus on different operations.
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 for extracting invoice data but does not explicitly state when to prefer this tool over the validation or generation siblings. It provides format scope (XML vs PDF) but lacks when-not-to-use guidance or alternative tool references, so the usage context is only implied.
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:

[![einvoice-mcp MCP server](https://glama.ai/mcp/servers/Mavengence/einvoice-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Mavengence/einvoice-mcp)

Score Badge

Copy to your README.md:

[![einvoice-mcp MCP server](https://glama.ai/mcp/servers/Mavengence/einvoice-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Mavengence/einvoice-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/Mavengence/einvoice-mcp'

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