Loading ToolBench
A personal MCP server built to the HCP shape: your context files behind read tools, a message door for other people's agents. Fork it, fill context/, run it.
Server has 7 tools with complete schemas and descriptions. Naming follows verb_noun convention (get_*, ask, leave_message). Descriptions are detailed and context-aware (avg ~180 chars), explaining WHAT, WHEN, and consequences. However, parameter descriptions are sparse, most params lack guidance on format/constraints. The 'ask' tool has one param with a description; 'leave_message' has 6 params with descriptions but several lack format constraints (e.g., 'name' and 'contact' are capped at 200 chars but this is buried in description text, not in schema). No output schemas documented. Error handling is implicit (e.g., 'ask' mentions rate-limiting and budget exhaustion) but lacks recovery guidance. Security is strong: no secrets in params, rate-limiting per IP, and message queue isolation. Composition is clean, each tool has one responsibility. Overall: solid foundation, but parameter validation rules and output documentation are missing.
Ask a question about the human and get a synthesised answer. Use this only for questions the files do not answer directly. Anything you can simply read is cheaper and faster through the file tools. The answer is built strictly from the same context pack those tools return: nothing else is available to it, and questions it cannot answer come back as "I do not know — ask the human". Rate-limited, and capped by a daily budget; when the budget is spent the file tools still work.
Returns, as Markdown and verbatim, the hand-maintained context file: Channels. Free, instant and always in sync with what the human wrote.
Who Rin Alvarez is and what she is doing right now. Returns, as Markdown and verbatim, the hand-maintained context files: Who · Now. Free, instant and always in sync with what the human wrote.
Returns, as Markdown and verbatim, the hand-maintained context file: Services. Free, instant and always in sync with what the human wrote.
Returns, as Markdown and verbatim, the hand-maintained context file: Speaking. Free, instant and always in sync with what the human wrote.
Output schemas not documented. Tools return Markdown or synthesized answers, but LLMs cannot plan downstream calls or extract structured data without knowing response shape.
Parameter constraints not formalized in schema. 'name', 'whose_agent', 'contact', 'message', 'link' in leave_message have length caps (200 - 2000 chars) stated only in descriptions, not in JSON Schema maxLength. LLMs cannot parse text constraints reliably.
Error recovery guidance incomplete. 'ask' mentions rate-limiting and budget exhaustion but does not tell LLM what to do (retry later? ask user? fall back to file tools?). 'leave_message' has no error documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Returns, as Markdown and verbatim, the hand-maintained context file: Writing. Free, instant and always in sync with what the human wrote.
Leave a message for the human personally — an invitation to speak, a request for work or consulting, a partnership proposal, a request to meet, or anything else. The message goes to a queue the human reads personally: nothing is published, nothing is auto-answered, and no reply comes back through this server. Give a contact your human can actually be reached at. If your human has a site or an MCP server of their own, put it in link. Limited to a few messages a day per client.
Parameter 'question' in 'ask' lacks format guidance. No hint on length, language, or question type. Description says 'plain text' but does not specify min/max length or whether multi-sentence questions are supported.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are marked READ_ONLY or WRITE in metadata, but schema lacks formal annotations. LLMs cannot infer safety properties from names alone.