Loading ToolBench
Real Signal MCP reference plugin — gives Claude calm, source-attributed neighbourhood intelligence for one Singapore neighbourhood (Cluny Court + adjacent pockets).
Neighborhood Sense exhibits significant definition quality gaps. While all 11 tools have names starting with action verbs (get_, list_) and descriptions present, the descriptions are domain-specific but lack LLM-optimization guidance. Three tools (8-10) are marked 'planned' with server-side rollout pending, indicating incomplete implementation. Input schemas are minimal: most tools accept only 1-2 parameters with basic type declarations but lack enum constraints, format specifications, or validation ranges. No output schemas are documented in the source code. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. The composition patterns in index.js are reference documentation, not runtime tool definitions, creating ambiguity about actual tool behavior.
Read live merchant-confirmed experiences currently available in a pocket
Planned tool - score pocket against specific intent (e.g., 'calm-work') (manifest-listed, server-side rollout pending)
Read outlet substrate including observed patterns and decision-support lines from shadow-profile pipeline
Read trajectory of pocket atmosphere over specified hours with trend direction
Read current-state moment for a pocket including primary_state, calm_probability, signal_saturation, and silence indicators
Score each pocket by Moment Quality Score (MQS) scalar with band classification
No output schemas documented. Tools return structured content (e.g., 'structuredContent.mqs', 'structuredContent.pocket_id') but the response format is inferred from composition code, not formally specified. LLMs cannot plan downstream calls without knowing what fields to expect.
Input parameters lack validation constraints. 'hours' parameter in get_pocket_atmosphere has no min/max bounds (could be 0, negative, or 999999). 'query' in lookup_pocket_by_name has no length limits or format guidance. Unbounded parameters invite invalid LLM inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2025-06-18+ | v2 |
Planned tool - read predictions ledger for a pocket (manifest-listed, server-side rollout pending)
Planned tool - read silence state and reasons for a pocket (manifest-listed, server-side rollout pending)
Read sustainability metrics and environmental impact assessment for a pocket
Enumerate active set of observed pockets
Resolve free-text place name to pocket_id with confidence scoring
Three tools (get_pocket_silence, get_pocket_predictions, get_intent_substrate) marked 'planned' with 'server-side rollout pending'. These are manifest-listed but not live, creating ambiguity about whether they are callable. Planned tools should be removed from the manifest until implementation is complete.
No error handling guidance. Tools return structured content but no error responses are documented. What happens if pocket_id is invalid? If the service is down? LLMs receive no recovery hints.
Descriptions are domain-specific but lack LLM-optimization. 'Resolve free-text place name to pocket_id with confidence scoring' (65 chars) is clear but does not explain when to use this vs list_pockets, what confidence range means, or what happens if no match is found. Baseline for A+ tools is 50-200 chars with explicit WHEN/WHY guidance.