Loading ToolBench
MCP Server for CodeFuse-CGM: Graph-Integrated Large Language Model for Repository-Level Software Engineering Tasks
The server defines 7 tools with basic MCP structure, but exhibits significant gaps in definition quality. Tool descriptions are present but generic (90-120 characters), lacking the LLM-optimized specificity required by production baselines (194 chars average, p10=34, p90=392). Input schemas are visible for all tools and include type definitions, but parameter descriptions are sparse or missing entirely. No output schemas are documented. Error handling is absent, no recovery guidance, classification, or actionable error messages. The server has no error reporting capability, no tool annotations (readOnlyHint/destructiveHint), and no structured output documentation. Tool naming follows verb-noun convention adequately, but composition issues exist: cgm_process_issue and cgm_extract_context lack clear differentiation, and there is no pagination support despite tools that likely return large datasets (cgm_analyze_repository, cgm_find_related_code). The tools operate on repository operations (READ_ONLY risk profile), but security documentation is minimal, no mention of permission gates, scope declarations, or audit trails.
Analyze repository structure and extract code context
Extract context information for external models
Find code relationships and dependencies in a repository
Get detailed content and analysis of specific files
Get the status of a CGM task
Check CGM server health status
Process a repository issue using CGM framework
No output schemas documented. Tools like cgm_analyze_repository, cgm_get_file_content, and cgm_find_related_code return complex structured data, but no schema is visible to specify field names, types, or whether results are paginated. LLMs cannot plan downstream tool chains or extract required fields without output documentation.
Parameter descriptions are missing or generic. 'repository_context' in cgm_process_issue has description 'Optional repository context information', no detail on structure, required fields, or valid values. LLMs cannot infer what to pass without explicit guidance.
No error handling or recovery guidance. Server defines READ_ONLY operations but provides no error classification (retryable vs fatal), no recovery hints (e.g. 'if repository not found, try search_repositories'), and no validation error messages. A failed cgm_process_issue call leaves the agent with no actionable next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No pagination support visible. cgm_analyze_repository and cgm_find_related_code operate on large code graphs but lack limit, offset, or cursor parameters. Results will either be capped at unknown defaults or explode the context window.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are marked READ_ONLY in metadata, but this is not exposed in the MCP tool definition via annotations. Modern MCP spec recommends explicit tool annotations for safety and composition clarity.
Ambiguous tool naming. cgm_process_issue and cgm_extract_context both operate on repositories and extract information, but their relationship is unclear. 'process' is vague, does it resolve the issue? Analyze it? The distinction should be explicit in names.
Parameter constraints under-specified. cgm_analyze_repository.analysis_scope has enum (minimal, focused, full), but what does 'focused' mean quantitatively? cgm_find_related_code.max_depth defaults to 2 but has no stated minimum or maximum. cgm_extract_context.max_context_tokens lacks range (is 1000 valid? 1M?). Without explicit ranges, LLMs pass invalid values.