Loading ToolBench
Enterprise MCP server bridging Claude 4.5 Sonnet with GLM-4.6 for advanced software architecture consulting
Five tools are explicitly registered with complete JSON Schema input definitions and descriptions. However, the server exhibits significant issues with naming conventions, parameter documentation specificity, and lack of output schema documentation. Naming relies on imperative/query verbs (consult_, analyze_, design_, review_, advanced_) rather than action-oriented verb_noun patterns (get_, create_, update_). Parameter descriptions are minimal and lack detail about format constraints, ranges, or validation rules. No output schemas are documented, forcing LLMs to guess what fields they'll receive. Error handling is basic (try/catch with generic messages) and lacks recovery guidance. Overall quality is below the baseline for production-grade tools.
Consult GLM-4.6 for advanced mathematical, algorithmic, and scientific reasoning tasks. Delivers world-class innovative solutions with rigorous methodology, optimal algorithms, and enterprise-grade quality. Use for: complex algorithms, mathematical proofs, performance optimization, advanced data structures, computational problems, scientific analysis. Response optimized for Claude 4.5 Sonnet with XML structure.
Analyze code from an architectural perspective using GLM-4.6. Evaluates design patterns, SOLID principles, scalability, security implications, and provides improvement recommendations.
Consult GLM-4.6 for expert software architecture guidance, system design patterns, scalability strategies, and technical decision-making. Use this for high-level architectural questions requiring deep technical expertise.
Design a complete system architecture based on requirements using GLM-4.6. Provides component breakdown, data flow patterns, technology recommendations, and deployment strategies.
Review and evaluate a technical decision using GLM-4.6 architectural expertise. Assesses impact, trade-offs, alternatives, risks, and provides recommendations.
Tool names do not follow verb_noun pattern (get_, create_, update_, etc.). 'consult_architecture', 'analyze_code_architecture', 'design_system_architecture', 'review_technical_decision', and 'advanced_reasoning' are imperative/query forms that obscure the actual action. LLMs struggle to infer intent and tool selection becomes ambiguous.
No output schemas documented for any tool. All tools return plain text via {type: 'text', text: response}. LLMs cannot plan downstream operations, cannot extract structured data, and must parse unstructured responses. This violates the documented return type requirement.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Parameter descriptions lack specificity about format, constraints, and validation rules. 'The architectural question or problem requiring expert consultation' is vague. Should specify: max length, required format, examples of good vs bad queries. 'context' parameter is described as optional but the LLM needs to know what kinds of context are useful (system design constraints, scalability targets, etc.).
Error handling is minimal and non-actionable. The catch block returns a generic error message with no recovery guidance. Per pattern:recovery-guide, errors should tell the LLM what to do next. Example: if the GLM API times out, the error should suggest 'API timeout, try again with a simpler query or break the task into smaller parts.'
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). All five tools are read-only (they consult an external LLM and return advice), but this is not formally declared via toolAnnotations. LLMs cannot determine which tools are safe to call multiple times or whether a tool modifies state.
'code' parameter in analyze_code_architecture lacks format guidance. No specification of max length, character restrictions, supported languages (claims 'typescript, python, go, java' in description but has no enum constraint). LLMs may pass binary or excessively large payloads.
Three tools accept 'context' as an optional parameter with minimal guidance. Parameter descriptions should explain: What kind of context is most valuable? (e.g., 'current architecture constraints', 'business requirements', 'performance targets'). Without examples, LLMs waste tokens on redundant context or skip useful information.