A collection of MCP servers demonstrating tool integration with LangGraph. Includes Math server (stdio transport), Weather server (HTTP transport), and a local documentation search tool.
This MCP server collection exhibits significant quality gaps across the 5 tools. Tool names are verb-forward (add, multiply, get_weather, greet, search_docs), which is correct, but descriptions range from minimal to adequate. Most critically, the server lacks structured output schemas for responses, parameter descriptions are sparse or absent, and there is no error handling guidance. The tools are READ_ONLY operations (good), but the definitions do not meet production quality baselines. The search_docs tool description is in Chinese, mixing languages inappropriately for an LLM-facing interface. Parameter descriptions are present in the schema inspection but extremely terse (e.g., 'First number', 'Location name'). No tool declares output structure, and there is no documentation of how results are serialized. The math_server and weather_server examples show use of FastMCP, which is current, but the tool definitions themselves are skeletal.
Add two numbers
Get weather for location.
Greet a person by name
Multiply two numbers
在项目内微型知识库里检索。演示用,实际可接数据库/向量检索。
Tool descriptions are inadequate. 'Add two numbers', 'Multiply two numbers', 'Get weather for location.' are under 50 characters and lack context about when to use the tool vs. similar tools, what happens to state, or failure modes.
search_docs description is written in Chinese ('在项目内微型知识库里检索。演示用,实际可接数据库/向量检索。'), which violates the LLM-facing interface requirement. Descriptions must be in English for cross-region agent compatibility.
No output schemas documented. Tools return unstructured results (add returns an integer, multiply returns an integer, get_weather returns a free-form string, search_docs returns a free-form string). LLMs cannot plan downstream calls or extract structured data without knowing the response schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Parameter descriptions are terse. 'First number', 'Second number', 'Location name' do not explain constraints, formats, or why the parameter matters. For example, get_weather does not specify whether location accepts latitude/longitude, city names, postal codes, or all of the above.
No error handling or recovery guidance. If add or multiply receive non-integer input, or if get_weather receives an invalid location, there is no indication of what the error message will be or how the LLM should recover.
greet tool is registered in mcp/server.py but the file context shows only a decorator definition; no explicit MCP server registration visible.
Parameter naming could be more explicit. 'location' in get_weather does not clarify whether it accepts city names, coordinates, or both. Following the rubric baseline, parameters like user_name vs user_id would reduce LLM confusion. Here, 'location_name' would be more precise than 'location'.