A project-scoped persistent MCP gateway with BM25, semantic, and hybrid capability search plus the ratel CLI
Ratel Local exposes 4 tools with basic descriptions and schemas, but significant gaps limit production readiness. Tool names follow verb_noun convention (search_capabilities, invoke_tool, get_skill_content, auth), which is good. However, descriptions are minimal (10-60 chars), parameter descriptions are sparse or missing, and output schemas are not documented. The auth tool is defined in a UI file (ToolsPage.tsx), not the core server, suggesting incomplete tool registration. No evidence of error handling guidance, input validation rules, or pagination support. Schemas present but lack depth, parameters have types but descriptions are often single-word or absent.
Authenticate with an upstream MCP server using OAuth or other authentication flows
Retrieve the full content of a skill (reusable playbook) from the catalog
Execute a tool from the upstream MCP servers in the catalog
Search for tools and skills across the Ratel catalog using BM25, semantic, and hybrid search capabilities
Parameter descriptions missing or trivial. 'query' in search_capabilities has a description, but 'toolId' and 'arguments' in invoke_tool lack context. LLMs cannot infer what 'arguments' should contain or how to structure it.
Output schemas not documented. No indication of what search_capabilities returns (list of tools? metadata?), what invoke_tool yields (result object? raw response?), or what get_skill_content provides. LLMs cannot plan downstream calls without knowing response structure.
Tool descriptions under 50 characters lack context for selection. 'Execute a tool from the upstream MCP servers in the catalog' (invoke_tool) does not explain when to use it vs search_capabilities, what prerequisites exist, or what happens on failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2025-06-18+ | v2 |
auth tool defined in UI file (ToolsPage.tsx), not core server (packages/core/src/lib/server.ts). Suggests incomplete tool registration or missing from actual MCP server implementation. Cannot verify if auth is truly exposed as an MCP tool.
No error handling guidance. No indication of what errors invoke_tool or auth might return, whether they are retryable, or what the LLM should do next. Missing recovery patterns.