Loading ToolBench
MCP server for the StorEdge API. Exposes the Storable Edge (StorEdge) self-storage management API as MCP tools so Claude / Cursor / any MCP client can read and write a self-storage facility's data directly: tenants, units, leads, ledgers, insurance, tasks, move-in/out pipeline, surcharge calculations.
Strong foundation with 12 well-named, read-only tools covering a coherent domain (self-storage facility management). All tools have descriptions (avg ~150 chars, within baseline 194 chars). Input schemas present with typed parameters and descriptions. Key gaps: no output schemas documented, no error recovery guidance, no tool annotations (readOnlyHint despite all being read-only), and descriptions lack explicit 'when to use' guidance. Naming is verb-noun consistent (list_, get_, search_) and parameter names match across tools (facility_id, tenant_id, unit_id). However, descriptions are functional but not LLM-optimized, they state WHAT but not always WHEN or WHY to prefer one tool over another.
Fetch a single tenant by id. Use when: "show me the record for tenant <uuid>".
List a tenant's current ledgers (rental agreements). Use when: "what units is tenant <id> renting?".
List notes attached to a tenant. Use when: "what has the manager said about this tenant?".
Fetch a single unit (size, rate, amenities, current tenant).
Verify credentials work by listing one tenant. If this fails with 401, the OAuth 1.0 signature is wrong (consumer key or secret bad). If it fails with 403, the consumer is not authorized for this facility. Use this whenever other tools start returning auth errors - confirms whether the problem is creds or scoping.
List only units available for move-in. Use when: "what 10x10 units do I have open?", "show rentable inventory".
No output schemas documented. LLMs cannot infer what fields to expect from responses (e.g., does list_tenants return tenant_id, name, phone, move_in_date?). This forces agents to guess field names for downstream operations and risks context loss.
Descriptions lack 'when to use' guidance. E.g., get_tenant vs list_current_tenants, when should an agent pick one over the other? Descriptions state WHAT but not WHEN, forcing LLMs to reason about intent without explicit direction.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | <=2025-11-25 | v2 |
List only currently-active tenants (not moved-out). Use when: "show me everyone who has a unit rented right now".
List tenants for a facility. Use when: "show me all tenants", "list tenants moved in this month". Pagination: ``per_page`` up to 100, ``page`` is 1-indexed. Time filters accept ISO 8601 timestamps (``2026-07-01T00:00:00Z``).
List unit groups (size buckets: 5x5, 10x10 climate, etc.).
List unit types (Parking, Climate Controlled, Drive-Up, etc.).
List every unit for a facility (rented + vacant + offline). For "what's available right now" use ``list_available_units``.
Search tenants by account code or phone number. Provide exactly ONE of ``account_code`` or ``phone_number``. Phone matches digits - drop any non-numeric characters first. Use when: "find the tenant on account 12345", "who has phone 555-1212?".
No tool annotations despite all 12 tools being read-only. Adding readOnlyHint=true to all tools would signal to agents that these are safe to call without confirmation, enabling more aggressive optimization.
Error handling in health_check re-raises StoredgeError but provides no recovery guidance. LLMs see 'Authentication failed' but don't know whether to retry, ask the user, or check credentials. Error responses should categorize as retryable/user-fixable/fatal.
Pagination parameters (per_page, page) present in list tools but no documentation of max page size, total count return, or next_cursor pattern. Agents cannot determine if they've fetched all results or need to paginate further.