Loading ToolBench
A PowerShell module for implementing MCP (Model Context Protocol) servers with tools, resources, and prompts support
FastMCP-PowerShell exhibits major definition quality gaps. The server exposes 6 tools with basic parameter schemas, but critical issues undermine usability: (1) Tool names violate verb-first conventions, 'New-Tool', 'New-FastMCPServer', 'New-Resource', 'New-Prompt', 'Get-FastMCPContext', 'New-Image' follow PowerShell naming (New-*/Get-*) rather than agent-friendly patterns like 'create_tool', 'create_server'. LLMs struggle to parse PowerShell CapWords naming and infer intent from non-standard verb forms. (2) No output schemas are documented anywhere, callers cannot predict what these tools return or plan downstream chaining. (3) Parameter descriptions are minimal and generic ('The name of the tool', 'The endpoint URL for the server'). Descriptions lack actionable detail about format, constraints, or dependencies. (4) No error handling guidance, what happens on invalid input? What should the agent do on failure? (5) No examples of actual tool usage or integration. The test file shows unit tests but no live invocation patterns. (6) The server's transport mechanism is UNKNOWN and source code is truncated, preventing verification of MCP protocol compliance.
Creates a new FastMCP context object from a server with tools, resources and prompts collections
Creates a new FastMCP server object with endpoint, API key, provider, model, options and timeout configuration
Creates an image object from a file path with optional description, name, and tags
Creates a prompt object with name, description, render script and optional tags
Creates a resource object with name, description, content, type and optional tags
Creates a tool object for FastMCP with name, description, function, optional parameters and tags
Tool names do not follow verb-noun LLM conventions. PowerShell CapWords naming (New-Tool, Get-FastMCPContext) is incompatible with standard agent tool discovery. LLMs expect lowercase verb_noun patterns (create_tool, get_context) to parse intent from the name alone.
No output schemas documented for any tool. Callers cannot predict return types, fields, or structure. This breaks downstream tool chaining and forces agents to guess what data is available.
Parameter descriptions are generic and lack actionable detail. 'The name of the tool' does not specify length limits, character restrictions, or naming conventions. LLMs need explicit constraints (e.g., 'alphanumeric, 1-64 chars') to generate valid input.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | <=2025-11-25 | v2 |
No error handling guidance. Tools provide no recovery hints when inputs are invalid or operations fail. Error responses must tell the LLM what to do next (e.g., 'Invalid endpoint format. Expected https://...'; try again with a valid URL').
Parameter 'Function' (New-Tool) and 'RenderScript' (New-Prompt) accept scriptblock type, which is opaque and unvalidated. No documentation of expected signature, arguments, or return type. LLMs cannot reason about these parameters.
Parameter 'Provider' (New-FastMCPServer) defaults to 'OpenAI' but no enum or list of valid values is documented. LLMs will hallucinate unsupported providers (e.g., 'Claude', 'Gemini'). Use an explicit enum to constrain options.
Parameter 'ApiKey' (New-FastMCPServer) appears to be a secret credential. Tool parameters must never expose credentials. Use server-side secret injection via environment variables or configuration instead.
No documentation of which parameters are mutually exclusive. 'Endpoint' and 'ApiKey' likely work together; missing fields should fail fast with guidance (e.g., 'Endpoint and ApiKey are required together').