Agent-callable donations to GiveWell in BTC, ETH, and USDC. MCP server + HTTP API.
Strong tool definitions with clear naming, comprehensive descriptions, and well-structured schemas. All 5 tools follow verb_noun convention (get_, prepare_, broadcast_, check_, donate_). Descriptions are detailed (100-300 chars) and explain WHEN to use each tool and what happens. Input schemas are complete with enums and type constraints. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles.
Broadcast a transaction the agent already signed itself. The destination is verified to be GiveWell before broadcasting, and rejected otherwise. Requires no donor key here — the agent keeps full custody and this only relays.
Check the donation wallet balance across all supported chains and assets (ETH on Ethereum mainnet; USDC on Ethereum mainnet and Base). Returns what is available to donate and whether enough gas is present to move it. Call this before donating.
Irreversibly donate funds from the configured donation wallet to GiveWell, which directs money to evidence-backed global health charities. Destination addresses are fixed to GiveWell's published addresses and cannot be overridden. This spends real money and cannot be undone. Amounts are swept in full unless a specific amount is given.
Get GiveWell's donation address for an asset. Requires NO configuration and no key — any agent that can move funds by any means can donate by sending to this address. This is the zero-setup path and works even if no donor wallet is configured here.
Build an UNSIGNED transaction donating to GiveWell, ready for the agent to sign with whatever wallet or signing tool it already has. Requires no donor key here. Use this when the agent holds funds through its own means rather than via GIVEWELL_DONOR_KEY.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects) for downstream tool chaining or data extraction. E.g., check_donation_balance returns balance info but structure is invisible.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked READ_ONLY or IRREVERSIBLE in metadata but not in schema. LLMs cannot infer safety properties from tool definitions alone.
Error handling lacks recovery guidance. No error response examples or actionable next steps. If broadcast_signed_donation fails (e.g., wrong destination), LLM has no guidance on retry or fallback.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
prepare_donation and donate_to_givewell accept optional 'chain' parameter but description does not clarify default behavior. LLMs may omit the param unintentionally, defaulting to ethereum when base was intended.
donate_to_givewell description warns 'Amounts are swept in full unless a specific amount is given' but does not clarify what 'swept' means (all balance minus gas?). Ambiguous language risks LLM misunderstanding.