Multi-language MCP server implementations (TypeScript, Python, Go, Rust, Java, C#, Swift) exposing periodic table element lookup tools via StreamableHTTP transport
This polyglot MCP server (Go, Java implementations) exposes 2 tools for periodic table element lookup. Both tools have reasonable names (verb-based: get_element, get_element_by_position) and documented input schemas with type definitions. However, there are critical gaps: tool descriptions are present but very short (Chinese language, ~30-40 characters), parameter descriptions lack detail about constraints and formats, output schemas are not documented, and no error handling guidance is visible. The implementation appears functional but lacks the completeness expected of production tools. Input schemas are visible and properly typed (string for name, number for position), which prevents a lower score, but missing output documentation and sparse parameter guidance pull the overall score into the 'Fair' range.
根据元素名称获取元素周期表元素信息
根据元素在周期表中的位置(原子序数)查询元素信息
Tool descriptions are too short (25-30 chars) and lack context about when/why to use the tool or what it returns. Current: '根据元素名称获取元素周期表元素信息' (Chinese, ~30 chars). Pattern expects 50-200 chars with clear WHAT/WHEN/OUTPUT guidance.
Parameter descriptions are minimal or absent. 'name' parameter has generic description 'Element Chinese name (e.g. 氢, 氦)' but lacks constraints on valid values, length, or format. 'position' parameter description '元素的原子序数,范围从1到118' is in Chinese; should clarify if this is the ONLY valid lookup method and what happens if position is out of range.
Output schemas are not documented. Neither tool shows what fields are returned (e.g. element name, atomic number, atomic mass, electron configuration, etc.). LLMs cannot plan downstream operations or extract required data without knowing the response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
No error handling guidance. What happens if an invalid element name is passed to get_element? If position is 0 or 999 in get_element_by_position? Tools should return actionable error messages (e.g. 'Invalid element name. Valid range: 1-118. Try search_elements() for partial matches.') instead of generic errors.
Tool descriptions and parameter descriptions are in Chinese. While this may be intentional for a Chinese-language demo, production tools serving global LLMs should use English descriptions. LLM training predominantly uses English, and non-English descriptions reduce reliability.
No idempotency documentation. Both tools are read-only (marked READ_ONLY risk), which is good, but descriptions do not explicitly state this. LLMs should not need to infer safety; state clearly: 'Read-only. Safe to call multiple times.'