raposa-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RAPOSA_API_KEY | Yes | Your Raposa API key, read only from RAPOSA_API_KEY and never appears in tool inputs or outputs. | |
| RAPOSA_API_BASE | No | Base URL override for the Raposa API. | https://dcescrypt.com/api |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_approvalB | Create an approval request and return its id immediately (no waiting). Use with a webhook_url, or poll with get_approval. risk: low | medium | high. |
| get_approvalA | Read an approval by id. Look at |
| request_human_approvalA | Ask an authorised human to approve an action and wait for the answer. Returns {approved: bool, status, decided_by, ...}. Proceed ONLY if approved is true — a timeout, an expiry or a rejection means do not proceed. risk: low | medium | high. |
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 3 tools
Each tool has a clearly distinct purpose: create_approval is fire-and-forget async, get_approval is read-only polling, and request_human_approval is synchronous waiting. The descriptions explicitly differentiate the workflows, leaving no ambiguity.
create_approval and get_approval follow a clean verb_noun pattern, while request_human_approval deviates slightly by inserting 'human' into the noun phrase. Still, the overall pattern remains readable and predictable.
Three tools is well-scoped for a focused human-approval server. Each tool fulfills a necessary role: async creation, status lookup, and synchronous approval waiting. No redundant tools exist.
The core approval lifecycle (create, read, wait) is covered with no dead ends for the primary use cases. A list or cancel operation would be a minor gap, but the three tools support the main workflow effectively.