Loading ToolBench
Cloudflare Workers MCP server for Safaricom Daraja APIs, including OAuth token management, STK Push, status query, payment verification, and callback handling.
Server has 9 tools with mostly complete schemas and descriptions, but quality is inconsistent. Tool names follow verb_noun convention (get_, check_, verify_, etc.), which is good. However, descriptions vary widely in clarity and actionability. Most parameters have type definitions and descriptions, but several lack sufficient detail for LLM reasoning. Output schemas are not explicitly documented. Error handling is present but generic. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. stk_push is the only WRITE operation but lacks confirmation/dry-run pattern. Overall execution is competent but falls short of production-grade polish.
Queries Daraja for STK transaction status and returns a normalized response.
Explains known Daraja error codes and recommended next actions.
Generates and returns a Daraja OAuth access token (cached in TOKENS KV).
Returns current API usage and daily limit information.
Generates a deterministic multi-step payment workflow plan for either payment initiation or status checks.
Simulates a payment flow for development without calling Daraja APIs.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk levels. stk_push is marked WRITE but lacks annotation in schema. Agents cannot distinguish safe vs destructive operations without explicit hints.
Output schemas not documented. Tools return responses but LLMs cannot plan downstream calls without knowing return structure. E.g., stk_push returns checkoutRequestId but this is not formally documented.
stk_push (WRITE operation) lacks confirmation/dry-run pattern. Agents can trigger real M-Pesa charges without verification. No idempotency guarantee documented.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
Initiates an M-Pesa STK Push request and logs transaction metadata to KV.
Summarizes transaction history with optional AI enhancement.
Verifies payment intent using transaction status, amount matching, and optional phone matching.
Parameter descriptions lack format/constraint details. phoneNumber accepts '2547XXXXXXXX or 07XXXXXXXX' but no regex or validation guidance. accountReference 'max 12 chars' is mentioned but not enforced in schema.
orchestrate_payment_workflow description (55 chars) is too vague. 'Generates a deterministic multi-step payment workflow plan' does not explain WHEN to call it vs stk_push directly, or what 'deterministic' means to an LLM.