ReturnRadar MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RETURNRADAR_DATA_DIR | No | Absolute path to the private data directory used by both the backend and MCP client. Defaults to `private_data/` in the repository root. Must match the backend's data directory. |
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 |
|---|---|
| add_purchaseC | Save a reviewed purchase. Do not invent terms. Extracted fields need confirmation. |
| get_my_purchasesC | Search actual local purchases with filters and pagination. |
| get_purchase_detailsB | Get purchase, document metadata, policy evidence, and confirmed/tentative/unknown deadlines. |
| get_upcoming_deadlinesB | Get actionable confirmed deadlines within N days, in each purchase's timezone. |
| update_purchaseA | Replace fields and policies with reviewed values. Retrieve details first to preserve fields. |
| update_purchase_statusC | Record a user-reported status. This does not confirm any merchant approval. |
| generate_return_requestB | Draft a return, refund, warranty or replacement request from confirmed fields. Never sends it. |
| get_warranty_statusB | Get warranty provider, terms, evidence and status. Unknown starting dates or terms remain unknown. |
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 8 tools
Most tools have clearly distinct purposes: create, list/search, detail, update fields, update status, generate draft, and warranty status. Two mild overlaps exist: update_purchase vs update_purchase_status both modify a purchase, and get_purchase_details vs get_upcoming_deadlines both surface deadlines, but descriptions clarify the boundaries.
All tools use snake_case with a consistent verb_noun pattern (add_, get_, update_, generate_). The only slight variation is 'get_my_purchases' using a possessive, but it still follows the same convention.
Eight tools fit the focused purchase-return tracking domain well. Each tool earns its place by covering a distinct operation without redundancy.
Core lifecycle is present: create, list/search, detail, update fields/status, deadline retrieval, return drafting, and warranty status. Minor gaps include no delete operation and no direct way to update or manage warranty terms, but agents can likely work around them.