Tool definitions are inferred from a validation script only. No actual tool schemas, descriptions, or parameter definitions are visible in the source code. The validate.sh script references tool names (edgaze_catalog, edgaze_search, edgaze_inspect, edgaze_run, edgaze_watch) but provides zero evidence of their implementation, input schemas, output schemas, or descriptions. Per HARD SCORING RULES, tools without visible definitions are capped at 50; since NO definitions are visible at all, the overall score reflects complete absence of evaluable definition quality.

• Provide the actual MCP server implementation code (handler registration, schema definitions, parameter validation). The validation script alone does not constitute a tool definition.
• Add JSON Schema definitions for each tool's input parameters with type, description, enum constraints, and min/max bounds. Example: edgaze_search should declare query (string, required), limit (integer, 1-100, default 20), offset (integer, default 0).
• Write 50-200 character descriptions for each tool explaining WHAT it does, WHEN to use it, and WHAT it returns. Example: 'edgaze_search: Search the Edgaze catalog by keyword. Returns matching items with IDs, names, and descriptions. Use this to find resources before calling edgaze_inspect.'
• Add descriptions to every input parameter. Do not assume LLMs infer meaning from names alone. Example: 'query (string): The search term. Supports partial matches and wildcards (*).'
• Implement error handling with recovery guidance. Return structured errors like '{"error": "not_found", "message": "Item not found. Try search_catalog() with a broader query."}' instead of raw HTTP status codes.