Loading ToolBench
MCP Server for Optix workspace management with business-specific tools
This MCP server defines 6 tools for GraphQL schema introspection and Optix workspace management. While input schemas are present and mostly well-typed for all tools, descriptions vary in quality. Three tools (introspect-schema, search-schema, get-enum-values) are utility tools for schema exploration with adequate descriptions. Two Optix-specific business tools (optix_list_bookings, optix_get_booking_details) have solid descriptions aligned with user intent. However, one critical tool (generate-query) has a vague description that doesn't explain its purpose or when to use it. Parameter descriptions are generally present but inconsistent in detail. Output schemas are not documented for any tool, critical for LLM planning. Error handling is minimal; no recovery guidance, no classification of errors as retryable vs fatal. The server uses Zod for runtime validation but doesn't expose these schemas in the tool definitions visible to the LLM. Composition is reasonable: tools are single-purpose and include chaining IDs (e.g., booking_id returned from list can feed into get_booking_details). No tool annotations (readOnlyHint, destructiveHint) are present despite all tools being READ_ONLY.
Generate a safe GraphQL query template for a given intent and parameters. Returns query + variables.
Return all values for a GraphQL enum by name. Use this instead of introspecting the full schema.
Introspect the GraphQL schema, use this tool before doing a query to get the schema information if you do not have it available as a resource already.
Get comprehensive details about a specific booking, including member information, resource details, and booking history.
List bookings in your Optix workspace. Perfect for checking daily schedules, finding specific bookings, or getting an overview of space usage. You can filter by date range, status, member, or resource.
Output schemas are completely undocumented. The LLM cannot determine what fields to expect from tool responses, blocking downstream tool selection and field extraction.
generate-query has an inadequate description (41 chars). It states 'Generate a safe GraphQL query template for a given intent and parameters. Returns query + variables.' but does not explain WHEN to use it vs calling the API directly, what 'safe' means, or that it's not executing the query.
introspect-schema accepts a useless '__ignore__' parameter (default=false, no description beyond 'This does not do anything'). This pollutes the schema and confuses the LLM about what the tool actually requires.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 21 | - | v1 |
Search the GraphQL schema text and return matching lines with small context. Useful to avoid dumping the full schema.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. All 6 tools are marked READ_ONLY in the metadata but the tool definitions themselves lack structured hints for the LLM.
Error handling is absent. No recovery guidance, no classification of errors as retryable vs user-fixable. When generate-query fails to parse a GraphQL intent or when optix_list_bookings hits a network error, the LLM receives no guidance on what to do next.
Parameter descriptions are inconsistent. 'context_lines' in search-schema has a full description; many parameters in generate-query (e.g., 'organization_id', 'user_id', 'location_id') lack any context about what they control or when they are required.
Tool naming inconsistency: introspect-schema, search-schema, and get-enum-values use hyphens; optix_list_bookings and optix_get_booking_details use underscores. While both are valid, mixed conventions reduce discoverability and make it harder for the LLM to parse tool names.