Generate invoice and receipt PDFs from JSON. Agent-callable document API with a free demo quota.
Scored across 7 tools
Each tool has a clearly distinct purpose: PDF invoice creation, PDF receipt creation, e-invoice XML creation, e-invoice parsing, schema retrieval, API key issuance, and usage lookup. The three document-generation tools are differentiated by output format and document type, so an agent can select correctly.
All tool names follow a consistent snake_case verb_noun pattern: create_*, get_*, and parse_*. The convention is predictable throughout the set.
Seven tools is well-scoped for a document generation and e-invoice parsing service. Each tool earns its place by covering a distinct generation, parsing, schema, or account operation.
The surface covers core document generation, e-invoice parsing, schema discovery, API key issuance, and usage tracking. Minor gaps exist around validation, document history/listing, or non-invoice document types such as credit notes, but core workflows are covered.
Generate an EN 16931 e-invoice as UN/CEFACT Cross-Industry Invoice (CII) XML — the format behind France's Factur-X and Germany's XRechnung mandates. Same JSON shape as create_invoice_pdf plus a few extra fields: from/to countryCode (required), from.vatId (required when taxRate > 0), optional paymentIban, paymentReference, buyerReference. Returns a 24-hour download URL for the XML plus computed totals. Validated against the official EN 16931 schematron in CI.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | Optional Slipstack API key (psk_...). With a key, usage bills against your plan quota. Without one, the shared demo quota applies (10 documents/day per IP). Get a key at https://slipstack.dev/pricing | |
| options | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the non-destructive, non-idempotent, closed-world mutation profile. The description adds real value beyond that: returns a 24-hour download URL plus computed totals, and is validated against the EN 16931 schematron in CI. It doesn't mention auth/quota beyond what the schema's api_key already covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with what it produces, followed by the delta vs the sibling and the return value. No filler; every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers output shape (download URL + totals), the profile enum context is handled in the schema, and key conditional requirements are stated. With nested objects and no output schema, a bit more on party/address requirements would make it fully complete, but it is sufficient to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description must compensate and does: it names the newly required fields (countryCode, vatId when taxRate > 0) and the optional e-invoice fields (paymentIban, paymentReference, buyerReference), which are the semantically tricky additions over create_invoice_pdf. Many nested item/party fields remain undocumented in the description, keeping it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (generate) and resource (EN 16931 e-invoice as CII XML), and distinguishes itself from sibling create_invoice_pdf by name. An agent can tell exactly which document format this produces versus the PDF sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Signals when to use it (France Factur-X / Germany XRechnung mandates) and anchors it to the sibling by saying it shares create_invoice_pdf's JSON shape with extra fields. Lacks an explicit 'use create_invoice_pdf when you don't need e-invoicing' exclusion, so not full marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a professional invoice PDF from structured JSON (parties, line items, tax, discount). Returns a download URL valid for 24 hours plus computed totals. No account needed for up to 10 documents/day; pass api_key or an Authorization header for plan quotas.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | Optional Slipstack API key (psk_...). With a key, usage bills against your plan quota. Without one, the shared demo quota applies (10 documents/day per IP). Get a key at https://slipstack.dev/pricing | |
| options | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only declare readOnly=false, destructive=false, idempotent=false), the description adds real operational context: the 24-hour download URL lifetime, computed totals in the response, and the anonymous rate limit with the api_key/Authorization escape hatch. It stops short of saying each call consumes quota or whether generated documents persist server-side.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and immediately followed by the return value and the auth/quota caveat. 'Professional' is mild filler, but nothing else is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description supplies the essential return contract (download URL, 24h validity, computed totals) plus auth and rate-limit behavior, which is what an agent needs before calling. Gaps remain around document persistence and the format option, but the core is covered for a nested-schema create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33%, so the description should carry more weight; it does summarize the data payload as parties/line items/tax/discount and explains the api_key quota behavior, but says nothing about the options.format parameter (A4 vs LETTER) or the nested optional party fields. Useful orientation, incomplete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb+resource: 'Generate a professional invoice PDF from structured JSON', with the input shape (parties, line items, tax, discount) sketched in. It implicitly separates itself from create_receipt_pdf and create_einvoice_xml by naming the invoice PDF output, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives quota/auth context (10 documents/day anonymous, api_key for plan quotas) but never says when to choose this over create_einvoice_xml or create_receipt_pdf, or what conditions favor one output format over another. Usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a payment receipt PDF from structured JSON. Same schema as invoices (use number for the receipt number). Returns a 24-hour download URL and computed totals.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| api_key | No | Optional Slipstack API key (psk_...). With a key, usage bills against your plan quota. Without one, the shared demo quota applies (10 documents/day per IP). Get a key at https://slipstack.dev/pricing | |
| options | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavioral context beyond the annotations: the call returns a 24-hour download URL plus computed totals, which tells the agent the output is ephemeral and that it does not need to calculate tax/discount itself. Annotations already cover the safety profile (not read-only, not destructive, non-idempotent), so the remaining gaps (validation failure behavior, whether repeated calls produce distinct URLs) are minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, then the schema-compatibility note, then the return contract. No filler and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description adequately covers the return value (download URL with expiry, computed totals). For a nested, non-idempotent generation tool it could say more about what 'computed totals' includes and how receipt content differs from an invoice, but an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage and a deeply nested payload, the description must compensate; it does so partially by stating 'same schema as invoices (use `number` for the receipt number)', which resolves the misleading 'INV-2026-001' example on the number field. However, it adds no guidance on the many e-invoice fields (paymentIban, buyerReference, paymentReference), the options.format parameter, or which nested fields are ignored for receipts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Generate a payment receipt PDF from structured JSON') and notes it shares the invoice schema, which tells an agent this is the receipt-producing counterpart to create_invoice_pdf. It never explicitly contrasts itself with the invoice or e-invoice siblings, so the differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the input format (structured JSON, invoice-compatible schema) but gives no when-to-use or when-not guidance relative to create_invoice_pdf or create_einvoice_xml. An agent must infer that this tool is for receipts specifically and the others for invoices/e-invoices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current month's document usage, quota, and plan for a Slipstack API key. Requires api_key (or an Authorization: Bearer header).
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Slipstack API key (psk_...). Optional if sent as a Bearer header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond them by disclosing the temporal scope ('current month's') and the authentication path, though it says nothing about rate limits or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero padding; the capability statement is front-loaded and the authentication caveat follows immediately. Nothing is wasted or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with rich annotations, the description covers purpose, scope and auth, and names the three return concepts (usage, quota, plan) in lieu of an output schema. Only minor gaps remain: no note on units, reset timing, or response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented there, including the psk_ prefix and the Bearer-header alternative. The description merely restates that same auth requirement rather than adding new semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') and a well-defined resource ('current month's document usage, quota, and plan'), with the account scope made explicit. It is clearly distinguishable from the siblings, all of which create files or fetch schema/key data rather than report usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for invocation plus an explicit prerequisite: an api_key or an Authorization: Bearer header. It does not name exclusions or contrast with get_api_key, but for a single-purpose read tool the calling condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a free Slipstack API key (50 documents/month) for an email address, returned directly in the response — no signup flow, no email verification step. Idempotent: the same email always gets the same key back. Use the key as api_key on other tools or as an Authorization: Bearer header. Paid plans (from $19/mo for 1000 documents): https://buy.stripe.com/eVqeVcaEa9xFdnudDeew80n
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to associate with the key (used for account recovery and plan upgrades) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, readOnlyHint=false, and the description corroborates idempotency while adding genuinely new facts: the key is returned inline, the free quota is 50 documents/month, and no verification step exists. Since there is no output schema, the disclosure that the key comes back in the response itself is the most valuable sentence. The idempotency restatement is redundant with annotations, and failure modes (invalid email, key revocation) are unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and the return shape, then usage, then commercial details. The Stripe pricing sentence is a mild upsell that an agent invoking the tool does not need, though it does convey plan-tier context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by describing what comes back (the key, inline) and how to use it. Quota and idempotency are covered. Missing only edge behavior on invalid or malformed email addresses, which is minor for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains the email parameter's role in recovery and plan upgrades. The description's only addition is that the address is "for an email address" being keyed, which does not add meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Issue a free Slipstack API key") plus the input (email) and quota. No sibling tool deals with credentials, so an agent can tell instantly this is the bootstrap step before any document tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the acquisition context ("no signup flow, no email verification step") and tells the agent exactly how to consume the result (api_key param or Bearer header). It does not name a sibling or state explicit when-not conditions, but for a first-call bootstrap tool the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the JSON shape accepted by create_invoice_pdf / create_receipt_pdf / create_einvoice_xml, a complete example payload, and current plan limits. Call this first if you are unsure how to structure a document.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide the safety profile (readOnlyHint: true, destructiveHint: false), confirming it's a read operation. The description adds context about returning 'current plan limits' and 'a complete example payload,' which is useful operational detail beyond the standard JSON shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely efficient, using a single sentence to define the schema, the function of that schema, and the critical operational context (plan limits), achieving maximum information density without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no input parameters, the description is highly complete by detailing the comprehensive nature of the return object, specifically mentioning both the JSON shape and the 'current plan limits.' This is a complete definition for a discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 0 parameters, leading to the baseline score of 3. However, the description implies that the returned object will contain structural information and limits, providing high context even without parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's role as returning the JSON structure (schema) used by the suite of document creation tools (create_invoice_pdf, etc.). It explicitly distinguishes itself from siblings by mentioning it is the informational prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear condition for use: 'Call this first if you are unsure how to structure a document,' effectively placing it as the primary discovery tool before creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse EN 16931 e-invoice XML — UN/CEFACT CII (Factur-X, ZUGFeRD, XRechnung) or UBL Invoice/CreditNote (Peppol BIS) — into normalized invoice JSON: parties, line items, totals, VAT ids, payment details. Pass the XML document as a string.
| Name | Required | Description | Default |
|---|---|---|---|
| xml | Yes | The complete e-invoice XML document (CII or UBL) | |
| api_key | No | Optional Slipstack API key (psk_...). With a key, usage bills against your plan quota. Without one, the shared demo quota applies (10 documents/day per IP). Get a key at https://slipstack.dev/pricing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description's added value is in disclosing the transformation contract: which input standards are accepted and what the normalized output contains. It could say more about failure behavior on non-conforming or non-e-invoice XML, but the core conversion semantics are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and supported standards, then the output shape — good ordering. The trailing 'Pass the XML document as a string' sentence duplicates the schema's `xml` description and could be dropped without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly enumerates the returned JSON fields (parties, line items, totals, VAT ids, payment details), so an agent knows what it gets back. Input, supported standards, and auth/billing context are all covered between description and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, including a description for `xml` and a detailed note on `api_key` quota behavior, so the schema carries the load. The description's 'pass the XML document as a string' only restates the schema and adds no format or size nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (parse) and resource (EN 16931 e-invoice XML) and enumerates the concrete dialects it accepts (CII/Factur-X/ZUGFeRD/XRechnung, UBL/Peppol BIS). This clearly distinguishes it from all create_* siblings, which generate rather than parse documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the trigger condition clear — you have an e-invoice XML document and want normalized JSON. No explicit 'not for X' exclusion or named alternative is given, but no sibling competes for this job (get_document_schema only returns schemas).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_api_keycreate_einvoice_xmlcreate_invoice_pdf11 fields changedInput schema / properties / data / properties / buyerReferenceAdded value: +{
+ "description": "Buyer reference, e.g. a German Leitweg-ID (e-invoice BT-10; required by XRechnung)",
+ "type": "string"
+}Input schema / properties / data / properties / from / properties / cityAdded value: +{
+ "description": "City name (improves e-invoice address quality)",
+ "type": "string"
+}Input schema / properties / data / properties / from / properties / countryCodeAdded value: +{
+ "description": "ISO 3166-1 alpha-2 country code, e.g. FR (required for e-invoices)",
+ "maxLength": 2,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / data / properties / from / properties / postalCodeAdded value: +{
+ "description": "Postal code",
+ "type": "string"
+}Input schema / properties / data / properties / from / properties / vatIdAdded value: +{
+ "description": "VAT identifier, e.g. FR12345678901 (needed for e-invoices with VAT)",
+ "type": "string"
+}Input schema / properties / data / properties / paymentIbanAdded value: +{
+ "description": "Payment IBAN for SEPA credit transfer (e-invoices)",
+ "type": "string"
+}Input schema / properties / data / properties / paymentReferenceAdded value: +{
+ "description": "Remittance/payment reference (e-invoice BT-83)",
+ "type": "string"
+}Input schema / properties / data / properties / to / properties / cityAdded value: +{
+ "$ref": "#/properties/data/properties/from/properties/city"
+}Input schema / properties / data / properties / to / properties / countryCodeAdded value: +{
+ "$ref": "#/properties/data/properties/from/properties/countryCode"
+}Input schema / properties / data / properties / to / properties / postalCodeAdded value: +{
+ "$ref": "#/properties/data/properties/from/properties/postalCode"
+}Input schema / properties / data / properties / to / properties / vatIdAdded value: +{
+ "$ref": "#/properties/data/properties/from/properties/vatId"
+}create_receipt_pdf11 fields changedInput schema / properties / data / properties / buyerReferenceAdded value: +{
+ "description": "Buyer reference, e.g. a German Leitweg-ID (e-invoice BT-10; required by XRechnung)",
+ "type": "string"
+}Input schema / properties / data / properties / from / properties / cityAdded value: +{
+ "description": "City name (improves e-invoice address quality)",
+ "type": "string"
+}Input schema / properties / data / properties / from / properties / countryCodeAdded value: +{
+ "description": "ISO 3166-1 alpha-2 country code, e.g. FR (required for e-invoices)",
+ "maxLength": 2,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / data / properties / from / properties / postalCodeAdded value: +{
+ "description": "Postal code",
+ "type": "string"
+}Input schema / properties / data / properties / from / properties / vatIdAdded value: +{
+ "description": "VAT identifier, e.g. FR12345678901 (needed for e-invoices with VAT)",
+ "type": "string"
+}Input schema / properties / data / properties / paymentIbanAdded value: +{
+ "description": "Payment IBAN for SEPA credit transfer (e-invoices)",
+ "type": "string"
+}Input schema / properties / data / properties / paymentReferenceAdded value: +{
+ "description": "Remittance/payment reference (e-invoice BT-83)",
+ "type": "string"
+}Input schema / properties / data / properties / to / properties / cityAdded value: +{
+ "$ref": "#/properties/data/properties/from/properties/city"
+}Input schema / properties / data / properties / to / properties / countryCodeAdded value: +{
+ "$ref": "#/properties/data/properties/from/properties/countryCode"
+}Input schema / properties / data / properties / to / properties / postalCodeAdded value: +{
+ "$ref": "#/properties/data/properties/from/properties/postalCode"
+}Input schema / properties / data / properties / to / properties / vatIdAdded value: +{
+ "$ref": "#/properties/data/properties/from/properties/vatId"
+}parse_einvoicecreate_invoice_pdfcreate_receipt_pdfget_account_usageget_document_schemaTurn HTML or templates into branded invoice & document PDFs from your agent. One call, no install.
Render PDFs and images (invoices, receipts, OG images) from templates or HTML. 1 cent each.
Free invoice drafts, templates and direct PDF generation for AI agents. No account needed.
PDFs, images and e-invoices (XRechnung, ZUGFeRD) from templates and JSON, rendered in the EU.
Add one secure layer between your agents and this server.