Loading ToolBench
A modular MCP server that enables AI agents to safely interact with M-Pesa/Daraja APIs.
Server has 10 tools with complete input schemas and descriptions present. However, descriptions are generic and repetitive ('Validate MCP input and delegate...'), averaging ~80 chars, below the 194-char baseline for A+ tools. All tools lack output schema documentation, which is critical for LLM planning. Parameter descriptions are minimal (e.g., 'Phone number for the payment' lacks format/validation hints). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Error handling is present in code but not surfaced in tool definitions. Naming is verb-first and clear (initiate_, check_, generate_, approve_, reject_, run_), which is good. No idempotency guidance in descriptions despite idempotency_key parameters. Overall: functional but below production baseline.
Validate MCP input and delegate approval execution to the payment service.
Validate MCP input and delegate payment status checks to the service.
Validate MCP input and delegate transaction status checks to the service.
Validate MCP input and delegate receipt generation to the service.
Validate MCP input and delegate failed transactions retrieval to the service.
Validate MCP input and delegate analytics summary retrieval to the service.
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., what does generate_receipt return? Is it a PDF URL, JSON object, or text?). This violates pattern:tool and forces agents to guess.
Descriptions are generic boilerplate ('Validate MCP input and delegate...'), averaging 80 chars vs. 194-char baseline. They do not explain WHEN to use each tool, what it returns, or how it differs from similar tools (e.g., initiate_stk_push vs initiate_payment). LLMs cannot disambiguate.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
Validate MCP input and delegate generic payment initiation to the service.
Validate MCP input and delegate payment initiation to the payment service. The public MCP tool remains M-Pesa-first for compatibility. The service layer delegates to the configured payment provider, which can be Daraja or another rail.
Validate MCP input and delegate approval rejection to the approval service.
Validate MCP input and delegate reconciliation to the reconciliation service.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications (WRITE vs READ_ONLY). Agents cannot infer safety properties without explicit hints. Pattern:command-tool requires this.
Parameter descriptions lack format/validation hints. E.g., 'Phone number for the payment' does not specify format (E.164? Local? Prefix?), length, or allowed characters. 'Amount' lacks currency, min/max bounds. LLMs will pass invalid values.
No idempotency guidance in tool descriptions despite idempotency_key parameters. Agents do not know when/why to use the key or what happens if omitted. Pattern:idempotent-operation requires explicit documentation.