Loading ToolBench
An MCP server providing access to Sally, an AI assistant specializing in metabolic health, through the x402 blockchain-based payment protocol
The server has 1 tool (chat-with-sally) with a clear action-verb name and documented schema. However, the tool has significant gaps in parameter descriptions and lacks critical error-handling guidance. The description is adequate but generic. Parameter schema includes type and description, which is positive, but the overall guidance for LLM decision-making is thin. The server includes prompts and resources which add value, but these do not compensate for tool-level definition quality issues.
Chat with Sally to talk about metabolic health (requires privateKey configuration)
Tool description lacks context on when to use chat-with-sally vs alternatives, what prerequisites exist, and what the return format contains. Description is 94 chars, at the low end of the 10-1024 range. Should explain the x402 payment protocol requirement, expected response format, and when Sally is the right choice vs other health tools.
No error handling guidance. The tool catches errors and returns a text message, but the description does not prepare the LLM for failure modes: missing privateKey configuration, API timeouts, rate limits, or invalid messages. Error messages like 'Failed to chat with Sally. Error: <message>' are reactive, not proactive. LLM has no guidance on retry behavior or what to do if Sally's API is unavailable.
Parameter 'message' has minimal description: 'The message to send to Sally'. Does not specify: max length, format constraints, expected topics (metabolic health, nutrition, exercise, etc.), whether followups are supported, or how to structure multi-turn conversations. A 72-char baseline suggests this param description should be ~72 chars but is much shorter.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Output schema is not documented. The tool returns res.data wrapped as a text field, but the LLM cannot know: Is it a string? JSON object? Array? Does it include follow-up suggestions, metadata, or confidence scores? A documented return schema (e.g. 'Returns JSON with keys: response (string), topics (array of strings), confidence (0-1)') would enable better planning.
Private key requirement is mentioned in the tool description ('requires privateKey configuration') but not enforced at the tool level. The code checks 'if (!apiClient)' and returns an error, but a better pattern is to fail fast at tool registration or provide a clear configuration guide. No documentation on how to acquire or manage the privateKey.