Server has 4 tools with basic verb-noun naming (list_, get_). However, critical gaps undermine quality: (1) Input schemas are present but lack proper JSON Schema structure with explicit type declarations in the source code shown. (2) Parameter descriptions are minimal or absent, 'org_name' has a description, but many lack detail on format/constraints. (3) Output schemas are not documented, tools return dicts/strings without declared field structure. (4) Error handling is minimal: list_org_repos returns ['Error fetching data'] (a string in a list, not structured); get_repo_stats returns a dict with 'error' key but no guidance on recovery. (5) No tool annotations (readOnlyHint, etc.). (6) Descriptions are present but generic (10-50 chars), below the 50-200 char baseline for LLM optimization. Per-tool analysis: list_org_repos and get_repo_stats have basic descriptions but no output schema docs; get_latest_block and get_previous_block have trivial descriptions (under 20 chars when stripped of context) and no input validation despite empty input objects.

• Document output schemas for all tools. Example for get_repo_stats: 'Returns {stars: int, forks: int, watchers: int, message: string}'. Include field types and meanings.
• Replace generic error responses with actionable guidance. Instead of ['Error fetching data'], return {error: 'Organization not found. Verify the org name is correct and public.', retryable: false}.
• Expand descriptions to 50-200 chars. Example: 'get_latest_block: Fetches the current block number from Metis mainnet. Use this to check the latest state of the blockchain. Returns a dict with the block number and a human-readable message.'
• Add tool annotations to the FastMCP decorator. Mark all tools with readOnlyHint=true since they are read-only. Example: @mcp.tool(readOnlyHint=True).
• Add parameter constraints to descriptions. Example for org_name: 'The GitHub organization name (2-39 alphanumeric characters and hyphens, e.g. "python" or "aws")'. Validate input and return clear error messages.