Skip to main content
Glama

InkVoice — XRechnung & E-Invoicing

by net.inkvoice
OverviewDiscussionsAdmin

Server Details

XRechnung and ZUGFeRD e-invoicing (EN 16931): create, validate, check Leitweg-IDs, German VAT.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 42 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinct action and artifact: VAT arithmetic, Leitweg-ID validation, XRechnung creation, ZUGFeRD creation, and invoice validation. The two creation tools (create_xrechnung vs create_zugferd) could be confused at a glance, but the descriptions sharply delineate public-sector XML versus private B2B hybrid PDF, so misselection is unlikely.

Naming Consistency5/5

All five tools follow a clean verb_noun snake_case pattern: calculate_vat, check_leitweg_id, create_xrechnung, create_zugferd, validate_einvoice. The verb choice matches the action (calculate/check/create/validate) with no stylistic drift.

Tool Count5/5

Five tools is well-scoped for an e-invoicing helper: arithmetic, one identifier check, two output formats, and a validator. Every tool earns its place with no redundant surface.

Completeness4/5

The core lifecycle (compute, create, validate) is covered across both required formats. The main gap is a workflow dead end: validate_einvoice only reads XML, yet no tool extracts the embedded XML from a ZUGFeRD PDF, so a ZUGFeRD file cannot be validated end-to-end; multi-rate invoices are also explicitly unsupported.

Available Tools

5 tools
calculate_vatCalculate German VATA
Read-only
Inspect

Converts between net, tax and gross for a given VAT rate, in either direction.

Give an amount and say whether it is net or gross, and you get all three figures back rounded to the cent. Germany's rates are 19 % (standard) and 7 % (reduced), but any rate from 0 to 100 is accepted, so this also works for an Austrian or French invoice.

Rounding is half-away-from-zero, the convention invoices and tax authorities use, and the three returned figures always reconcile: net plus tax equals gross exactly, with no cent left over from rounding each separately.

What this does NOT do: it does not decide which rate applies to a supply, handle more than one rate at a time, or know anything about reverse charge, intra-community supply or the Kleinunternehmer rules. It is arithmetic, not tax advice.

ParametersJSON Schema
NameRequiredDescriptionDefault
rateYesVAT rate as a percentage, not a fraction: 19 means 19 %, not 1900 %.
basisYesWhether `amount` is the net figure (add tax to it) or the gross figure (take tax out of it).
amountYesThe amount to convert, in the invoice currency. Must not be negative.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark the tool read-only; the description adds meaningful behavioral detail beyond that: half-away-from-zero rounding, exact reconciliation of net + tax = gross, and acceptance of rates 0–100. It also honestly discloses that it is arithmetic, not tax advice.

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 purpose is front-loaded in the first sentence, followed by usage, behavioral guarantees, and limitations. The paragraphs are dense but every sentence contributes; there is no fluff or repetition of schema details.

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?

Even without an output schema, the description tells the agent that all three figures are returned, rounded to the cent, and reconcile. It also covers edge acceptance and exclusions, making it complete for a simple arithmetic conversion 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 coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining the valid rate range (0–100) and how `basis` controls whether tax is added or removed, going slightly beyond the schema 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?

Opens with a specific verb and resource: 'Converts between net, tax and gross... in either direction.' It clearly scopes the tool to arithmetic VAT conversion and distinguishes itself from siblings by stating what it does NOT do (rate selection, tax advice).

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?

Clear context is given for when to use the tool, and the 'What this does NOT do' section provides explicit exclusions such as reverse charge and rate determination. It stops short of naming sibling tools as recommended alternatives, so it misses the top score.

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

check_leitweg_idCheck a Leitweg-IDA
Read-only
Inspect

Checks a German Leitweg-ID — the routing identifier that goes in BT-10 of an XRechnung to a public authority. An invoice to a German public body with a wrong or missing Leitweg-ID is rejected, so this is worth checking before building a document.

It verifies the structure (Grobadressierung of 2 to 12 digits, an optional Feinadressierung of up to 30 alphanumerics, then two check digits) and recomputes the ISO/IEC 7064 MOD 97-10 check digit, the same procedure an IBAN uses. When the check digits are wrong it returns the ones the address parts actually imply, so the value can be corrected rather than merely rejected. It also names the Bundesland the leading two digits point at, or Bund for the federation.

One real limit: the check digit is computed over the address parts with the hyphens removed, which is what KoSIT specifies, so it CANNOT detect a hyphen in the wrong place. '04011000-1234512345-06' and '040110001-234512345-06' both pass. That is the specification's behaviour, not a defect here.

What this does NOT do: it does not confirm that the ID belongs to a real authority or that they are reachable. It checks the number, not the recipient — there is no directory lookup.

ParametersJSON Schema
NameRequiredDescriptionDefault
leitwegIdYesThe Leitweg-ID, e.g. '04011000-1234512345-06'. Surrounding whitespace is ignored.

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint annotation, explaining the exact verification algorithm, the ISO/IEC 7064 MOD 97-10 check-digit procedure, the hyphen-placement limitation with concrete examples, and the fact that it returns implied check digits for correction. It is exceptionally transparent about edge-case behavior.

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 longer than average, but every section earns its place: main purpose, verification behavior, a critical limitation with examples, and explicit non-goals. It is front-loaded with the essential purpose and remains highly readable despite the technical detail.

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?

Even without an output schema, the description states the key outputs: pass/fail on structure and check digits, the implied check digits when wrong, and the Bundesland derived from leading digits. For a single-parameter, deterministic check tool, this fully equips an agent to invoke it correctly and interpret results.

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 single parameter with an example and whitespace handling, giving a baseline of 3. The description adds genuine value by detailing the accepted structure, the check-digit computation, and the hyphen-sensitivity limitation, which helps the agent understand what values are valid and what the check actually covers.

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 and resource: it 'checks' a German Leitweg-ID, verifies its structure, and recomputes the check digit. It clearly distinguishes itself from broader invoice tools by stating exactly what it does not do, such as confirming the ID belongs to a real authority.

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 when-to-use context: check before building an XRechnung because a wrong or missing Leitweg-ID causes rejection. It also gives explicit when-not-to-use guidance by stating it does not validate the recipient or perform directory lookups, though it does not name a specific sibling tool as the alternative.

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

create_xrechnungCreate an XRechnungA
Read-only
Inspect

Builds a German XRechnung 3.x electronic invoice (EN 16931, CII syntax) from invoice details and returns the XML as text. This is the format German public-sector buyers are legally required to receive, and that many private B2B buyers now ask for.

The EN 16931 business rules are checked before anything is built, and a rejected call comes back naming the rules that failed and the business term (BT-xx) each concerns. The ones worth getting right up front: tax category S requires a rate above 0 %, categories Z, E and AE require exactly 0 %, E and AE additionally require a stated exemption reason (BT-120), both parties need an email address because XRechnung makes the electronic address (BT-34, BT-49) mandatory, and an IBAN (BT-84) is required, because XRechnung makes payment instructions (BG-16) mandatory (BR-DE-1). For a public-sector buyer, put their Leitweg-ID in buyerReference (BT-10) — check_leitweg_id will verify it first.

What this does NOT do:

  • It does not validate against the KoSIT Prüftool. It applies our reading of EN 16931, which is not the same thing as the Schematron suite a receiving portal runs. Use validate_einvoice for a second look, and the official validator before a deadline.

  • It does not produce ZUGFeRD or Factur-X. There is no PDF and no embedded XML — this is a bare XML file. Use create_zugferd for the hybrid a private-sector B2B buyer usually wants.

  • It handles ONE tax rate and one tax category for the whole invoice. A document mixing 19 % and 7 % lines is not expressible here.

  • It does not send the invoice anywhere, and there is no Peppol.

Nothing is stored: no account, no invoice record, no retained personal data.

ParametersJSON Schema
NameRequiredDescriptionDefault
invoiceYesThe invoice to turn into an XRechnung document.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true and openWorldHint=false; the description adds substantial context beyond that: EN 16931 business rules are checked before building, rejected calls name the failed rules and BT-xx terms, specific tax-category and exemption constraints are disclosed, and it explicitly states nothing is stored. This is consistent with readOnlyHint (builds and returns text, mutates no external state).

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?

Long, but front-loaded with the core purpose in the first sentence and then organized into a scannable 'What this does NOT do' list. Every sentence carries a constraint or routing instruction; it is appropriately sized for a tool with this much business-rule surface, though it is on the verbose side.

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 a nested 1-parameter object schema with no output schema, the description supplies the preconditions, the failure behavior, scope limits (single tax rate/category, no PDF, no Peppol, no sending), and the sibling alternatives needed to call it correctly and interpret the result.

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 baseline is 3, but the description adds genuine meaning not in the schema: seller/buyer email is mandatory (BT-34/BT-49), IBAN (BT-84) is required (BR-DE-1), buyerReference carries the Leitweg-ID (BT-10), and taxCategoryCode drives rate constraints. It does not cover every field (bic, bankName, notes, reference) but clearly elevates the critical ones.

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?

States a specific verb+resource ('Builds a German XRechnung 3.x electronic invoice'), names the standard (EN 16931, CII syntax), and states the return format (XML as text). It also implicitly distinguishes itself from create_zugferd by specifying a bare XML file, so an agent can tell it apart from siblings without opening schemas.

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 says when to use it (German public-sector buyers legally require it, many private B2B buyers ask for it) and when not to, naming the concrete alternatives: check_leitweg_id to verify the buyerReference first, validate_einvoice for a second look, create_zugferd for the hybrid format private B2B buyers want. Routing is unambiguous.

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

create_zugferdCreate a ZUGFeRD / Factur-X invoiceA
Read-only
Inspect

Builds a ZUGFeRD 2.x / Factur-X hybrid invoice from the same details create_xrechnung takes, and returns it as a PDF file.

A hybrid is one invoice stated twice in one file: a PDF/A-3 document a person reads, carrying the same invoice inside it as EN 16931 XML a machine books. This is the format private-sector German B2B buyers generally want, where XRechnung is what public bodies require. If the recipient is a public authority and gave you a Leitweg-ID, you want create_xrechnung instead.

The embedded XML declares plain EN 16931 — the profile ZUGFeRD calls COMFORT — not the XRechnung CIUS, because that CIUS is a statement about public-sector procurement.

Validation is identical to create_xrechnung, except that the IBAN is optional here (EN 16931 makes BG-16 optional): the same EN 16931 rules are applied before anything is built, and a rejected call names the rules and business terms that failed.

What this does NOT do:

  • The result is a binary PDF returned as an attachment. It is not text and there is nothing useful to read in it — do not try to quote or summarise its contents. Offer it to the user as a file.

  • It does not validate against veraPDF or the Mustangproject validator. The document is built to be valid PDF/A-3 with the required Factur-X metadata, but that is our reading rather than a validator's verdict.

  • It handles ONE tax rate and one tax category for the whole invoice, exactly as create_xrechnung does.

  • It does not send the invoice anywhere, and there is no Peppol.

  • There is no logo and no custom styling. The PDF uses the default invoice layout.

Nothing is stored: no account, no invoice record, no retained personal data.

ParametersJSON Schema
NameRequiredDescriptionDefault
invoiceYesThe invoice to turn into a ZUGFeRD / Factur-X document.

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: validation rules run before building, IBAN is optional because BG-16 is optional, rejections name the failing rules/business terms, one tax rate and category per invoice, no Peppol/sending, no logo or styling, and nothing is persisted. It also warns that the output is opaque binary and must be offered as a file rather than quoted. The 'nothing stored' statement is consistent with readOnlyHint=true despite the 'create_' name.

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?

Well front-loaded: purpose and format first, then the routing rule, then the explicit 'What this does NOT do' list. It is long, and the PDF/A-3-vs-EN-16931 explainer paragraph is more context than strictly necessary, but nearly every sentence carries actionable 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?

There is no output schema, so the description correctly carries the return-value burden, explaining that the result is a binary PDF attachment with nothing readable inside. Combined with validation behavior, restrictions, and the no-storage guarantee, an agent has everything needed to call and present this 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?

With a single wrapper parameter and high schema coverage, the baseline is 3, but the description adds real semantic deltas: the payload takes 'the same details create_xrechnung takes', the IBAN is optional here (unlike XRechnung), and the invoice is constrained to one tax rate/category. It does not explain taxCategoryCode or currency formats, which remains a minor gap.

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?

States a specific verb ('Builds') and a precise resource ('ZUGFeRD 2.x / Factur-X hybrid invoice') and adds the concrete output form ('returns it as a PDF file'). It also explicitly distinguishes itself from the sibling create_xrechnung, so an agent can route without opening either schema.

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?

Gives an explicit routing rule: private-sector German B2B buyers want this, while a public authority that supplied a Leitweg-ID means 'you want create_xrechnung instead'. Both the when and the when-not are stated, with the selecting condition named.

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

validate_einvoiceCheck an e-invoiceA
Read-only
Inspect

Reads an existing electronic invoice and reports what is wrong with it. Accepts XRechnung and ZUGFeRD XML in either EN 16931 syntax — CII (used by XRechnung and ZUGFeRD) and UBL — and reports the syntax and profile it found along with the invoice's key fields, so it also answers "what is this file?".

It checks the rules behind most real rejections: BT-10 buyer reference present, and its Leitweg-ID check digit when it looks like one; BT-34 and BT-49 electronic addresses present; tax category S not used at 0 %; BT-120 exemption reason present for categories E and AE; line amounts summing to BT-106; net plus tax equalling the BT-112 gross; BT-115 amount due matching gross less prepaid; and the due date not falling before the issue date.

What this does NOT do:

  • It is NOT the KoSIT Prüftool and is not a substitute for it. It covers the rules that account for most rejections, not the full EN 16931 Schematron suite. A file that passes here can still be rejected by a Rechnungseingangsportal.

  • It does not check the XSD schema, so a structurally invalid document may parse here.

  • It reads XML only. A ZUGFeRD PDF must have its embedded XML extracted first — pass the XML, not the PDF.

Nothing is stored: the document is parsed in memory and discarded.

ParametersJSON Schema
NameRequiredDescriptionDefault
xmlYesThe full XML text of the invoice. For ZUGFeRD, the XML extracted from the PDF, not the PDF itself.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark readOnlyHint=true, but the description adds meaningful behavioral detail: 'Nothing is stored: the document is parsed in memory and discarded.' It also discloses limitations (not XSD validation, not full EN 16931 Schematron suite) and an important nuance: a file that passes can still be rejected by a portal. This goes well beyond the annotation.

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 well-structured and front-loaded with the core purpose. It uses a clear 'What this does NOT do' section and bullet-like lists. Every sentence carries useful information, though the detailed enumeration of checked rules (BT-10, BT-34, etc.) could be considered verbose for an AI agent. Still, it is appropriately sized for a complex validation tool.

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 tool that validates complex e-invoices, the description is remarkably complete. It covers accepted input formats, the specific rules checked, limitations and exclusions, behavioral side effects (memory-only, no storage), and what the output will contain ('reports the syntax and profile it found along with the invoice's key fields'). No gaps remain that would prevent correct selection and invocation.

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 100% and the single 'xml' parameter is well described. The description adds substantial meaning: it accepts XRechnung and ZUGFeRD XML in EN 16931 syntax (CII and UBL), clarifies the input must be the extracted XML not the PDF, and explains what the tool does with that XML. This goes far beyond the schema's basic description.

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 a specific verb and resource: 'Reads an existing electronic invoice and reports what is wrong with it.' It also clarifies it identifies syntax/profile and key fields, answering 'what is this file?'. This clearly differentiates it from siblings like create_xrechnung and check_leitweg_id, and the 'What this does NOT do' section further distinguishes it from the official KoSIT Prüftool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-not: it is not the KoSIT Prüftool, does not check XSD schema, and reads XML only (not ZUGFeRD PDFs). It also states a passing file may still be rejected by a Rechnungseingangsportal. However, it does not explicitly mention sibling tools like check_leitweg_id when the task is only a Leitweg-ID check, so it lacks direct alternative routing.

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.

  1. 2 tool updates
    • Changedcreate_xrechnung1 field changed
      • addedInput schema / properties / invoice / properties / deliveryDate
        Added value: +{
+  "default": null,
+  "format": "date",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • Changedcreate_zugferd1 field changed
      • addedInput schema / properties / invoice / properties / deliveryDate
        Added value: +{
+  "default": null,
+  "format": "date",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. 1 tool update
    • Addedcreate_zugferd
  3. 4 tool updates
    • First observedcalculate_vat
    • First observedcheck_leitweg_id
    • First observedcreate_xrechnung
    • First observedvalidate_einvoice

Related MCP Connectors

Related MCP Servers

  • beliq-mcp by beliq-eu

    beliq-mcpofficial

    beliq-eu
    A
    license
    A
    quality
    C
    maintenance
    Validates electronic invoices (XRechnung, ZUGFeRD, Factur-X, Peppol BIS, etc.) against authority-pinned rules and explains failures.
    2
    165 npm
    MIT

  • einvoice-mcp

    makririch
    A
    license
    A
    quality
    D
    maintenance
    MCP server for DACH e-invoicing. Create XRechnung (UBL) and ZUGFeRD 2.3 (Factur-X CII) invoices, validate against EN 16931 rules, extract data from XML, and convert between UBL, CII and JSON formats.
    6
    49 npm
    2
    MIT

  • erechnung-mcp

    pexon-consulting
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI assistants to read, validate against the official KoSIT rules (no Java), create, and display XRechnung and ZUGFeRD e-invoices, and export incoming invoices as DATEV posting batches. Running it with a cloud language model sends invoice contents to that provider's service.
    MIT
  • rechnungsapi-mcp by Rechnungsapi

    rechnungsapi-mcpofficial

    Rechnungsapi
    A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants and agents to create, validate, read and convert German and EU e-invoices in ZUGFeRD, XRechnung and Factur-X formats, including extracting structured data from scanned or PDF invoices and embedding XML into PDF/A-3 files. It can run as a hosted remote server or locally, with each request authenticated by the caller's own API token.
    10
    28 npm
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources