ForgeMesh exposes 10 tools via Next.js API routes with HTTP transport. Tool definitions are inferred from route handlers rather than explicitly registered with MCP schemas. Most tools lack formal input/output schema documentation in the source. Descriptions are present but brief (10-80 chars), below the 50-200 char LLM-optimized baseline. Parameters have types but many lack descriptions. No error handling guidance, no output schema documentation, no tool annotations. This is a domain-specific commerce/scanning service, not a production-grade MCP server.

• Implement explicit MCP tool registration with JSON Schema input/output definitions. Each tool needs a ToolDefinition with name, description (50-200 chars), inputSchema (with type and description per param), and documented return type.
• Expand tool descriptions to 50-200 characters. Example: 'scan' should be 'Grade any x402 / MPP endpoint for payment readiness: checks if endpoint is reachable, validates x402 envelope format, detects MPP dual-stack support, and returns a letter grade (A-F) with findings.' (current: 27 chars).
• Document output schemas for all tools. For 'scan', define: { type: 'object', properties: { mode: { enum: ['single', 'service'] }, grade: { enum: ['A', 'B', 'C', 'F'] }, ... }, required: [...] }.
• Add error handling guidance to tool descriptions. Example: 'If scan fails with 'unreachable', the endpoint may be offline, try again in 30s. If 'invalid_url', check the domain format.'
• Move sensitive parameters (code, state, Signature, SigningCertURL) to server-side environment injection. Accept only user-facing identifiers (email, vin, url) as tool parameters.