Loading ToolBench
A local agent runtime & workspace — a tiny agent OS for learning how agents work. Runs agents as HTTP services with tool execution, session persistence, and MCP server integration.
AgentSpace provides 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention (write_tool, conversation_search, fetch_sports_data, http_fetch, image_search). Descriptions are present and contextual (avg ~150 chars), meeting baseline minimums. However, parameter descriptions lack depth, many omit format constraints, valid ranges, or dependency hints. Output schemas are undocumented; LLMs cannot predict response structure for chaining. Error handling is minimal; tools return raw API responses without recovery guidance. write_tool is a meta-tool with WRITE risk but no confirmation pattern. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles.
Search past conversation transcripts (session memory) for a keyword/phrase and return matching message snippets with their session id. Use to recall what was discussed earlier. scope 'self' (default) searches this agent; 'all' searches every agent's sessions.
Get current scores, game status, and standings info for a major sports league (scoreboard from ESPN). Supported leagues: bundesliga, cfb, champions-league, club-world-cup, college-football, cwc, epl, fifa, fifa-world-cup, laliga, ligue1, mlb, mls, nba, nfl, nhl, ncaam, premier-league, seriea, ucl, wnba, world-cup, wc. Optionally pass a date (YYYYMMDD) for a specific day's games.
HTTP GET a URL and return the response body as text (truncated). Use for APIs and pages; for rich web content prefer the web_search tool or a fetch MCP server.
Search the web for images by keyword and return matching results as markdown (inline thumbnail, title, source page, license). Use when the user wants to find or show pictures of something.
Author a NEW tool for yourself when you lack a capability. Describe the tool and an implementation spec; the PI coding agent writes it and it becomes callable on your next turn. Use this when no existing tool can do what the user asked (e.g. creating a document, making a chart).
Output schemas undocumented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. fetch_sports_data, http_fetch, image_search return raw API responses without documented shape.
Parameter descriptions lack format constraints and valid ranges. 'date' in fetch_sports_data states 'YYYYMMDD' but no validation or error guidance if format is wrong. 'count' in image_search has no min/max bounds (1-20 stated in description but not enforced).
write_tool (WRITE risk) lacks confirmation or dry-run pattern. Agent can author arbitrary code without review. No safeguards against malicious tool specs or infinite loops.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). conversation_search and fetch_sports_data are read-only but unmarked. write_tool is destructive but unmarked. LLMs cannot infer safety properties.
Error handling minimal. http_fetch truncates responses without documenting max length or pagination. No recovery guidance (e.g., 'URL not found, try search_web first'). Raw API errors leak to LLM.