Loading ToolBench
Local semantic event bridge and MCP server for specter-sense
Three read-only tools with clear verb-noun naming (get_*). All have descriptions (avg 95 chars, within baseline 34-392). Tool schemas present with Zod validation. However, parameter descriptions are minimal (under 20 chars for some), and output schemas are not documented. No error handling guidance, no recovery paths. Composition is sound (each tool does one thing), but descriptions lack context on WHEN to use each tool vs. alternatives.
Return the latest authoritative specter-sense state and connection metadata.
Return recent semantic sensor and occupancy transitions, oldest first.
Return sensor health and the currently occupied, vacant, and stale zones.
Output schemas not documented. LLMs cannot infer what fields to expect from get_current_state, get_room_summary, or get_recent_events. The result() helper returns both text and structuredContent, but the structure of that content is opaque.
Parameter descriptions are too brief. 'Maximum events to return (default 50)' and 'Only return events newer than this event ID' lack context on when to use pagination or filtering. Descriptions should explain the use case and relationship to other parameters.
No error handling or recovery guidance. If the specter-sense connection is down, what does get_current_state return? If after_id is invalid, what error message guides the LLM? No actionable error responses.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2025-06-18+ | v2 |
Tool descriptions lack differentiation. All three tools return state/events, but the descriptions do not explain when to call get_current_state vs get_room_summary vs get_recent_events. LLMs may conflate them.
No pagination metadata in get_recent_events response. The tool accepts limit and after_id, but the response structure (EventPage) is not documented. LLMs cannot determine if more results exist or how to construct the next query.