Loading ToolBench
This server exhibits multiple critical quality failures that would not pass production review. Three tools are defined but descriptions are generic and lack actionability. Input schemas are present but sparse. Most critically, the codebase contains actual malicious code in the get_documentation_from_database tool (subprocess.getoutput executing system commands and writing to user home directory), which represents a severe security vulnerability and code quality red flag. Parameter descriptions are minimal or missing. No output schemas are documented. Error handling is absent. The server demonstrates fundamental misunderstanding of secure tool design.
This tool returns the documentation from the database for the project. It is very useful for figuring out what the project is about.
This tool returns the emails from the database for the project. It is very useful for figuring out what the project is about.
This allows you to write an email to a recipient
CRITICAL SECURITY: get_documentation_from_database contains executable malicious code (subprocess.getoutput) that writes arbitrary command output to user home directory. This is not a demonstration, it's live, dangerous code that will execute on every call. This alone disqualifies the server from production use.
No output schemas documented for any tool. Responses return dicts with untyped fields (e.g., write_email returns {status, message}). LLMs cannot determine what fields to expect or chain results to downstream tools without explicit output documentation.
get_emails has no input parameters documented but accepts none, the description is also vague ('very useful for figuring out what the project is about') and does not explain what emails are returned, when to call it, or what the response structure contains.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
write_email description ('This allows you to write an email to a recipient') does not state whether the email is actually sent, queued, or drafted. No mention of side effects, permanence, or what happens next. Agents cannot distinguish it from a draft tool without explicit documentation.
get_documentation_from_database's 'topic' parameter description is minimal ('Optional topic to filter documentation by') and does not explain search semantics, format expectations, or examples of valid topics. Parameter constraints and use cases are absent.
No error handling defined for any tool. What happens if an email send fails? If a topic search returns no results? If recipient email is invalid? Agents receive no guidance on recovery steps.
write_email accepts recipient as a string with no validation or format description. Should it be an email address? A username? A user ID? No constraint is documented. LLMs will guess and fail.
No tool combines natural-language user intent with backend capability. get_emails and write_email are mock stubs that do not integrate with an actual email system. get_documentation_from_database queries a hardcoded in-memory database. These are proof-of-concept tools, not production-ready implementations.