MCP server giving AI agents fast access to software architecture, dependencies, and impact analysis via pre-computed sgraph models
SGraph MCP Server demonstrates solid definition quality with consistent naming patterns, comprehensive parameter schemas, and actionable descriptions. All 14 tools follow verb_noun naming conventions (sgraph_get_*, sgraph_search_*, sgraph_analyze_*). Parameter descriptions are present and include type information. However, there are notable gaps: output schemas are not documented in the source code provided, error handling is generic ('Model not loaded', exception string wrapping), and some descriptions could be more specific about expected data structures and dependencies. The tools are well-organized across logical groups (model, navigation, search, analysis), and parameter constraints (enums, optional fields with defaults) are properly declared in Pydantic models. This positions the server solidly in the B/B+ range rather than A territory.
Analyze usage of External dependencies. Optionally restrict by scope_path (e.g., repository path).
Get transitive dependency chain from an element. Direction can be 'outgoing', 'incoming', or 'both'.
Get an element from a model by the path.
Get the incoming associations of single element. Does not include the associations of the children.
Get the outgoing associations of single element. Does not include the associations of the children.
Get all elements of a specific type. Optionally limit search to a scope path.
Output schemas not documented. The source code provides Pydantic input models but no corresponding response schemas. LLMs cannot plan subsequent operations without knowing what fields each tool returns. For example, sgraph_get_element likely returns element properties, but the agent must infer this.
Generic error handling. All tools catch exceptions and return {"error": "..."}. Errors lack actionable guidance. For example, 'Model not loaded' does not tell the LLM whether the model_id was wrong, the file was unreadable, or the model failed to parse. Compare to pattern: 'Model not found. Call sgraph_load_model(path) to load a model first, or check the model ID with sgraph_list_models().'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 75 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Get high-level module dependencies aggregated at directory level. This provides an architectural overview showing dependencies between modules/directories rather than individual functions/classes. Useful for understanding overall system structure, identifying tightly coupled modules, and architectural analysis.
Get hierarchical overview of the model structure up to specified depth.
Get information for multiple elements efficiently in a single request.
Get the root element from a model.
Get all dependencies within a subtree, categorized by internal, incoming, and outgoing.
Load a sgraph from a file and return the model id.
Search for elements by attribute values. attribute_filters is a dict of attribute_name -> expected_value.
Search for elements by name pattern (regex or glob). Optionally filter by element type and scope path.
Parameter descriptions lack specifics about data structure and dependencies. For example, sgraph_search_elements_by_attributes accepts 'attribute_filters' as an object, but the description does not clarify what keys/values are valid, whether keys are case-sensitive, or how to discover available attributes. Similarly, element_path is used across many tools but its format (delimiter, examples) is not documented.
No pagination or result limits documented. sgraph_search_elements_by_name, sgraph_get_elements_by_type, sgraph_search_elements_by_attributes, and sgraph_get_subtree_dependencies could potentially return large result sets. The descriptions do not mention limits, pagination, or when results are truncated. Without pagination, large model analyses could exhaust context windows.
No idempotency or dry-run support documented. Tools like sgraph_get_dependency_chain and analysis tools are read-only, but it's not clear which tools (if any) modify state. No confirm/dry-run pattern for destructive operations if any exist.