Loading ToolBench
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
RevoGrid MCP demonstrates solid tool design with comprehensive schemas and clear descriptions. All 8 tools have explicit input/output schemas defined via Zod (SearchRevogridDocsInputSchema, etc.) and descriptions ranging 80-180 chars. Tool names follow verb_noun convention (search_, find_, resolve_, get_, list_, inspect_, plan_, validate_). Parameters are well-typed with enums for framework/product/surface filters. However, descriptions lack WHEN-to-use guidance and dependency hints. Output schemas are documented but responses may include verbose metadata. Error handling is minimal, no recovery guidance or actionable error messages visible in tool definitions. All tools are READ_ONLY (safe), but no confirmation patterns for destructive operations (N/A here). Composition is strong: tools chain logically (search → inspect → plan → validate). Parameter naming is consistent (query, framework, version, packageName). Pagination implemented with cursor+limit pattern across discovery tools.
Use when implementation evidence should be a runnable or registered RevoGrid example, optionally filtered by framework and package.
Get upgrade notes between RevoGrid versions.
Use after discovery to resolve one exact symbol or capability. Returns ambiguity candidates instead of guessing and includes its supported import and evidence.
Start here to discover supported public capabilities and package ownership. Returns compact paginated summaries linked to detailed resources.
Use after resolving capability names to compose a deterministic package, plugin-order, configuration, lifecycle, and import plan.
Resolve whether a RevoGrid feature exists, whether it is Pro, and where to learn it.
Tool descriptions lack WHEN-to-use guidance and prerequisites. E.g., search_revogrid_docs says 'Use for broad questions' but doesn't explain when to call inspect_revogrid_api instead or what 'broad' means to an LLM.
No error handling guidance visible in tool definitions. Tools return structured output but lack recovery hints (e.g., 'If no results, try search_revogrid_docs with broader query').
Parameter descriptions are minimal. E.g., 'surface' enum has no explanation of what 'core', 'pro', 'pivot', 'plugin' mean or when to use each. LLMs cannot infer domain semantics from enum values alone.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
Use for broad RevoGrid questions or when the exact API name is unknown. Searches source-grounded docs and API evidence; defaults to public exports.
Validate a code snippet or configuration against RevoGrid best practices and API compatibility.
validate_revogrid_usage tool description is vague ('Validate a code snippet or configuration'). Does it check syntax, API compatibility, best practices, or all three? What does the response contain?
No documented output schema examples or field descriptions. Agents cannot plan downstream calls without knowing what fields (e.g., 'resourceUri', 'packageName', 'id') are returned.