Loading ToolBench

Reading the current corpus…

bonnard MCP server · D · ToolBench

bonnard

MCP server that provides access to a Cube semantic layer for querying cubes, views, measures, dimensions, and segments via an AI-friendly interface

<=2025-11-25STREAMABLE_HTTP5 tools

59/100

Definition Quality59

Protocol Readiness72

Supportability50

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Bonnard demonstrates solid definition quality with all 5 tools having clear verb-prefixed names (explore_, list_, search_, query, sql) and substantive descriptions (115-194 chars). Input schemas are present for all tools with proper type definitions and descriptions. The server implements thoughtful error classification and recovery guidance. However, output schemas are not explicitly documented, parameter constraints could be more specific, and some descriptions lack dependency hints or prerequisite guidance. The coercion logic and error handling show production consideration. Overall: B-grade (good, minor gaps).

Tools (5)

explore_schemaread onlyauthsource verified77/100

Fetch detailed metadata (measures, dimensions, segments) for a specific cube or view. Returns formatted documentation with all available fields.

list_schemaread onlyauth50/100

List all available cubes and views in the semantic layer with summaries showing measure, dimension, time dimension, and segment counts.

queryread onlyauthsource verified73/100

Execute a JSON query against the Cube load API. Query must specify measures, dimensions, and optional filters/segments. Returns up to 250 rows with pagination support.

search_schemaread onlyauth50/100

Search for measures, dimensions, and segments by name or description across all cubes and views. Returns up to 50 matches.

sqlread onlyauth50/100

Execute raw SQL against the Cube SQL API. Returns results with column schema and up to 250 rows of data.

Issues (6)

HIGHresponse-shaper ↗

Output schemas not documented in tool definitions. Users/LLMs cannot predict response structure (field names, types, pagination info) without reading source code or empirical testing.

explore_schemalist_schemasearch_schemaquerysql

MEDIUMconstrained-input ↗

Missing parameter constraints for numeric fields. 'query' tool accepts 'limit' (default 250) and 'offset' but no min/max bounds specified. 'search_schema' returns 'up to 50 matches' but no limit parameter exposed to control this.

querysearch_schema

MEDIUMpaginated-result ↗

No pagination metadata in tool descriptions. Tools mention result limits (250 rows, 50 matches) but do not specify whether pagination is supported, what offset/limit values are valid, or whether a next_cursor/total_count is returned.

querysearch_schema

Recommendations

Add explicit output schema documentation to all tools. For 'explore_schema', document that it returns a markdown-formatted string with sections: CUBE/VIEW name, Measures (array with name/type/description), Dimensions, Time Dimensions, Segments. Include example output.
For 'query' tool, expand the 'query' parameter description to document the nested object structure: 'Cube query object: {measures: string[], dimensions: string[], filters?: object[], segments?: string[], order?: object[], limit?: number (1-250, default 250), offset?: number (0+)}'.
Add explicit min/max bounds to 'query' and 'search_schema' descriptions: 'Returns up to 250 rows. Use offset/limit for pagination (limit: 1-250, offset: 0+).' and 'Returns up to 50 matches. Refine your query to reduce results.'
Add dependency hints to tool descriptions. E.g., search_schema: 'Tip: Call list_schema first to see available cubes/views, then use search_schema to find specific measures/dimensions within them.'
Document error recovery in tool descriptions. E.g., query/sql: 'If you receive a CONNECTION_ERROR, verify the Cube API endpoint is accessible. Try list_schema first to confirm connectivity.'
Consider adding tool annotations (readOnlyHint) since all tools are read-only against Cube. This signals to agents that these operations are safe to retry and compose freely.
Validate and document the 'query' parameter structure more explicitly in code comments or schema examples, since agents must construct nested JSON objects correctly.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

↑ 30 points across a rubric change (v1 → v2)

59/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	D	59	<=2025-11-25	v2
2026-03-09	F	29	-	v1