Loading ToolBench
Starlake MCP server that dynamically registers tools from OpenAPI specifications
Single tool 'dynamic_openapi_tools' has critical definition gaps. Input schema is empty object with generic description stating schema is 'dynamically generated', this violates the requirement that every tool must have a concrete, visible schema. No parameter descriptions provided. Tool description is 194 chars but lacks WHAT it does operationally, WHEN to use it, and what the LLM should expect. No output schema documented. No error handling guidance visible. Naming 'dynamic_openapi_tools' is generic and does not start with an action verb (get_, create_, etc.), violating verb_noun convention.
Dynamically generated tools from OpenAPI specification paths. Each endpoint in the OpenAPI spec becomes a tool with the name pattern: {method}_{path_normalized}
Input schema is empty object with no properties. This prevents LLMs from understanding what parameters to pass.
Tool name 'dynamic_openapi_tools' does not start with action verb (get_, create_, list_, etc.). Naming violates verb_noun convention. LLMs cannot infer intent from name alone.
Tool definition is inferred from OpenAPI spec at runtime, not statically visible in code. No explicit tool registration with schema visible in handlers.py.
No output schema documented. LLMs cannot plan downstream calls or extract required fields. Violates pattern:tool requirement that output structure be declared.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 26 | <=2025-11-25 | v2 |
Description states 'Input schema is dynamically generated from OpenAPI operation parameters' but provides no concrete guidance on what parameters the LLM should pass or what constraints apply. Generic description under 50 chars of actionable content.