Loading ToolBench
RayBridge exposes a single dynamic tool 'dynamic_extension_tools' that acts as a meta-gateway to Raycast extension tools. The tool has a vague name that violates verb_noun convention, a mediocre description lacking context on when to use it, and a schema that relies on additionalProperties:true for the 'input' parameter, deferring validation to runtime. The schema lacks output documentation entirely. The tool is marked IRREVERSIBLE but the description does not explain what makes it irreversible or what consequences the LLM should be aware of. No per-parameter descriptions beyond the bare minimum. No error handling guidance. The core pattern of 'pass tool_name + dynamic input' requires the LLM to reason about unknown Raycast extension signatures at runtime, this is a high-risk pattern that breaks tool composition and makes LLM planning opaque.
Dynamically discovers and exposes Raycast extension tools. Each extension becomes a tool where tool_name parameter specifies which specific tool to run, and input object contains tool-specific parameters.
Tool name 'dynamic_extension_tools' violates verb_noun convention and is vague. LLMs cannot infer the action from the name alone. Should be 'execute_raycast_tool' or similar action verb.
Input parameter 'input' uses additionalProperties:true with no schema, deferring all validation to runtime. LLM cannot know what fields are valid for a given tool_name. Breaks tool composition and increases hallucination risk.
No output schema documented. LLM cannot plan downstream steps or extract required fields (e.g., IDs, references) from results.
Tool marked IRREVERSIBLE but description does not explain consequences or when reversibility matters. LLM cannot reason about safety implications.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 29 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 13 | - | v1 |
Description (131 chars) lacks WHEN to use, WHAT it does in concrete terms, and how it differs from direct Raycast API calls. Too vague for LLM tool selection.
No parameter-level descriptions. 'tool_name' and 'input' parameters lack guidance on format, valid values, or examples of expected structure.
No error handling guidance. When a tool_name is invalid or input malformed, LLM receives no actionable recovery path.
Meta-gateway pattern (dynamic tool name + free-form input) breaks tool composition. Each Raycast extension tool should be registered as a separate MCP tool with explicit schemas.