This MCP server is a Next.js-based builder tool for creating MCP servers, not a production MCP server itself. The three tools (tools/call, resources/read, prompts/get) are meta-tools for testing user-defined MCP projects. (2) Descriptions are present but generic and lack actionable context for LLM tool selection. (3) Input schemas exist (name/arguments structure) but lack depth, no enums, constraints, or detailed parameter descriptions. (4) No output schemas documented. (5) No error handling guidance. (6) The tools themselves are READ_ONLY introspection utilities, not domain-specific production tools. The codebase shows a builder UI (ToolsTab.tsx) for creating MCP servers with support for custom code, HTTP, and database handlers, but the MCP server exposure of these capabilities is minimal and poorly specified.

• Explicitly register tools in an MCP server handler with full schema objects. Use the MCP SDK to declare tool names, descriptions, and input/output schemas rather than inferring them from route signatures.
• Document output schemas for all three tools. Example: tools/call should return {success: boolean, result: any, error?: string}; resources/read should return {uri: string, content: string, mimeType?: string}; prompts/get should return {name: string, content: string, arguments: object}.
• Expand tool descriptions from ~40 chars to 100-150 chars. Answer: What does this tool do? When would an LLM call it? What are typical use cases? Example: 'tools/call: Invokes a previously registered tool in the MCP project with supplied arguments. Use this to test tool behavior, validate implementations, or execute domain-specific actions. Returns the tool result or error message.'
• For the 'arguments' parameter, provide a schema fragment explaining its structure: 'Arguments object matching the target tool\'s inputSchema. Key-value pairs must match declared parameter names and types. Example: {user_id: "123", include_archived: true}'.
• For the 'name' parameter in tools/call and prompts/get, add discovery hints: 'The name of the tool to invoke (e.g., send_email, get_user). Call tools/list to see available tool names.' Or implement a tools/list tool that returns {tools: [{name, description}]} for agent discovery.
• Add error handling guidance in descriptions. Example for tools/call: 'If the tool name does not exist, returns {success: false, error: "Tool \'invalid_tool\' not found. Available: [send_email, get_user]"}. If arguments are invalid, returns {success: false, error: "Invalid arguments: expected user_id (string), got undefined."}.'

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained