What can you do with this server?

This server provides an MCP interface to the PixelLetter service, enabling physical letter and fax dispatch, account management, and electronic invoice signing. You can: * Send physical letters (send_letter): Submit PDF or other documents (or plain text) to be printed, folded, franked, and posted. Supports registered mail, return receipt, personal delivery, cash on delivery, colour printing, duplex control, GoGreen postage, and optional simultaneous fax dispatch. * Send faxes (send_fax): Transmit documents or plain text as a fax only, without posting a physical letter. * Check account info (get_account_info): Retrieve customer data and current credit balance. * Cancel orders (cancel_order): Cancel a submitted order by its PixelLetter order ID, before it has been printed. * Sign invoices electronically (sign_invoice): Send documents to PixelLetter's electronic invoice signing service (qualified or advanced), with optional e-mail notification to the recipient. * Look up interface reference (get_interface_reference): Offline lookup of API action values, dispatch centres, service codes, upload limits, and error codes — no API call required. Key notes: * Every sending action requires an explicit testMode flag (true = no real dispatch or charge, false = live order). * Credentials are provided via environment variables (PIXELLETTER_EMAIL, PIXELLETTER_PASSWORD). * Files can be supplied as absolute paths or base64-encoded inline data.

How do I use pixelletter-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pixelletter-mcp Send the PDF at /Users/me/letter.pdf to Germany as registered mail." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

pixelletter-mcp

by bitterdev

Overview Schema Related Servers Score Discussions

TypeScript

Local

pixelletter-mcp

Local MCP server (stdio) for the PixelLetter HTTPS interface. Hand it a PDF and a destination country and PixelLetter prints, folds, franks and posts the letter, optionally as registered mail. It also sends faxes, cancels orders, reads the account balance and drives the electronic invoice signature.

It pairs with pdf-letter-mcp: that server writes a DIN 5008 letter PDF, this one puts it in the post. send_letter takes the absolute path that create_letter returns.

The implementation follows the published documentation: the HTTPS handbook, the e-mail handbook, the two signature handbooks, the reference PHP class (version 2.01) and the public error code list. Three values are not printed in those documents, colour printing, GoGreen postage and the NODUPLEX switch, and they are taken from the hudora/pyPostal client that has been sending real orders with them. They are marked as such in the table below. Nothing else is invented.

How the interface works

Everything is one multipart HTTPS POST to https://www.pixelletter.de/xml/index.php. The form field xml carries the order document, credentials included, and the fields uploadfile0, uploadfile1 and so on carry the documents. The answer is a small XML document: code 100 means the order was accepted, anything else is an error code from the published list. The final result, including whether the recipient address fitted the address window, arrives by e-mail a few hours later.

Related MCP server: agent-mail-mcp

Test mode

Every sending tool needs an explicit testMode flag, there is no default. testMode: true runs the order exactly like a real one but PixelLetter never prints it, never sends it and never charges for it. testMode: false really posts the letter. Set PIXELLETTER_FORCE_TEST_MODE=true to pin the whole server to test mode while wiring things up.

Install

npm install
npm run build

claude mcp add pixelletter \
  --env PIXELLETTER_EMAIL=you@example.com \
  --env PIXELLETTER_PASSWORD=your-password \
  -- node "/absolute/path/to/pixelletter-mcp/dist/src/index.js"

Or in ~/.claude.json / claude_desktop_config.json:

{
  "mcpServers": {
    "pixelletter": {
      "command": "node",
      "args": ["/absolute/path/to/pixelletter-mcp/dist/src/index.js"],
      "env": {
        "PIXELLETTER_EMAIL": "you@example.com",
        "PIXELLETTER_PASSWORD": "your-password",
        "PIXELLETTER_DEFAULT_DESTINATION": "DE"
      }
    }
  }
}

Environment

Variable	Purpose
`PIXELLETTER_EMAIL`	Required. The e-mail address the PixelLetter account is registered with.
`PIXELLETTER_PASSWORD`	Required. The PixelLetter password.
`PIXELLETTER_ENDPOINT`	Endpoint of the interface. Default `https://www.pixelletter.de/xml/index.php`.
`PIXELLETTER_ACCEPT_TERMS`	Accept the PixelLetter terms with every order, default `true`. The API rejects orders otherwise (error 013).
`PIXELLETTER_WAIVE_WITHDRAWAL_RIGHT`	Waive the two week right of withdrawal so orders run immediately, default `true`. `false` delays every order by two weeks.
`PIXELLETTER_DEFAULT_LOCATION`	Default dispatch centre: `1` Munich (DE), `2` Hausleiten near Vienna (AT), `3` Hamburg (DE).
`PIXELLETTER_DEFAULT_DESTINATION`	Default destination country as a two letter ISO code, for example `DE`.
`PIXELLETTER_FORCE_TEST_MODE`	Force test mode for every order, default `false`.
`PIXELLETTER_TIMEOUT_MS`	Request timeout in milliseconds, default `120000`.

Credentials are only read from the environment, nothing is stored in the repository and nothing is written to disk.

Tools

Tool	Purpose
`send_letter`	Sends documents or plain text as a physical letter, optionally as a fax too.
`send_fax`	Sends documents or plain text as a fax only.
`get_account_info`	Reads the stored customer data and the current credit.
`cancel_order`	Cancels a submitted order by its PixelLetter order id.
`sign_invoice`	Sends documents to the electronic invoice signature service and optionally mails the signed PDF on.
`get_interface_reference`	Offline lookup of action values, dispatch centres, service codes, limits and error codes.

send_letter

Ready made PDF, the normal case:

{
  "testMode": true,
  "files": ["/Users/you/Documents/Briefe/2026-07-24-widerspruch.pdf"],
  "destination": "DE",
  "transaction": "widerspruch-4711"
}

Registered mail with return receipt, printed in colour on one side only:

{
  "testMode": false,
  "files": ["/Users/you/Documents/Briefe/kuendigung.pdf"],
  "destination": "DE",
  "registered": true,
  "returnReceipt": true,
  "colorPrint": true,
  "duplex": false
}

Plain text, typeset by PixelLetter, with the signature stored in the account:

{
  "testMode": true,
  "address": ["Erika Mustermann", "Musterstr. 28", "81237 Musterstadt", "Deutschland"],
  "subject": "Ihre Anfrage vom 12.07.2026",
  "text": "Hallo Frau Mustermann,\n\nvielen Dank für Ihre Anfrage.\n\nMit freundlichen Grüßen\n\n%Unterschrift%\nMax Mustermann",
  "destination": "DE"
}

Rules the tool enforces before anything is sent:

One order carries either documents or text, not both. Several documents are converted and merged into one letter, in the order given.
The destination country is mandatory for letters, a wrong code leads to wrong postage.
The recipient address has to be visible in the address window area of the document, PixelLetter checks this before dispatch.
Allowed upload types are .pdf, .doc, .xls, .ppt, .rtf, .wpd, .psd, 50 MB maximum. Error 053 shows that PixelLetter can restrict this to PDF, so PDF is the safe choice.
Additional services, colour print and duplex are letter only, a pure fax order rejects them. Codes 28 (return receipt) and 29 (personal delivery) need 27 (registered), code 30 (drop-in registered) stands alone. Registered mail is a German product, other destinations run into error 026.

Every option of the interface

Full coverage of the fields the interface documents. "Applies to" says which dispatch type accepts the option, invalid combinations are rejected before the request goes out.

API field	Tool parameter	Allowed values	Applies to	Source
`email`	`PIXELLETTER_EMAIL`	account e-mail	all	HTTPS handbook
`password`	`PIXELLETTER_PASSWORD`	account password	all	HTTPS handbook
`agb`	`PIXELLETTER_ACCEPT_TERMS`	`ja`, `nein`	all	HTTPS handbook
`widerrufsverzicht`	`PIXELLETTER_WAIVE_WITHDRAWAL_RIGHT`	`ja`, `nein`, `nein` delays the order by two weeks	all	HTTPS handbook
`testmodus`	`testMode`, `PIXELLETTER_FORCE_TEST_MODE`	`true`, `false`	all	HTTPS handbook
`order type`	picked from the input	`text`, `upload`, `cancel`	all	HTTPS handbook, reference class
`action`	`send_letter`, `alsoSendFax`, `send_fax`, `sign_invoice`	`1` letter, `2` fax, `3` letter and fax, `4` invoice signature	all	HTTPS handbook, signature handbooks
`transaction`	`transaction`	free text, returned with the response	all	HTTPS handbook
`fax`	`faxNumber`	international format, `+49 89 72448483`	fax	HTTPS handbook
`location`	`location`	`1` Munich (DE), `2` Hausleiten near Vienna (AT), `3` Hamburg (DE), default `1`	letter, fax	HTTPS handbook
`destination`	`destination`, `PIXELLETTER_DEFAULT_DESTINATION`	two letter ISO code, mandatory for letters, ignored for pure fax	letter	HTTPS handbook
`addoption` 27	`registered`	Einschreiben, registered mail	letter	HTTPS handbook
`addoption` 28	`returnReceipt`	Rückschein, return receipt, only with 27	letter	HTTPS handbook
`addoption` 29	`personalDelivery`	Eigenhändig, personal delivery, only with 27	letter	HTTPS handbook
`addoption` 30	`registeredDropIn`	Einschreiben Einwurf, drop-in registered mail, not combinable with 27, 28, 29	letter	HTTPS handbook
`addoption` 31	`cashOnDelivery`	Nachnahme, set automatically when the bank details block is given	letter	reference class 2.01
`addoption` 33	`colorPrint`	colour print instead of black and white	letter	pyPostal, error 038
`addoption` 44	`goGreen`	GoGreen, CO2 neutral postage	letter	pyPostal
`addoption` other	`additionalServiceCodes`	raw numbers PixelLetter agreed for your account	letter	HTTPS handbook
`control`	`duplex`	`true` double sided (default of PixelLetter), `false` sends `NODUPLEX` for single sided	letter	pyPostal
`control` raw	`control`	any token PixelLetter gave you, cannot be combined with `duplex`	letter, fax	reference class 2.01
`returnaddress`	`returnAddress`	raw value, no published meaning	letter, fax	reference class 2.01
`wiretransfer/recipient/name`	`cashOnDelivery.name`	1 to 27 characters	letter	reference class, errors 030 to 037
`wiretransfer/recipient/bankaccountid`	`cashOnDelivery.bankAccountId`	6 to 10 digits	letter	reference class, error 036
`wiretransfer/recipient/blz`	`cashOnDelivery.bankCode`	exactly 8 digits	letter	reference class, error 037
`wiretransfer/recipient/bankname`	`cashOnDelivery.bankName`	1 to 27 characters	letter	reference class, error 031
`wiretransfer/reasonforpayment1`	`cashOnDelivery.reasonForPayment1`	up to 27 characters	letter	reference class, error 032
`wiretransfer/reasonforpayment2`	`cashOnDelivery.reasonForPayment2`	up to 27 characters	letter	reference class, error 033
`wiretransfer/amount`	`cashOnDelivery.amount`	`XXXX,XX`, 3,00 to 1600,00 EUR	letter	reference class, errors 034, 035
`text/address`	`address`	recipient address lines, country included	letter, fax	HTTPS handbook
`text/subject`	`subject`	subject of the letter	letter, fax	HTTPS handbook
`text/message`	`text`	plain text, no HTML, `%Unterschrift%` inserts the stored signature	letter, fax	HTTPS handbook
`uploadfile0`, `uploadfile1`, ...	`files`, `inlineFiles`	`.pdf`, `.doc`, `.xls`, `.ppt`, `.rtf`, `.wpd`, `.psd`, 50 MB each	letter, fax, signature	HTTPS handbook
`order type="cancel"/id`	`cancel_order.orderId`	PixelLetter order id	cancellation	reference class 2.01
`sender`, `recipient`, `cc`, `bcc`, `subject`, `body`, `filename`	`sign_invoice.notification.*`	e-mail fields of the signature notification	signature	signature handbooks
`info/account:info type="all"`	`get_account_info`	no parameters	account	HTTPS handbook

get_interface_reference returns the same list at runtime, including the full error code table.

What the interface does not offer

Named explicitly, because their absence is a property of the API and not an omission of this server:

No job list. There is no documented call that lists or queries submitted orders. cancel_order works on an order id from the confirmation e-mail, get_account_info reports the balance, everything else lives in the PixelLetter customer area.
No envelope or paper format, no postage class, no delivery speed, no cover sheet, no reply envelope, no sender identification. These are no fields of the interface. Letters go into a DIN C6/5 window envelope and the postage follows weight and destination country.
No address correction. Premiumadress shows up in error 088, but it has to be set up by PixelLetter support for the account and has no request field.
Postcards, upload templates and bulk orders. The reference class and the error codes show they exist (font, template number, action 5), but no handbook documents their action values or their field layout. Sending a guessed action could produce a real, wrong dispatch, so they are left out.
ref in the auth block has no documented meaning and is always sent empty, exactly like the reference class does.

Verification

npm test    # XML payloads, response parsing, option rules, configuration, HTTP layer with a mocked fetch

The tests never touch the live API. The HTTP layer is exercised through an injected fetch, which checks the endpoint, the xml field, the uploadfileN parts, the test mode flag and the error code mapping.

License

MIT, see LICENSE.

Available Tools

5 tools

get_account_infoGet account info and balanceA

Reads the stored customer data and the current credit of the PixelLetter account. Use it before sending to make sure the balance covers the order, error 021 means the credit is too low.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

No annotations provided; description clearly indicates a read operation ('Reads'). Does not mention safety or side effects but is straightforward and correct for a read 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?

Two sentences, no wasted words. Front-loaded with purpose, followed by usage guidance.

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?

Covers usage and error code. No output schema, but return values not detailed. Reasonably complete for its simplicity.

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, so schema coverage is 100%. Description adds no param details, which is appropriate. Baseline of 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?

Clearly states it reads customer data and current credit. Distinct from sibling tools which are for sending or signing.

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 advises using before sending to check balance, and explains error 021 for low credit. Provides clear usage context.

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

get_interface_referenceGet interface referenceA

Returns what the PixelLetter interface documents: action values, dispatch centres, additional service codes, allowed upload types, limits and the published error codes. Offline lookup, no API call.

ParametersJSON Schema

Name	Required	Description	Default
`errorCode`	No	Look up a single error code, for example "021".

TDQS

A4.4/5.0

Behavior5/5

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

Description explicitly states it performs no API call and is offline, implying no destructive or network-dependent behavior. Without annotations, it fully discloses the tool's safe, read-only nature.

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: first enumerates returned data, second adds offline context. No wasted words, front-loaded with key information.

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?

Description covers what is returned but lacks detail on response structure or format. Given no output schema, a bit more detail would be helpful, but it is adequate for a simple lookup tool.

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 provides 100% coverage for the single optional parameter errorCode. Description references error codes but does not clarify behavior when parameter is omitted (likely returns all). Baseline 3 is appropriate as description adds minimal 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?

The description clearly states it returns interface documentation including action values, dispatch centres, etc. It is distinctly different from sibling tools like send_letter or send_fax, making its read-only reference purpose unambiguous.

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?

Description mentions 'Offline lookup, no API call' which implies safe usage, but does not explicitly state when to use versus alternatives. However, given sibling tools are all action-oriented, the context is clear enough.

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

send_faxSend faxB

Sends documents or plain text as a fax through PixelLetter, without posting a letter. Additional services such as registered mail do not apply to faxes.

ParametersJSON Schema

Name	Required	Description
`text`	No	Letter text as plain text, no HTML. Long texts run onto more pages automatically, your sender address is added by PixelLetter. "%Unterschrift%" on its own line inserts the signature stored in your PixelLetter account.
`files`	No	Absolute paths of the documents to send, for example the PDF written by pdf-letter-mcp. Several files are converted and merged into one letter, in this order. Allowed: .pdf, .doc, .xls, .ppt, .rtf, .wpd, .psd, and PDF is the only type that always works.
`address`	No	Recipient address, one line per array entry, country included. PixelLetter typesets it. Required when no file is sent.
`control`	No	Raw value for the control field of the interface. The only value in public use is NODUPLEX, which the duplex parameter sets for you, so only reach for this when PixelLetter gave you another token.
`subject`	No	Subject of the letter.
`location`	No	Dispatch centre: 1 = Munich (DE), 2 = Hausleiten near Vienna (AT), 3 = Hamburg (DE). Default of the API is 1.
`testMode`	Yes	Test mode. true runs the order exactly like a real one but PixelLetter never prints, never sends and never charges. false really sends the letter. Always required, so nothing goes out by accident.
`faxNumber`	Yes	Fax number in international format, for example "+49 89 72448483".
`inlineFiles`	No	Documents passed as base64 instead of a path.
`transaction`	No	Your own transaction id or short note. PixelLetter returns it with the response.

TDQS

B3.4/5.0

Behavior2/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 does not disclose behavioral traits such as authentication needs, rate limits, or what happens upon success or failure. The testMode parameter indicates a test mode, but the description does not elaborate on its behavior beyond the schema.

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-loading the core purpose and adding a clarifying detail about additional services. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 10 parameters and no output schema, the description remains minimal. It does not explain operational behavior, return values, or error cases. The schema covers parameters, but the description lacks completeness for effective agent usage without additional 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%, so the existing parameter descriptions are detailed (e.g., for text, files, address). The tool description adds no new parameter-level information beyond what the schema provides, meeting the baseline expectation.

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 sends documents or plain text as a fax via PixelLetter, specifically noting it does not post a letter. This differentiates it from the sibling tool 'send_letter' and clarifies that additional services like registered mail do not apply.

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

Usage Guidelines3/5

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

The description implies usage for faxing rather than mailing, but does not provide explicit when-to-use or when-not-to-use guidance. The mention that registered mail does not apply offers some direction, but alternatives like 'send_letter' are not mentioned in the description itself.

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

send_letterSend letterA

Sends a letter through PixelLetter, either as ready made documents (absolute file paths, PDF preferred) or as plain text plus a recipient address that PixelLetter typesets. Optionally faxes the same document as well. Returns the result code and the transaction id.

ParametersJSON Schema

Name	Required	Description
`text`	No	Letter text as plain text, no HTML. Long texts run onto more pages automatically, your sender address is added by PixelLetter. "%Unterschrift%" on its own line inserts the signature stored in your PixelLetter account.
`files`	No	Absolute paths of the documents to send, for example the PDF written by pdf-letter-mcp. Several files are converted and merged into one letter, in this order. Allowed: .pdf, .doc, .xls, .ppt, .rtf, .wpd, .psd, and PDF is the only type that always works.
`duplex`	No	Print on both sides (true, the default of PixelLetter) or on one side only (false, sent as control NODUPLEX). Letters only.
`address`	No	Recipient address, one line per array entry, country included. PixelLetter typesets it. Required when no file is sent.
`control`	No	Raw value for the control field of the interface. The only value in public use is NODUPLEX, which the duplex parameter sets for you, so only reach for this when PixelLetter gave you another token.
`goGreen`	No	GoGreen, CO2 neutral postage (addoption 44). Letters only.
`subject`	No	Subject of the letter.
`location`	No	Dispatch centre: 1 = Munich (DE), 2 = Hausleiten near Vienna (AT), 3 = Hamburg (DE). Default of the API is 1.
`testMode`	Yes	Test mode. true runs the order exactly like a real one but PixelLetter never prints, never sends and never charges. false really sends the letter. Always required, so nothing goes out by accident.
`faxNumber`	No	Fax number in international format, for example "+49 89 72448483". Only needed with alsoSendFax.
`colorPrint`	No	Colour print instead of black and white (addoption 33). Letters only, and not available through every dispatch centre, see error 038.
`registered`	No	Einschreiben, registered mail (code 27). Germany only.
`alsoSendFax`	No	Send the same document as a fax too. Needs faxNumber. Additional services stay letter only.
`destination`	No	Destination country as a two letter ISO code, for example DE, AT, CH. Mandatory for letters, a wrong code leads to wrong postage.
`inlineFiles`	No	Documents passed as base64 instead of a path.
`transaction`	No	Your own transaction id or short note. PixelLetter returns it with the response.
`returnAddress`	No	Raw value for the returnaddress field of the interface. Undocumented in the public handbooks.
`returnReceipt`	No	Rückschein, return receipt (code 28). Only together with registered.
`cashOnDelivery`	No	Bank details for cash on delivery. Setting this block adds additional service 31.
`personalDelivery`	No	Eigenhändig, personal delivery (code 29). Only together with registered.
`registeredDropIn`	No	Einschreiben Einwurf, drop-in registered mail (code 30). Cannot be combined with the other registered variants.
`additionalServiceCodes`	No	Raw addoption codes for services PixelLetter documents elsewhere or agrees per account. Only use numbers PixelLetter gave you.

TDQS

A3.6/5.0

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 action (sends), test mode to prevent charges, and return values. However, it omits details on idempotency, reversibility, authentication requirements, or rate limits, leaving behavioral gaps.

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?

Two sentences cover the core functionality efficiently without fluff. The structure could be slightly improved by grouping modes more clearly, but it is concise and front-loaded.

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 complexity (22 parameters, nested objects), the description covers the return values and test mode requirement but lacks mention of prerequisites (e.g., PixelLetter account), error handling, or operational limits, leaving some gaps for an agent.

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%, so baseline is 3. The description adds high-level context (e.g., how text and files interplay, signature insertion) but does not significantly deepen understanding of individual parameters beyond what the schema already provides.

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 sends a letter via PixelLetter, with two modes (ready documents or text plus address). It also mentions optional faxing and return values, clearly differentiating from sibling tools like send_fax or sign_invoice.

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

Usage Guidelines3/5

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

The description implies usage for sending letters but does not explicitly contrast this with sibling tools (e.g., when to use send_fax instead). It provides no exclusions or when-not-to-use guidance, relying on the user to infer from context.

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

sign_invoiceSign invoice electronicallyA

Sends documents to the PixelLetter invoice signing service (action 4) and optionally mails the signed PDF to the invoice recipient. The account needs electronic signatures enabled once in the customer area, otherwise PixelLetter answers with error 046.

ParametersJSON Schema

Name	Required	Description
`files`	No	Absolute paths of the documents to send, for example the PDF written by pdf-letter-mcp. Several files are converted and merged into one letter, in this order. Allowed: .pdf, .doc, .xls, .ppt, .rtf, .wpd, .psd, and PDF is the only type that always works.
`testMode`	Yes	Test mode. true signs with an advanced signature only, which is not legally sufficient, and costs nothing. false creates the qualified signature.
`inlineFiles`	No	Documents passed as base64 instead of a path.
`transaction`	No	Your own transaction id or short note. PixelLetter returns it with the response.
`notification`	No	Leave this out and nothing is mailed to the invoice recipient, you only get the signed file yourself.

TDQS

A3.9/5.0

Behavior4/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 test mode behavior, optional mailing, error condition (046), and merging of files. It lacks details on return values or side effects, but overall provides substantial behavioral 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 two sentences, front-loaded with the core action and optional behavior, followed by a crucial prerequisite. No wasted words.

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 complexity (5 parameters, nested objects, no output schema), the description covers the main purpose and a key error. However, it does not clarify how files and inlineFiles interact (e.g., can both be provided?), nor what the tool returns (e.g., order number). More detail would improve completeness.

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 description coverage is 100%, but the tool description adds meaning beyond the schema by mentioning the external service name (PixelLetter), action 4, and the optional mailing behavior which relates to the notification parameter. This extra context helps the agent understand the tool's integration.

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 sends documents to the PixelLetter invoice signing service (action 4) and optionally mails the signed PDF. This distinguishes it from sibling tools like send_letter and send_fax which are for physical sending, and get_account_info which is informational.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description mentions a prerequisite (electronic signatures enabled) and an error condition, but does not compare to siblings or specify contexts for use.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.0.0Jul 27, 2026
- First observedget_account_info
- First observedget_interface_reference
- First observedsend_fax
- First observedsend_letter
- First observedsign_invoice

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: sending a letter, sending a fax, checking account info, signing invoices, and retrieving interface reference. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., send_letter, get_account_info). No mixing of conventions.

Tool Count5/5

5 tools is well-scoped for a niche service like PixelLetter, covering sending, faxing, account management, e-signatures, and documentation. Not too few or excessive.

Completeness4/5

Covers core operations (send, fax, sign, account info) and reference. Minor gaps like bulk sending or history tracking are not critical but could be added.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MailStreamOAuth
app.mailstream
The first MCP server for physical mail: send postcards and letters, manage lists and campaigns.
Communication Marketing
2
mcp-serverOAuth
io.github.Print-one
An MCP server to send personalised direct mail.
Marketing Communication
2
Agent Safe Email MCP AOAuth
com.locationledger.agentsafe
A Remote MCP Server that checks every email before your agent acts on it. Connect via MCP protocol, pay per use with Skyfire.
Communication Security App Automation
2
Email Server
live.alpic.staging
An MCP server that provides email capabilities, hosted on Alpic platform
Communication App Automation
2

Related MCP Servers

mailbox-mcp
Communication
arbengine
A
license
A
quality
C
maintenance
Official mailbox.bot MCP server for AI agents. Send letters, certified mail, postcards, and receive scanned inbound physical mail with sandbox keys, approval controls, tracking, and webhooks.
Updated 2 months ago (2026-07-08 02:11 UTC)
29
114
2
MIT
agent-mail-mcp
Payments & Billing
postalform
A
license
Not graded
quality
C
maintenance
MCP server that lets AI agents create reviewable physical mail drafts, validate quotes, and pay for postage via MPP or x402 protocols.
Updated 3 months ago (2026-06-20 04:28 UTC)
1
MIT
mailsnail
Payments & Billing App Automation
iancollins27
A
license
Not graded
quality
B
maintenance
An open-source MCP server for sending physical mail (letters, postcards, certified mail) directly from AI agents, with per-piece payment and no account signup needed.
Updated 20 days ago (2026-08-17 20:24 UTC)
MIT
pdf-letter-mcp
bitterdev
A
license
A
quality
B
maintenance
Local MCP server that generates print-ready PDF letters with DIN 5008 compliant address positioning for window envelopes, handling structured content offline without external APIs.
Updated a month ago (2026-07-27 15:15 UTC)
7
55
MIT

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/bitterdev/pixelletter-mcp'

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