Loading ToolBench

Reading the current corpus…

mcp-refund-server-python MCP server · D · ToolBench

← Browse

mcp-refund-server-python

github.com/thebigviditb/mcp-refund-server-python

MCP server exposing customer lookup and refund tools over stdio

<=2025-11-25STDIO2 tools

59/100

Definition Quality83

Protocol Readiness47

Supportability28

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Two well-defined tools with complete JSON schemas, clear descriptions, and proper input validation. Both tools have explicit type definitions, parameter descriptions, and tool annotations (readOnlyHint, destructiveHint). Descriptions are concise (120 - 180 chars) and explain what, when, and consequences. Error handling distinguishes domain errors (is_error=True) from protocol errors (JSON-RPC codes). Main gaps: no output schema documentation, no pagination support, and descriptions lack dependency hints or recovery guidance.

Tools (2)

get_customer_recordread onlysource verified85/100

Fetch the billing record for a customer. `customer_id` must be formatted as CUST-XXXXX, where XXXXX is exactly five uppercase letters or digits.

trigger_refundirreversiblesource verified80/100

Raise a pending refund against a customer's refundable balance. Requires a positive `amount` with at most two decimal places and a `reason` of at least 10 characters. This writes to the billing system and is not reversible.

Issues (5)

HIGHtool ↗

Output schemas not documented. LLMs cannot infer what fields to expect from tool responses, forcing them to guess at downstream field names and risk broken tool chains.

get_customer_recordtrigger_refund

MEDIUMrecovery-guide ↗

Descriptions lack recovery guidance. Error messages say 'customer_not_found' but do not suggest calling search_customers() or listing available IDs. Agents cannot self-correct without extra reasoning.

get_customer_recordtrigger_refund

MEDIUMidempotent-operation ↗

trigger_refund description does not explain idempotency or retry semantics. Agents do not know if retrying with the same amount/reason creates duplicate refunds or is safe.

trigger_refund

LOWtool-composition ↗

No batch operations. If an agent needs to refund 10 customers, it must call trigger_refund 10 times sequentially, wasting tokens and latency. A batch_trigger_refunds tool would be more efficient.

trigger_refund

Recommendations

Document output schemas for both tools. Example: 'Returns {customer_id, name, email, refundable_balance, account_status}' for get_customer_record and '{refund_id, customer_id, amount, reason, status, remaining_balance}' for trigger_refund.
Add recovery hints to error responses. E.g., 'Customer not found. Verify the customer_id format (CUST-XXXXX) or call list_customers() to find the correct ID.'
Clarify idempotency in trigger_refund description: 'Calling this twice with the same customer_id, amount, and reason will create two separate refunds. Use refund_id to check if a refund already exists before retrying.'
Consider adding a batch_trigger_refunds tool accepting an array of {customer_id, amount, reason} objects, returning per-item success/failure. Reduces token waste for multi-customer operations.
Migrate from STDIO to HTTP+SSE or Streamable HTTP transport to enable remote client access and hosted MCP deployments.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

59/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	59	<=2025-11-25	v2