Pinpole MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PINPOLE_BASE_URL | No | Base URL of the Pinpole API. Can be overridden for local testing. | https://app.pinpole.cloud |
| PINPOLE_API_TOKEN | Yes | Personal access token (pp_live_…). Required for authenticated operations. | |
| PINPOLE_DEV_USER_ID | No | Local dev only. Firebase UID to impersonate when ALLOW_DEV_USER_HEADER is set on the server. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pinpole_build_architectureA | Turn a natural-language system description into a validated cloud architecture and draw it on the user's Pinpole canvas. Returns a canvas URL the user can open to see and edit the live ReactFlow diagram (a draw.io replacement). Optionally runs a cost simulation. Use this when the user wants to design or visualize a system/architecture. |
| pinpole_create_architectureA | Generate a validated {nodes, edges} cloud architecture from a description using Pinpole's AWS Well-Architected model. Does NOT draw it — pass the result to pinpole_draw_on_canvas or pinpole_simulate_cost. Use pinpole_build_architecture to do both in one step. |
| pinpole_simulate_costA | Run Pinpole's simulation engine over an architecture graph at a given traffic level and return per-node + total estimated monthly cost, latency (p50/p95/p99), throughput, and throttling/error alerts. Use to answer 'what will this cost / how will it perform'. |
| pinpole_draw_on_canvasA | Persist an architecture graph to the user's Pinpole canvas (ReactFlow), creating a project and workspace if none is given. Returns the canvas URL to open the live diagram. Nodes are auto-laid-out left-to-right when positions are omitted. |
| pinpole_open_canvasB | Return the Pinpole canvas deep link for a project + workspace so the user can open the live, editable architecture diagram in their browser. |
| pinpole_list_projectsA | List the authenticated user's Pinpole projects (id + title). |
| pinpole_create_projectC | Create a new Pinpole project to hold architecture workspaces. |
| pinpole_export_terraformC | Generate Terraform project files from an architecture graph. Works offline. |
| pinpole_list_servicesA | List AWS service ids/specs the canvas understands. Reads local repo specs when available. |
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 9 tools
Each tool has a clearly distinct purpose: building vs creating architecture, drawing vs simulating, listing vs opening. No overlapping functionality that could confuse an agent.
All tools follow a consistent 'pinpole_verb_noun' pattern in snake_case, making the naming predictable and easy to understand.
With 9 tools, the server covers the main workflows (create, visualize, simulate, export) without being bloated or too sparse. The count feels well-scoped.
The core lifecycle of architecture design is covered: create project, define architecture, draw on canvas, simulate cost, export to Terraform. Minor gaps like update/delete operations are absent but can be handled via the canvas UI.