Loading ToolBench
An MCP server that helps generate PyMilvus code and translate Milvus API calls between different programming languages using vector-based document retrieval from Milvus
Three tools are defined with basic schemas and descriptions. However, naming conventions are weak (verb-noun pattern not consistently followed), descriptions are generic and lack actionable context, parameter descriptions are minimal, and there is no documented output schema. Tool names like 'milvus-pypmilvus-code-generate-helper' are overly long and unclear about what action is performed. The 'query' parameter descriptions lack specificity about expected format and constraints. No error handling guidance, no pagination support, and no output structure documented. The server implements HTTP+SSE transport but has significant definition quality gaps typical of community-grade tools.
Find related documents and code snippets in different programming languages for milvus code translation
Find related orm and pymilvus client code/documents to help converting orm code to pymilvus client (or vice versa)
Find related pymilvus code/documents to help generating code from user input in natural language
Weak verb-based naming. Tool names do not start with clear action verbs. 'milvus-pypmilvus-code-generate-helper' is a compound descriptor, not a verb-noun action. Should be renamed to 'search_pymilvus_examples' or 'find_code_snippets'. LLMs rely on tool names to infer intent before reading descriptions.
Generic, uninformative descriptions lack actionable context. Descriptions do not explain WHEN to use each tool vs the others, what prerequisites exist, or how results are structured. E.g., 'Find related pymilvus code/documents' tells the agent the tool searches, but not what query format it expects (list of API names? Natural language?) or what fields are returned. Descriptions should be 50 - 200 characters with explicit guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Parameter descriptions are minimal and lack format/constraint guidance. The 'query' parameter in all three tools has trivial descriptions ('User query for generating code', 'Milvus API names in list format'). No indication of expected format (JSON array? Comma-separated? Natural language?), length limits, or examples. 'source_language' and 'target_language' in the third tool have descriptions but no enum constraint or list of valid values, forcing the LLM to guess.
No output schema documented. Tool responses return TextContent with unstructured text, but the agent does not know what fields, structure, or metadata to expect. Production tools should document: Are results JSON? Markdown? Code blocks? Is there pagination? How many items returned? This blocks downstream composition and forces the LLM to parse freeform text.
No error handling guidance. If a query fails (e.g., no matching code found, invalid language pair), the tool returns unstructured text. No indication of error type, recovery steps, or whether retry is safe. LLMs need explicit error classification (retryable vs user-fixable vs fatal) to decide next steps.
No pagination or result limiting documented. If a code search returns hundreds of snippets, the response could blow the context window. Production tools should declare max result size, support pagination, and include a total_count or next_cursor in responses.
Enum constraints missing for language/type parameters. The third tool 'milvus-code-translate-helper' lists example languages in the description ('python', 'java', 'go', 'csharp', 'node', 'restful') but does not declare them as an enum in the schema. This violates the rule: replace examples with formal enum constraints. LLMs will hallucinate unsupported languages like 'rust' or 'cpp'.