FastMCP server with tools for AC company and model information, weather resources, and topic prompts
This server has severe definition quality issues. Tool definitions are duplicated (ping, companies, models appear twice), naming lacks clear action verbs, descriptions are minimal or generic, and parameter schemas lack proper type constraints. The `ping` tool provides no actionable value. The `companies` and `models` tools have shallow descriptions that don't explain when to use them or what data structure is returned. Parameter descriptions are present but minimal. Output schemas are not documented. No error handling guidance is provided. Security is weak, the server accepts a bearer token but exposes it in plaintext in the code. This server would not pass a production code review.
Returns AC companies for a specified country. Args: country (str): The country name or code (e.g., 'bd' or 'bangladesh'). Returns: list: A list of AC company names for the specified country.
Returns AC companies for a specified country. Args: country (str): The country name or code (e.g., 'bd' or 'bangladesh'). Returns: list: A list of AC company names for the specified country.
Hello world
Returns a list of models for selected companies
Returns a list of models for selected company
Check server is running or not
Check server is running or not
Tool duplication: ping, companies, and models are defined identically across multiple files (server.py, simple_server.py, client.py). This creates confusion about which implementation is canonical and violates single responsibility.
Naming lacks action verbs: 'companies', 'models', and 'hello' do not start with clear action verbs like get_, list_, fetch_, or search_. LLMs cannot reliably infer intent from noun-only names. 'get_companies' or 'list_ac_models' would be clearer.
ping tool provides no value: it returns a hardcoded status with no parameters. In production, ping is a debugging artifact. Remove it or replace with a proper health check tool that returns server metadata (version, capabilities).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameter descriptions are minimal: 'company_list' is described only as 'List of company names', but does not explain format constraints (length, encoding, supported companies), expected count, or what happens with invalid inputs.
No output schema documentation: Tools return structured data (lists, dicts) but do not formally document the response structure, field types, or constraints. LLMs cannot reliably parse undocumented output.
No error handling guidance: Tools do not document failure cases (invalid country code, empty company list) or recovery steps. An LLM receiving a generic error has no recovery path.
Security: Bearer token is generated in server.py and printed to stdout in plaintext (line 'print(f"Bearer token for testing: {token}")'). This token appears in production logs and could be intercepted. Never log secrets.
Inconsistent tool implementations: companies() in simple_server.py returns JSON string ('json.dumps()') while server.py returns plain list. This inconsistency forces clients to detect return type, adding fragility.
Missing resource context: Tools reference AC companies (Walton, Samsung, Gree) but do not document where these come from or how the dataset is kept current. No explanation of scope or limitations.
APIKeyMiddleware in simple_server.py is defined but commented out (line '# custom_middleware = [...]'). This suggests incomplete implementation and unclear security posture.