mcp-einvoicing-be

Server Quality Checklist

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

Latest release: v0.9.0
Disambiguation5/5
Each tool addresses a distinct operation—validation, generation, transformation, parsing, VAT lookup, code list checks, participant discovery, DNS resolution, endpoint retrieval, and sending—with clear boundaries. Even similar tools like generate_invoice_be and transform_to_ubl are differentiated by validation behavior and intended use.
Naming Consistency4/5
Tool names consistently use snake_case with descriptive verb_noun patterns. There is some variation in how the 'Peppol' component appears (peppol_ prefix, suffix in check_*_in_codelist, or in resolve_peppol_dns), but the style remains predictable and readable.
Tool Count4/5
18 tools is slightly above the typical 'well-scoped' range (3–15), but each tool serves a legitimate purpose in the e-invoicing domain. The count feels justified given the need to cover document handling, community lookups, and network operations.
Completeness5/5
The server covers the full invoice lifecycle: generation, validation, transformation, parsing, and sending. It also provides essential supporting operations like VAT lookup, Peppol participant discovery, endpoint resolution, and code list management. No obvious gaps for the stated purpose.
Average 4/5 across 18 of 18 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs a check (presumably read-only) and mentions an environment variable requirement, which is useful context. However, it doesn't disclose what happens if the environment variable is not set, whether the tool raises errors or returns a boolean, or any side effects. It adds enough context to understand the operation, but lacks depth.
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 extremely concise, two sentences, with no filler words. It front-loads the core purpose and adds the prerequisite as a separate sentence. Every word earns its place, making it easily scannable.
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 has 2 parameters, no output schema, and no annotations, the description provides the essential purpose and a key prerequisite. However, for a tool performing a validation check, it lacks detail on parameter semantics, return values, and error conditions. It's adequate but leaves gaps, especially given the sibling tools that check other codelists—it could benefit from clarification on distinctions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'a (scheme, value) pair is a recognized Peppol process identifier.' It doesn't explain what 'scheme' and 'value' mean as parameters, their expected formats, or examples. The schema just lists them as strings with no additional detail, so the description does not compensate for the lack of schema documentation.
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 the tool's purpose: 'Check whether a (scheme, value) pair is a recognized Peppol process identifier.' This uses a specific verb ('check') and resource ('Peppol process identifier'), which distinguishes it from sibling tools like 'check_participant_id_scheme_in_codelist' and 'check_document_type_id_in_codelist' by referencing process identifiers. However, it doesn't explicitly differentiate from these siblings by naming them.
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 indicates a prerequisite: 'Requires EINVOICING_PEPPOL_CODELIST_DIR (see `list_participant_id_schemes`).' This provides clear context for usage and points to a related tool for setup. It doesn't state when NOT to use this tool relative to other codelist-checking siblings (like 'check_participant_id_scheme_in_codelist'), but the prerequisite and the likely tool family imply when it's applicable.
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 that the tool reports the locally configured version, implying it is a read-only operation, but does not specify whether it queries an external system, requires network access, or what the exact return structure is beyond the output schema existence. The description is clear but lacks deeper behavioral details like whether it reads from a local cache or performs a live check.
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 a single sentence that directly states the tool's purpose without excessive detail. It is concise and front-loaded with the main action. It does not include any fluff or redundant information, though it could be slightly more specific about the output format, but the output schema likely covers that.
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?
The tool is relatively simple with no parameters and has an output schema (though its contents are unknown). The description is adequate for a tool that simply reports a version. However, it lacks context such as whether this version is used for validation or how it might affect other operations, and it does not mention possible differences between multiple code lists or versions. Given the complexity is low, a score of 3 is appropriate as the description is sufficiently complete but could add a bit more context.
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 tool has zero parameters, and the schema coverage is 100% since the schema shows no properties. Therefore, the description does not need to explain parameter semantics. The baseline for zero parameters is 4, and the description accurately covers the tool's input requirements by stating it reports the current configured version without any parameters.
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 the purpose: reporting the OpenPeppol eDEC code list release version(s) currently configured locally. It specifies the resource (OpenPeppol eDEC code list) and the action (report version), which is distinct from sibling tools that focus on validation, generation, parsing, and other Peppol 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 the tool is used to check the locally configured version of the code list, but does not explicitly state when to use it versus alternatives. Sibling tools like 'check_participant_id_scheme_in_codelist' suggest this tool is for version reporting, not for validating codes, which is a subtle distinction but not explicitly articulated.
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 provided, the description carries the full burden. It mentions that the tool requires an environment variable (EINVOICING_PEPPOL_CODELIST_DIR), which is useful behavioral context. However, it does not disclose what happens if the directory is missing, whether it performs network calls, or any side effects, so transparency is moderate.
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 concise, consisting of two sentences, and is front-loaded with the primary action. The second sentence adds a necessary prerequisite. There is no wasted wording, though it could be slightly more explicit about output format.
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, good schema coverage, and an output schema present, the description is adequate. It provides the necessary context about the data source and prerequisite. It is not overly complex, so no additional detail is strictly required, making it complete for this context.
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?
The schema description covers 100% of parameters, describing 'active_only' as a boolean to omit deprecated entries. The description does not add further semantics beyond the schema, so the baseline of 3 is appropriate; it fully relies on the schema for parameter meaning.
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 lists Peppol SPIS use case identifiers from the OpenPeppol eDEC code list, which is a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'list_participant_id_schemes' or 'list_document_type_ids', though the resource is distinct.
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 implicitly indicates this is for listing SPIS identifiers, and the requirement for EINVOICING_PEPPOL_CODELIST_DIR is mentioned, which provides some context. However, it does not explicitly state when to use this tool over alternatives or any exclusions, so guidance is limited.
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 fails to mention that the tool is read-only, does not describe what happens when the code is not found (return value or error), and does not specify side effects. The requirement of an environment variable is useful but leaves significant behavioral aspects undisclosed.
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 extremely concise, consisting of two sentences that convey the core purpose and a critical prerequisite. There is no wasted wording, and the format is effective for an agent to quickly understand the tool's function.
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 simplicity (single parameter, output schema exists), the description covers the essential purpose and a key prerequisite. However, it lacks information about expected output structure or behavior in edge cases, but the output schema may partially compensate. It is adequate but not exhaustive.
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?
The schema has 0% description coverage for the single parameter 'icd', but the description explicitly defines it as a 4-digit ISO 6523 ICD code with an example, which compensates for the schema gap. It adds meaning beyond the raw 'string' type, so a baseline of 3 is appropriate.
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 whether a 4-digit ISO 6523 ICD code is a recognized Peppol scheme, using a specific example. It distinguishes itself from sibling tools like check_document_type_id_in_codelist by focusing on participant ID schemes and referencing list_participant_id_schemes for context.
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 implies usage by requiring the ICD code and mentions the prerequisite environment variable EINVOICING_PEPPOL_CODELIST_DIR, linking to list_participant_id_schemes for setup. It does not explicitly state when not to use it or contrast with siblings, but the reference to list_participant_id_schemes provides clear context.
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 the output structure and the fact that it applies customizationID and profileID, but does not mention authentication needs, side effects, or prerequisites.
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 two concise paragraphs with no filler. The first sentence states the purpose, followed by profile handling, then return values. Every sentence adds value.
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 explains what it does, the output format, and the profile application. It could mention error handling or validation of invoice_data, but given the existence of an output schema, it is fairly complete.
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%, so the description adds no additional meaning beyond what the schema already provides. The description does not elaborate on the parameters (e.g., invoice_data structure).
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 generates a UBL 2.1 Belgian e-invoice XML from structured data, specifying the output is ready for Peppol or Mercurius. It distinguishes well from siblings (parsing, validation, checking) by focusing on generation.
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 does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied by the clear purpose, but no explicit guidance is 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 provided, the description carries full weight for behavioral disclosure. It adds a genuinely useful piece of context beyond the schema: the tool requires the EINVOICING_PEPPOL_CODELIST_DIR environment variable, which is a concrete external dependency. However, it doesn't discuss what happens if that variable is unset, or mention the return format characteristics (beyond the output schema existing). The disclosed prerequisite is valuable, but for a straightforward list operation the behavioral surface is small. Compared to the scoring guide's emphasis on adding context, this description does add something meaningful, so above baseline, but doesn't go as far as discussing auth, error handling, or response behavior. Weights: 1=misleading/missing (no, since the env var note is there), 2=no guidance (no, env var note exists), 3=adequate, 4-5=rich contextual detail.
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 short, front-loaded sentences with zero waste. The first sentence states the purpose, and the second conveys an essential prerequisite while efficiently redirecting to a sibling tool for related context. Every word earns its place.
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 low-complexity, list-style tool with one optional boolean parameter, this description is largely complete. It explains the source (OpenPeppol eDEC code list), the resource (process identifiers), and the single critical dependency (env var). The tool has an output schema but the description need not cover return values per the rubric. A minor gap is not mentioning how to check a single process ID's existence (the sibling check_process_id_in_codelist), which could help an agent decide between listing and checking, but this is a nice-to-have given the tool's simplicity.
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% — the single optional 'active_only' parameter is fully described inline ('When True (default), omit deprecated/removed entries.'). The long description adds no parameter-specific detail, but it doesn't need to since the schema already fully explains the one parameter. Per the rubric, high schema coverage sets a baseline of 3, and there's no gap for the description to fill.
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 gives a specific verb+resource+source: 'List Peppol process identifiers from the OpenPeppol eDEC code list.' This clearly identifies what the tool does and, given the sibling context (list_participant_id_schemes, list_document_type_ids), distinguishes it as the one for process IDs. Naming the code list authority (OpenPeppol eDEC) adds precision.
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 provides an implicit usage hint by referencing the shared prerequisite and pointing to list_participant_id_schemes for env var details. However, it never explicitly explains when to use this tool versus alternatives. Interestingly, a related check function (check_process_id_in_codelist) exists as a sibling, but the description doesn't clarify when to use a list vs. a check. The cross-reference provides some context, but no explicit when/when-not guidance. Weights: 1=misleading, 2=no guidance, 3=implied usage, 4=clear context, 5=explicit 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?
No annotations are present, so the description carries the full burden. It discloses the environment variable requirement and the read-only nature of listing. It does not mention potential side effects, but as a listing operation, this is acceptable. The reference to another tool adds context.
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 extremely concise, containing two short sentences. It front-loads the action and avoids unnecessary words. The structure is clear and scannable, with the requirement and cross-reference placed appropriately.
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 core functionality and the required environment variable, and it references another tool for additional details. Given that an output schema exists, return values need not be explained. It is sufficiently complete for the tool's simplicity, though it relies on a cross-reference for full setup details.
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?
The only parameter, active_only, is already described in the schema with a clear explanation. The tool description does not add additional meaning or context beyond repeating that filtering occurs. Schema coverage is 100%, so it meets the baseline for parameter semantics.
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 lists Peppol document type identifiers from the OpenPeppol eDEC code list, specifying the resource and source. The verb 'List' and the object are unambiguous, distinguishing it from other list tools.
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 notes a prerequisite (EINVOICING_PEPPOL_CODELIST_DIR) and points to list_participant_id_schemes for more details, but does not explicitly contrast with alternative tools or state when to prefer this tool over others. Usage guidance is implicit rather than direct.
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 mentions the dependency on an environment variable and notes redistribution rights, pointing to module docs for more details. It does not state potential errors if the variable is missing or whether data is cached, but as a read-only listing operation, these omissions are acceptable.
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: two sentences clearly present the primary function and a required environmental prerequisite. No superfluous information is included, making it easy to parse.
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 provides essential context about the data source and its licensing, and notes where to find further documentation. Since an output schema exists (though not shown here), not detailing the return structure is acceptable. The tool's simplicity and the given details make it sufficiently complete.
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?
The input schema includes one optional parameter 'active_only' with a clear description, and the schema coverage is 100% (the only parameter is documented). The tool description itself does not add further parameter explanations, so the parameter semantics rely entirely on the schema, which is adequate.
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 explicitly states the tool's function: listing Peppol participant identifier (ICD) schemes from a specific code list. It also distinguishes itself from sibling tools like 'check_participant_id_scheme_in_codelist' by using the verb 'list' and referencing the full collection.
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 a clear prerequisite (the EINVOICING_PEPPOL_CODELIST_DIR environment variable must point to a local copy), which guides when the tool can be used. However, it does not explicitly contrast with alternatives (e.g., 'use this to list all schemes, use check_* for specific verification'), though the sibling names imply this.
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 full burden. It discloses the output fields (legal name, address, etc.) and the optional auth. But it does not mention error handling, rate limits, or what happens if the number is not found. Basic transparency is present but could be more 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?
Four sentences, each serving a distinct purpose: purpose, input flexibility, output description, optional authentication. No wordiness, well structured, and front-loaded with the core 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?
For a simple lookup tool with one parameter and an existing output schema, the description covers key aspects. It could mention error cases or prerequisites, but given the simplicity and the presence of an output schema, it is sufficiently complete.
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 already describes the parameter, and the description adds valuable formatting details (prefix, dots/spaces) beyond the schema. Schema coverage is 100%, so baseline is 3; the extra formatting guidance raises it to 4.
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 'Look up a Belgian enterprise number' against a specific database (BCE/KBO). It uses a specific verb and resource, and distinguishes well from sibling tools like generate_invoice_be or validate_invoice_be which have different purposes.
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 provides input formatting guidance (with/without prefix, dots/spaces) and mentions optional environment variable for authenticated access. However, it does not compare to sibling tools or specify when to use this vs. check_peppol_participant_be. No explicit when-not or alternative instructions.
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 must carry the full behavioral burden. It discloses the key steps: SMP lookup, envelope construction, and transmission using signing credentials, which is useful. However, it does not mention error handling, failure modes, idempotency, or the irreversibility of sending. It also does not clarify if the operation has any side effects beyond transmission. This partial transparency is adequate but not 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 two sentences, instantly front-loading the main purpose. It contains zero filler and every phrase contributes to understanding the tool's operation. This is exemplary conciseness.
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 complexity (8 params, 5 required) and existing output schema, the description is largely complete. It explains the end-to-end process and references the signing credentials. It omits details about environment |(test/prod) and response format, but those are covered in the schema. It could mention prerequisites like network access or timeout behavior, but overall it is sufficient for an agent to understand the tool's scope and usage.
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?
The input schema provides 100% description coverage for all 8 parameters, so the baseline is 3. The description does not add extra meaning to parameters beyond what the schema already states; it only references 'supplied signing credentials' which map to certificate_path and private_key_path but adds no new semantic detail. It does not clarify relationships between parameters or provide usage tips 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 clearly states the tool's function: sending a UBL/CII invoice to a Peppol participant via AS4. It names the verb (Send), the resource (invoice), the target (Peppol participant), and the protocol (AS4), distinguishing it from sibling lookup and validation tools like peppol_get_service_endpoint and check_participant_id_scheme_in_codelist.
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 clearly implies the tool is for sending invoices, contrasting with lookup/validation siblings. It mentions that it performs the SMP lookup internally, suggesting when not to use separate lookup tools, but it does not explicitly state 'use this when you need to actually transmit an invoice' or list exclusions. The context is clear enough for selection, though explicit 'when not to use' guidance is absent.
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?
With no annotations provided, the description carries the transparency burden. It discloses a meaningful behavioral nuance: searches all entries regardless of state, so deprecated or removed document types are still reported as found. It also flags an environment dependency, which is useful for an agent deciding whether the tool is callable.
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 very concise: two compact sentences plus a prerequisite line. It front-loads the main purpose, then adds essential behavioral context without redundancy. Every sentence contributes useful information.
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?
For a simple boolean-style check tool with an output schema, the description covers the core purpose, the required environment setup, and an important edge-case behavior. The presence of an output schema means return-value details are not the description's job, so the information provided is sufficient for invoking the tool correctly.
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?
The schema has no property descriptions, so the tool description must compensate. It clarifies that scheme and value together form a pair representing a document type identifier, but it does not explain accepted scheme formats or value examples. This is adequate but leaves the agent to infer exact parameter values.
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 begins with a specific action verb ('Check whether') and identifies the exact resource being tested: a Peppol document type identifier as a (scheme, value) pair. This clearly distinguishes it from sibling tools like check_participant_id_scheme_in_codelist and check_process_id_in_codelist.
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 provides a practical prerequisite ('Requires EINVOICING_PEPPOL_CODELIST_DIR') and references a sibling tool for setup context. However, it does not explicitly state when to prefer this over alternatives such as list_document_type_ids, nor does it give when-not-to-use guidance.
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?
With no annotations, the description carries the full disclosure burden. It details the accepted formats, extracted fields, and exact success/error return shapes. It omits side-effect information, but parsing is inherently read-only, and the behavioral disclosure is sufficient for an agent to understand the tool's operation and error handling.
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 relatively concise, front-loading the core purpose in the first sentence. It avoids fluff but could be slightly tightened (e.g., the accepted formats are mentioned twice). Overall, it efficiently conveys the necessary information without extra 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?
Given a single parameter with full schema coverage and an output schema (assumed from context), the description covers the tool's function, input constraints, and return structure on both success and failure. It does not mention dependencies or prerequisites, but for a parse tool with no nested objects or complex parameters, this is 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?
The input schema provides 100% coverage with a description for 'xml_content' as 'Raw UBL 2.1 XML invoice content (Peppol BIS 3.0)'. The description adds value by specifying that EU PINT v1.0.1 is also accepted, clarifying the parameter's scope beyond the schema. This extra context merits a score above the baseline 3.
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 parses UBL 2.1 XML invoices into a structured dict, specific to Peppol BIS 3.0 or EU PINT v1.0.1 documents, and extracts EN 16931 fields plus Belgian extensions. This is a distinct task from siblings like validate_invoice_be (validation) or transform_to_ubl (transformation).
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 specifies the input document types (Peppol BIS 3.0, EU PINT v1.0.1) and explains the return format, helping an agent decide when to invoke the tool. However, it does not explicitly contrast with siblings or state when not to use it, leaving some ambiguity about alternatives like validation or transformation.
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?
No annotations provided, so description must convey behavior. It clearly states it returns data (read-only) with no side effects. While it could explicitly state it's idempotent and safe, the description is sufficiently transparent for a simple query.
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, front-loaded with the main purpose. Every word is informative. No redundancy or fluff.
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 no paramaters and an output schema (assumed present), the description covers the key return information. It could hint at static nature or usage pattern, but it's largely complete for a reference data 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?
No parameters (baseline 4). The description explains what the return data contains (invoice types and UBL values), adding meaning beyond the empty schema. No param documentation needed.
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 it returns supported Belgian e-invoice document types, lists the specific types with codes (380, 381, 383), and mentions UBL identifiers. This distinguishes it from sibling tools like generate_invoice_be or validate_invoice_be, which have different purposes.
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?
No explicit guidance on when to use or when not, but the purpose is simple and self-evident. With siblings covering generation, validation, and transformation, the agent can infer this is for reference. However, explicit context would improve the score.
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?
With no annotations provided, the description carries the behavioral burden and adds valuable specifics: it states that redirects result in redirect_url being set and endpoint_url being None, and that callers must not follow more than one redirect per SMP 1.4.0 §3.2. This is more than a generic fetch description, though it omits other possible behaviors like error cases.
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 two tight sentences, with the purpose front-loaded and a specific edge case supported by a spec reference. There is no filler or redundant repetition of schema fields.
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 small, well-schematized tool with an output schema, the description covers the core workflow, an important redirect edge case, and a caller constraint. It could mention error/response details, but the output schema reduces that need.
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?
The input schema has 100% description coverage, including defaults and formats for environment and document_type_id, so the schema already provides the baseline. The description only adds minimal semantic reinforcement by mentioning that service metadata is fetched for *document_type_id*.
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 is led by a specific action and object: 'Fetch the AS4 endpoint for a Peppol participant's document type.' It clearly identifies the resource (AS4 endpoint) and scope (participant + document type), and this distinguishes it from siblings like resolve_peppol_dns or peppol_send.
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 conveys clear usage context by outlining the DNS-to-service-metadata resolution flow, so an agent knows this is the endpoint lookup step. It does not explicitly name alternatives or exclusions, stopping short of the 5-level guidance.
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?
With no annotations, the description carries the transparency burden. It discloses the internal process (DNS-over-HTTPS U-NAPTR lookup then SMP service-group request), which adds useful context beyond the schema. It implies a read-only operation but does not explicitly state side-effect freedom, rate limits, or error conditions.
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 concise sentences, front-loaded with the primary purpose and a brief technical overview. No redundant info or fluff.
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 output schema is present, so return values are covered. The description includes the process steps and the result content, which is sufficient for a moderate-complexity tool. It could mention environment nuances or that the operation is read-only, but these are inferable from context.
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 description coverage is 100%, and both parameters are fully described in the schema. The description adds no extra parameter detail, but the schema already explains the 'identifier' format and 'environment' default, so a baseline of 3 is appropriate.
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 registration status on the Peppol network and lists supported document type identifiers. It distinguishes from siblings like resolve_peppol_dns by focusing on registration rather than DNS resolution or endpoint retrieval.
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 clearly indicates when to use it (to verify registration status) but does not explicitly contrast with sibling tools or mention when not to use it. The functional purpose is unambiguous, so an agent can infer usage context, though explicit alternatives would improve guidance.
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?
No annotations are provided, so the description carries the full burden. It discloses that it performs a raw U-NAPTR (SML) lookup without fetching the SMP service group, which is a key behavioral trait. It also implies a read-only operation via DNS. Additional details like error handling are not mentioned, but the essential behavior is transparent.
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 two sentences, front-loaded with the purpose. The first sentence states the action, and the second adds purpose and behavior. No fluff or redundancy; every word earns its place.
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 an output schema present, the description need not explain return values. It sufficiently covers the purpose and key behavioral constraint (DNS only, no SMP fetch) for a diagnostic tool. It lacks mention of potential failure modes, but for a simple DNS lookup, this is acceptable and not a significant gap.
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?
The schema fully describes both parameters (identifier and environment) with 100% coverage, so the description does not need to add param details. It adds no extra semantic information beyond the schema, which is acceptable given the high schema 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 it resolves the SMP hostname for a Peppol participant via DNS only. It specifies a precise action (resolve hostname) and distinguishes itself from sibling tools like peppol_lookup_participant and peppol_get_service_endpoint by focusing solely on DNS resolution without fetching the SMP service group.
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 explains it is useful for diagnosing whether a participant is registered in the SML independently of SMP reachability, which gives clear context for when to use this tool over alternatives. It does not explicitly exclude other scenarios or name alternatives, but the diagnostic purpose is well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency responsibility and does so excellently. It discloses exactly what is checked (~50 BR-* rules), what is NOT checked (Peppol overlay, profile ID, EndpointID, narrowed code lists), the resulting metadata.scope, the warning behavior, and the risk of Peppol Access Point rejection. It also explains that mercurius only applies overlay rules, not full compliance.
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 long, but the length is justified by the complex tool behavior and the need to disclose significant limitations. The opening sentence provides a clear summary, and subsequent paragraphs are structured by profile. Slightly verbose, but every section contributes critical information.
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?
Given the tool's moderate complexity, two parameters, an output schema, and no annotations, the description is comprehensive. It explains the validation scope, per-profile behavior, return structure, and references a design decision document. It covers both what the tool does and what it intentionally omits, making it complete for an agent.
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%, so the schema already describes both parameters. The description adds meaningful value by explaining what each profile actually does in behavioral terms: peppol-bis-3/pint-eu run EN16931 base rules, while mercurius runs only overlay rules. This goes beyond the enum labels and default value in 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 uses a specific verb ('Validate') and resource ('UBL 2.1 XML invoice against Belgian business rules'), then immediately clarifies what is covered per profile. It clearly distinguishes itself from sibling tools like generate_invoice_be, parse_ubl_invoice_be, and transform_to_ubl, and explicitly states the scope limitations.
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 gives clear context for when the tool is appropriate: it covers EN16931 base rules for peppol-bis-3/pint-eu and Mercurius overlay rules for mercurius. It also states when it is NOT sufficient (not a full Peppol BIS3 conformance check). It does not explicitly name alternative tools to use for full conformance, but the profile-level guidance is strong.
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?
Discloses that no validation is performed, output format (xml, warnings), and non-fatal issues. With no annotations, but sufficient for a conversion tool.
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?
Three sentences plus a bullet list. Front-loaded with core purpose, no wasted words.
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?
For a single-parameter tool with output schema, description covers purpose, usage, behavior, return values, and references to sibling 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?
Schema covers 100% of parameter (data), description adds context about it being a structured JSON invoice and mentions output. Adds value beyond 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?
Clearly states it converts a structured JSON invoice to UBL 2.1 XML, with specific verb and resource. Distinguishes from sibling generate_invoice_be.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (caller will validate separately) and contrasts with generate_invoice_be which does validation.
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:

[![mcp-einvoicing-be MCP server](https://glama.ai/mcp/servers/cmendezs/mcp-einvoicing-be/badges/card.svg)](https://glama.ai/mcp/servers/cmendezs/mcp-einvoicing-be)

Score Badge

Copy to your README.md:

[![mcp-einvoicing-be MCP server](https://glama.ai/mcp/servers/cmendezs/mcp-einvoicing-be/badges/score.svg)](https://glama.ai/mcp/servers/cmendezs/mcp-einvoicing-be)

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/cmendezs/mcp-einvoicing-be'

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