This server exhibits critical definition quality gaps across all four tools. All tools have empty input schemas ({}), no parameter descriptions, minimal tool descriptions (15-17 chars), and no documented output schemas. The tools are hardcoded to return literal strings with no context for when/why an LLM should call them. Per the rubric hard rules: tools with NO input schema must score 0 on schema; descriptions under 20 chars must score 0-20 on description. All four tools violate both rules. The naming convention (get_* verbs) is acceptable, but without schemas, descriptions, and error handling, the tools are barely usable by an agent.

• Expand all tool descriptions to 50-200 characters. Include: What does this tool fetch? When should the LLM call it? What does the returned code represent? Example: 'get_companycode' → 'Retrieve the unique company identifier code. Use this to populate company-level API requests or match records against company databases. Returns a numeric code prefixed with #.'
• Define formal input schemas in the FastMCP decorator or function signature. Even if no parameters are required, declare this explicitly: 'Input: {} (no parameters required)' with description 'This tool accepts no arguments.' This signals to LLMs that the tool is stateless and can be called freely.
• Document output schemas for each tool. Example for get_companycode: 'Returns: {type: string, description: "Company code in format #<number>, e.g., #123456. Use this code in company_id fields for API calls."}'
• Rename tools to be more specific. If the codes are for different business entities (company, department, product line, etc.), use clearer names: 'get_company_identifier', 'get_department_code', 'get_product_code', 'get_mcp_registration_code'. Avoid ambiguous abbreviations like 'ABC' and 'XYZ'.
• Add error handling. If a code lookup or generation fails (e.g., due to database unavailability), return a structured error response: '{"error": "code_generation_failed", "message": "Unable to fetch company code. Database is unavailable. Retry in 30 seconds.", "retryable": true}' instead of raising an exception.
• Consider whether these tools need parameters. If different users or contexts need different codes, add parameters like 'department_id' or 'context'. If the code is always the same, reconsider whether a tool is necessary, this could be configuration or a resource instead.