A collection of MCP server examples demonstrating tool registration, SSE and stdio transports, SQLite database queries, and integration with LLMs (Ollama/OpenAI API) for tool selection and execution
This MCP server suffers from severe quality issues across all dimensions. Tool definitions lack proper structure, descriptions are minimal and non-functional, schemas are incomplete or absent, and there is no error handling guidance. Six tools are listed but only 4 unique implementations exist, with 2 exact duplicates (aoe appears twice identically; get_qh_price_from_sqlite appears twice). The codebase shows basic FastMCP usage but fails to meet production standards for LLM-agent integration. Descriptions are in Chinese and do not follow LLM-optimized patterns. Parameters lack proper type declarations in visible schemas. No parameter descriptions are provided beyond minimal labels.
定义了一个新的运算符aoe,根据aoe函数返回aoe运算符的结果
定义了一个新的运算符aoe,根据aoe函数返回aoe运算符的结果
获得指定期货品种的最新价格.
获得指定期货品种的最新价格.
获得指定城市的天气.
Gradio interface tool for counting letter occurrences in text (exposed via Gradio MCP server)
Duplicate tool definitions: 'aoe' defined identically twice (mcp_sse_client.py); 'get_qh_price_from_sqlite' defined identically twice (MCP-LLM/ and compare_5_LLM/). This creates ambiguity for LLMs and indicates poor repository organization.
Tool descriptions are non-functional for LLM selection. Descriptions like '定义了一个新的运算符aoe,根据aoe函数返回aoe运算符的结果' (in Chinese, translates to 'Defined a new operator aoe, returns aoe operator result according to aoe function') are circular and do not explain WHAT the tool does, WHEN to use it, or expected outputs. No parameter descriptions exist in the source code, only inline labels like 'first operand' and 'second operand' are visible in JSON.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Input schemas are incomplete and lack parameter descriptions. The 'aoe' tool shows {"a":{"type":"int","description":"first operand"},"b":{"type":"int","description":"second operand"}} in tabular form, but the source code @mcp.tool() def aoe(a: int, b: int) -> int: does NOT contain explicit parameter descriptions. If these descriptions are auto-generated by FastMCP, that is not visible in the code. For 'get_qh_price_from_sqlite', the source shows no type hints in the parameters visible in the schema output, only the function definition. Schema completeness is uncertain.
No output schemas documented. Tools return dict, int, or unspecified types, but there is no documentation of what fields, structure, or data the LLM should expect. For example, get_qh_price_from_sqlite returns 'dict: 包含指定期货品种的最新价格相关信息' (contains price-related info) but does not specify keys, types, or structure.
Tool naming is inconsistent and does not follow verb_noun conventions in all cases. 'aoe' is a custom operator name that does not convey action (should be 'calculate_aoe' or 'apply_aoe'). 'get_qh_price_from_sqlite' is awkwardly long and exposes implementation (sqlite) in the name. 'predict' is too generic, does not clarify what is being predicted. 'get_weather' is acceptable but lacks context (what data is returned beyond weather?)
No error handling or recovery guidance. Tools provide no documentation on failure modes, retryable vs. fatal errors, or what the LLM should do if a call fails. For example, get_qh_price_from_sqlite calls db.get_close_4_comm(qh_name) with no validation or error message if the commodity name is invalid.
Descriptions are extremely brief (10-50 characters) and do not explain prerequisites, return structure, or typical use cases. Baseline: 194 chars average, p10=34. These descriptions hover at p10 or below, providing minimal signal to the LLM.
No pagination support. If tools return lists (e.g., multiple futures prices or weather forecasts), there is no mention of page/offset, limit, or cursor parameters. Large results could overflow the context window.
Parameter validation is absent. No enum constraints, regex patterns, or range limits visible in tool definitions. For example, 'city' in get_weather accepts any string with no validation.
Repository organization is poor. Six tool definitions scattered across 5 different files (mcp_sse_server.py, mcp_stdio_server.py, MCP-LLM/mcp_server_sqlite.py, compare_5_LLM/mcp_server_sqlite.py, Gradio/mcp_sse_client_4_Gradio_server.py) with duplicates and inconsistent patterns. This makes maintenance difficult and violates composition principles.