Loading ToolBench
A Kubernetes-native Model Context Protocol server that integrates with the Refunc serverless platform to expose serverless functions as MCP tools
The refunc MCP server exposes a single tool 'dynamic_tools_from_triggers' that dynamically constructs tools from Kubernetes Trigger resources. While the concept is architecturally sound for a serverless platform, the tool definition itself has critical quality gaps. The tool name violates naming conventions (underscore_separated but noun-first, not verb-first; unclear action verb). The description is present but generic and does not explain WHEN to use this tool, what happens on invocation, or what the actual dynamic tools look like. The input schema is severely underdeveloped: it accepts a bare 'arguments' object with no type constraints, no property definitions, and additionalProperties=true, making it impossible for an LLM to understand what parameters are valid or required. There is no documented output schema. The tool performs a READ action (lists triggers and constructs tools dynamically) but offers no pagination, filtering, or structured result. Overall, this server would require significant schema documentation and description work before it could be confidently integrated into an agent system.
MCP server dynamically exposes tools based on Kubernetes Triggers with type 'mcp' that reference serverless functions. Each trigger configuration defines a tool with name, description, input schema, and optional structured output.
Tool name does not start with action verb. 'dynamic_tools_from_triggers' is noun-first and ambiguous about what action is performed. Should be 'list_mcp_triggers', 'get_available_tools', or similar verb-first name.
Input schema is dangerously permissive. The 'arguments' parameter has no type constraint (type='object' but no properties defined), no required fields, and additionalProperties=true. LLMs cannot infer what arguments a trigger expects. Schema must enumerate expected properties with types and descriptions.
Tool description (79 characters) is generic and does not specify WHEN to call this tool, what triggers are, what the output structure is, or what 'Kubernetes Triggers with type mcp' means in user terms. Must explain: what this discovers, why an agent would call it, and what to do with results.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 34 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 18 | - | v1 |
No documented output schema. The tool returns dynamically constructed tool definitions from Kubernetes Trigger resources, but there is no schema specifying the structure of returned tools (tool names, descriptions, schemas, outputs). LLMs cannot plan chaining or extract relevant fields.
Tool definitions are inferred from Kubernetes Trigger CRDs, not explicitly registered with full schemas in the MCP handler. The handler dynamically builds tool definitions at runtime based on Trigger resources.
No pagination, filtering, or result limiting documented. If many Triggers with type='mcp' exist, this tool could return hundreds of tool definitions, overwhelming context. No limit or next_cursor pattern implemented.
No error handling guidance. What happens if no triggers exist? If a trigger's schema is malformed? If Kubernetes API is unreachable? Tool must return actionable errors, not silent failures or stack traces.