pix-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port when in HTTP mode | 3000 |
| MCP_MODE | No | Server mode: 'stdio' for MCP, 'http' for HTTP API | stdio |
| NODE_ENV | No | Environment: 'development' or 'production' | development |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generateStaticPixB | Generate a static Pix QR code for any Pix key (works without API credentials) |
| healthCheckA | Check the health status of the Pix MCP server and providers |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one generates a static Pix QR code, the other checks server health. No ambiguity or overlap exists.
Both tools use camelCase, but one starts with a verb (generateStaticPix) and the other with a noun (healthCheck). Minor inconsistency but still readable.
With only 2 tools, the server feels very thin for a Pix-related service, which typically includes dynamic Pix generation, key management, and administrative operations.
The server only covers static Pix generation and a health check, missing key functionality like dynamic Pix, Pix key validation, or transaction history, leading to significant gaps.