Understand-Anything MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation5/5
Each tool targets a distinct aspect of the knowledge graph (entry points, stats, node search/detail/source, relationships, layers, domains, flows, impact, paths, hierarchy, file path). The two stats tools are clearly separated by intended audience (human-readable vs machine-readable), so there is no meaningful overlap.
Naming Consistency5/5
All tool names follow an imperative verb_noun pattern (find_, get_, list_, query_, trace_, search_). The consistent use of snake_case and a predictable verb prefix makes the toolset easy to navigate.
Tool Count4/5
18 tools is slightly above the ideal range, but each tool serves a distinct query need for a code understanding server. The count is justifiable given the breadth of analysis features, though it borders on heavy.
Completeness5/5
The toolset covers the full lifecycle of codebase exploration: listing projects, searching and inspecting nodes, retrieving source, tracing relationships and call chains, analyzing impact, exploring layers and business domains, and getting guided tours. No obvious gaps for the stated purpose.
Average 4.2/5 across 18 of 18 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It states this is a read operation that fetches data from domain-graph.json and returns a list of domains with flows, entity counts, and summaries, which covers basic behavior. However, it doesn't mention potential performance implications, error behavior for unknown projects, or any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using one sentence for purpose and a simple Args/Returns breakdown for the rest. There is no redundant text, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the core purpose, input, and output, making the tool understandable at a glance. However, it lacks usage context and enriched parameter detail, and with an output schema already available, the returns section adds little. Overall, it's sufficient for a simple overview tool but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the single parameter. It only provides 'project: Project name,' which adds minimal semantic meaning beyond the schema's property name. It doesn't clarify what a project name refers to, whether it must match a specific format, or what happens if it's null.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving a summary of all business domains and their flows, specifying the source file and output contents. It distinguishes itself from detail-oriented siblings by using 'overview' and 'all domains,' though it doesn't explicitly recommend against using detail tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus get_domain_detail or get_domain_flow_detail. The description does not include use cases, exclusions, or alternative tool mentions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal an important behavior: the freshness analysis uses git diff against the commit when the graph was last analyzed, which implies a potentially expensive operation. It also lists what statistics are returned. However, it does not mention whether the tool is read-only, potential side effects, or any computational cost or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear Args and Returns sections, and it front-loads the core purpose in the first sentence. It is a bit verbose with the freshness analysis explanation, but every sentence adds value and there is no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one optional parameter and an output schema exists, so the description covers the basic return contents. However, it lacks guidance on how this tool relates to siblings (especially get_graph_metadata) and does not address potential costs or operational nuances of the git diff-based freshness check. This leaves some context gaps for an agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the 'project' parameter (0% coverage), so the description's parameter explanation is essential. The description clearly explains that 'project' is a project name and that leaving it empty is valid when only one project is loaded, which adds meaningful semantics beyond the schema's bare type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('project's knowledge graph'), and adds scope details (comprehensive statistics, freshness analysis). However, it does not distinguish itself from the sibling tool 'get_graph_metadata', which likely has overlapping functionality, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like get_graph_metadata or query_nodes. It implies usage for statistics gathering but provides no exclusions, prerequisites, or comparative context. This leaves the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the core behavior (finding uncalled functions) and the return structure (list with layer and summary), but it does not mention whether it's read-only, any side effects, or performance implications. Without annotations, this is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, then clear Args/Returns sections. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description fully explains what it returns. It doesn't define 'layer' or specify sorting/limits, but these are likely domain-specific and not critical for a basic query tool. It is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description in the schema property), but the description provides 'project: Project name' which clarifies the parameter's meaning. Since this is the only parameter and its purpose is straightforward, the semantic addition is minimal but sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find functions that are NOT called by any other function', which is a specific verb+resource+scope. It distinguishes this tool from siblings like trace_call_chain or find_impact by focusing on uncalled functions as potential entry points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when seeking entry points) but does not explicitly compare to alternatives or state when not to use it. It lacks clear exclusionary or alternative guidance, so it earns a 3 for implied usage rather than explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return type ('Inheritance tree showing parent and child classes with relation types') but does not mention error behavior, performance implications, or any side effects. This is acceptable for a simple read-only query but lacks richer context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line purpose, a concise parameter list, and a return value note. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, parameters, and return value. It lacks usage guidance and edge-case behavior, but the presence of an output schema reduces the need to explain return details in prose, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by explaining each parameter in the Args section, including direction values, max_depth limits, and project name. This adds meaning beyond the schema, though the 'project' parameter could be described more fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Show the inheritance hierarchy for a class (extends/implements tree).' This distinguishes it from sibling tools like get_relationships or get_node_detail, which are more generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description only explains what it does, leaving the agent to infer its use case from the purpose and parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the effect of layer_name (empty vs specified) and the return type (layer listing or nodes), but does not disclose behavior when project is empty or mention prerequisites, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with clear Args and Returns sections, no redundant prose, and the primary purpose is front-loaded. Every line contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two optional parameters and an output schema exists, but the description misses important edge-case behavior: what happens if project is left empty, and how project and layer_name interact (e.g., listing layers for a specific project). These gaps prevent full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. layer_name is well described with a conditional behavior ('Leave empty to list all layers'), but project is only described as 'Project name,' which adds little beyond the schema title and does not clarify optionality or interaction with layer_name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List architectural layers, or get nodes belonging to a specific layer,' providing a specific verb and resource. This distinguishes it from sibling tools like query_nodes and get_graph_metadata by focusing on layer-level operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: listing all layers when layer_name is empty, or inspecting nodes in a specific layer. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the traversal direction and edge types, which is useful, but it does not mention how cycles are handled, whether the input node itself is included in results, or performance implications for deep traversals. This is partially transparent but leaves several corner cases unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a brief algorithm note, and a clear Args/Returns section. Every sentence provides relevant information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, algorithm, parameters, and return shape, and an output schema exists to detail exact return values. Minor gaps such as cycle handling, self-inclusion, and explicit when-to-use guidance prevent a perfect score, but overall it is complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's Args section is essential and does add meaningful context. It explains node_id, max_depth (including default and max), and project by name. However, project is only described as 'Project name' without elaborating on its filtering role, and max_depth's behavior at bounds is unspecified, so it is not fully thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: blast radius analysis to find all nodes affected by a change. It specifies the traversal semantics (following incoming imports, calls, extends, and implements edges in reverse), which distinguishes it from sibling tools like trace_call_chain or find_path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for impact analysis via 'Blast radius analysis', but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No direct comparison to sibling tools is given, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: 'Uses undirected BFS — traverses both outgoing and incoming edges.' This is non-obvious and directly affects results. With no annotations, the description carries the burden, and this detail plus the return description provides meaningful transparency, though it doesn't mention edge cases like no-path scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose, algorithm, usage, parameters, and return value. It is front-loaded with the main verb and every sentence contributes information. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, algorithm, parameters, and return format. Since an output schema exists, not detailing the return structure is acceptable. However, it omits behavior when no path is found and under-explains the project param, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists each parameter with some meaning: source_id as 'Starting node ID', target_id as 'Destination node ID', max_depth with default and max, and project as 'Project name'. The project description is minimal but present, giving some semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find the shortest path between two nodes in the knowledge graph', specifying the verb and resource. It doesn't explicitly differentiate from sibling tools like find_impact, but the purpose is specific enough that it likely won't be confused with other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The line 'Useful for understanding how two components are connected' provides clear context for when to use the tool. It does not mention explicit alternatives or exclusions, but the context is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It specifies substring matching, case-insensitive behavior, sorting by file path, and result limits (max 50), which are valuable beyond the schema. It does not explicitly note that the operation is read-only, but the search nature implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet complete: a clear purpose sentence, a usage hint, and organized Args/Returns sections. Each sentence adds value, and the structure makes parameters and return value easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter tool with an output schema, the description covers all parameters, return type, and sorting behavior. It could also mention behavior for invalid inputs or empty results, but the description is otherwise comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and types with no descriptions (0% coverage). The description compensates by explaining path_pattern with examples, node_type allowed values, limit constraints (default 30, max 50), and project semantics, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds nodes by file path pattern using substring matching, providing a specific verb and resource. It gives usage context for locating nodes in packages/modules/directories, but it does not explicitly distinguish from sibling search tools like query_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('finding all nodes in a package, module, or directory') and adds matching semantics, but it lacks explicit guidance on when not to use this tool or references to alternative sibling tools for other search criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return content ('Complete node details including path, layer, tags, complexity') and implies a read-only operation via 'Get'. However, it does not mention error behavior, authentication, or rate limits, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args and Returns sections. The opening sentence states the purpose, the example adds immediate clarity, and every line contributes useful information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (2 parameters, output schema present), and the description covers the essential semantics, return content, and ID-finding workflow. It is complete enough for an agent to invoke correctly, though it could mention error cases or multi-project disambiguation more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description fully compensates: node_id is explained with a concrete example ('upstream:function:src/auth/login.ts::loginUser') and pointer to query_nodes, while project is clarified with a conditional rule. This adds significant meaning beyond the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full details of a specific node by its ID,' which identifies the action (get), resource (node), and scope (specific node). This distinguishes it from siblings like query_nodes (search) and get_node_source (source code retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it instructs to 'Use query_nodes to find IDs' and explains the project parameter's conditionality ('Leave empty if only one project'). It does not explicitly exclude alternatives, but it gives actionable when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does well by explaining direction semantics (e.g., 'out' means this node calls/imports others) and enumerating valid relation_filter values, which adds behavioral context beyond the bare schema. Yet it does not explicitly state that this returns only direct/first-degree relationships, nor mention any limits like pagination, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently organized: a one-sentence summary, then a clear argument list with inline documentation, and a return format specification. There is no filler or repetition. All content is purposeful and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, 1 required, no annotations), the description covers parameters, direction semantics, and return format. It omits edge-case behavior such as invalid node IDs or empty results, and does not explicitly state this is a read-only operation, but the 'Get' wording implies it. Overall, it is sufficient for an agent to use correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does: every parameter (node_id, direction, relation_filter, project) is documented with its meaning and allowed values. Direction and relation_filter get particularly thorough explanation, covering all enum-like options. This far exceeds what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all nodes connected to a given node, with relationship types.' The verb 'get' is specific, the resource (connected nodes with relationship types) is explicit, and the scope (direct relationships) is implied by the direction parameter semantics. This distinguishes it from sibling tools like find_path or trace_call_chain, which explore larger structures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool is appropriate (inspecting a node's direct connections) through its parameter explanations. However, it does not explicitly state when not to use it or mention alternative tools, such as find_path for paths or trace_call_chain for call chains. This meets the 'clear context' bar but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that no parameters are required and that it returns node/edge counts and domain info, implying a safe, read-only list operation. However, it does not disclose any potential caveats like pagination, data freshness, or whether projects can be empty, so it only meets the basic standard.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each serving a clear purpose: describing the function, noting the lack of parameters, and stating the return value. There is no wasted wording or redundancy, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an existing output schema, the description is complete. It tells the agent when to call it (first), what it does, and what it returns, which is sufficient to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description explicitly says 'No parameters required.' With no parameters to explain, the baseline for a 0-parameter schema is 4, and the description appropriately adds no unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'List all registered projects with basic statistics,' clearly stating a specific action and resource. It also notes that this should be called first, which distinguishes it from sibling tools by positioning it as the entry point to discover projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to 'Call this first to see available projects,' indicating this is the initial contact point. It implies that the agent should use this before exploring graph-specific tools, but it does not name alternatives or exclusion criteria, so it lacks the explicit when-not-to-use guidance for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses useful behavioral details: tour stops are ordered sequences linking to knowledge graph nodes, stop_index is 1-based, and leaving it empty lists all stops while specifying expands with full node details. It also states the return format, providing good transparency for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: a two-sentence intro followed by structured Args and Returns sections. Every sentence adds value—defining the tour concept, explaining the parameter behaviors, and outlining return types. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two optional parameters, and an output schema exists, so return values are covered. The description explains the core behavior well. However, it lacks any mention of prerequisites, project selection context, or edge cases, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the two parameters (0% coverage). The description compensates well by explaining stop_index as a 1-based number with a specific behavior when empty, and project as the project name. This adds meaning beyond the schema, though it could clarify what happens when project is omitted (default null).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a guided project tour—a curated walkthrough of important codebase parts. The verb 'get' and resource 'tour' are specific, and this distinguishes it from sibling graph/query tools like query_nodes or get_domain_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when you want a high-level curated overview or a detailed stop. It explains the stop_index behavior (empty to list all, specify to expand), but does not explicitly mention alternatives or exclusion conditions among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that traversal is BFS-based, that class/file nodes are automatically resolved to functions, and that output is an indented text tree. It also documents max_depth limits. While it doesn't discuss auth or destructive behavior (unnecessary for a read-only trace), it provides substantive algorithmic details beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief purpose statement, followed by Args and Returns sections. Every sentence adds value—there is no fluff. The front-loaded purpose sentence immediately communicates the core function, and the parameter details are formatted for easy parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (graph traversal with special node-type handling), the description is complete. It covers the algorithm, input parameters with defaults, special cases for class/file nodes, and the return format. Despite an output schema existing, the description's note that the result is 'indented text' is sufficient for an agent to understand the outcome. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must fully compensate. It does: an Args section explains each parameter (start_node_id, max_depth, project) with types, defaults, and constraints (e.g., max_depth default 3, max 10). This greatly exceeds the bare schema definitions, providing clear semantics for all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Trace the function call chain starting from a node (BFS on 'calls' edges).' It uses a specific verb ('trace') and resource ('function call chain'), and specifies the algorithm (BFS on calls edges). This distinguishes it from sibling tools like find_path or find_impact, which focus on different types of graph traversal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining how it handles different node types and parameters, but it does not explicitly state when to use this tool versus alternatives. There are no direct comparisons or exclusions (e.g., 'for impact analysis use find_impact'). Guidance is implied but not definitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It discloses that fuzzy matching is supported for domain_name and states the return structure ('Full domain details with entities, business rules, flows and their steps'), giving the agent a clear expectation of the read-only nature and output. It does not mention side effects or edge cases, but for a simple getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized with an opening summary, an Args section, and a Returns section. Every sentence adds value: the summary explains what the tool does, the args explain parameters with examples, and the returns sets expectations. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple 2-parameter interface, an output schema, and a description that covers both the purpose and return payload, the description is complete for the agent's invocation needs. The project parameter's optionality is implied by the schema default, and the description's examples help disambiguate domain_name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only titles (0% description coverage), but the description compensates fully. It explains domain_name with concrete examples ('authentication', 'transfer', 'payroll'), notes fuzzy matching, and clarifies project as 'Project name.' This adds meaning far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get detailed info about a specific business domain' and enumerates the included content: 'entities, rules, flows, steps.' This is a specific verb+resource+scope, and the enumeration clearly distinguishes it from siblings like get_domain_overview or get_domain_flow_detail by emphasizing 'detailed' and listing all components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a full domain model with fuzzy matching on the domain name. It does not explicitly mention alternatives or when-not-to-use, but the context ('detailed info') and the enumerated contents provide clear guidance on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of transparency. It discloses node-type-specific extraction behavior, truncation for large files, inclusion of line numbers, and the effect of max_lines on whole-file reads. This is strong, but it does not mention failure modes or whether the operation is strictly read-only (though implied by 'Get'), so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an opening sentence, a short behavioral breakdown, labeled arguments, and a returns note. Every sentence earns its place, and the format is easy to scan without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no annotations, no schema descriptions, and no output schema. The description covers purpose, behavior by node type, parameter semantics, and return format. It gives the agent enough context to correctly invoke the tool without needing additional lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions, so the description fully compensates. It explains node_id as an ID to be found via query_nodes, max_lines as a limit for whole-file reads that does not affect function/class extraction, and project as the project name. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the actual source code for a knowledge graph node.' It further distinguishes behavior for function/class vs file/config nodes, which clearly separates it from sibling tools like get_node_detail or query_nodes that serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: use this tool when you need the actual source code for a node. The description also tells the agent to use query_nodes to find IDs, which is a helpful cross-reference. However, it does not explicitly mention when to avoid this tool or name alternative tools for metadata-only needs, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries behavioral disclosure. It reveals weighted scoring, exact-match bonuses, and pagination support. It stops short of detailing ordering or empty-result behavior, but provides substantial insight into the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured, with a one-sentence summary, scoring details, and a bulleted argument list. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which could reduce the need to explain returns), the description still lists the return fields. It covers query syntax, filtering, pagination, and project scoping, making it self-sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining each parameter with examples and defaults. It adds meaning beyond the schema types by describing 'node_type' filtering, pagination, and project context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action ('Search for nodes') and the resource ('knowledge graph'), with a clear keyword-based scope. It distinguishes itself from siblings like search_by_file_path by mentioning weighted fuzzy matching and scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the kind of search (keyword-based, fuzzy matching) and how scoring works, which implies when to use it. However, it does not explicitly mention alternatives or exclusion cases, so it lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that fuzzy matching is supported for flow_name, describes the return content (entry point, ordered steps, step summaries, cross-referenced code nodes), and implies a read-only, non-destructive operation. It could add more about pagination or error behavior, but for a query tool it provides solid context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized: a one-sentence purpose, a usage section with sibling differentiation, and clearly labeled Args/Returns sections. Every sentence contributes useful information with no redundancy, and the most important info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, an output schema, and moderate complexity, the description is complete. It explains what the tool returns, how to get broader context via siblings, and the semantics of the key parameter. The presence of an output schema reduces the need to detail return structure, and the description covers everything else needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description adds meaningful value for flow_name through examples ('SAGA Xử lý Lương', 'init payroll') and explicitly notes fuzzy matching. It also explains project as simply 'Project name', which is minimal, but the main parameter is well covered. This largely compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb phrase 'Deep-dive into a specific business flow' and precisely lists what is returned: entry point, ordered steps, and linked code nodes. It explicitly contrasts with sibling tools get_domain_overview and get_domain_detail, making its unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It directly states when to use the tool ('Use this for detailed understanding of a single flow's implementation') and names alternatives for broader overviews ('For an overview of all domains/flows, use get_domain_overview or get_domain_detail'). This gives explicit when and when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output format (JSON string with ok/error structure), including error code/message/remediation, and explains project handling. The 'snapshot' wording implies a read-only operation, though it does not explicitly state 'read-only' or side-effect-free. This is a minor gap but the description otherwise provides solid behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise opening sentence, an Args section, and a Returns section. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single optional parameter and an output schema available, the description covers the return format, error handling, and parameter behavior. It even provides a usage alternative. The tool's simplicity is fully matched by the description's completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining the project parameter: 'Project name. Leave empty if only one project is loaded.' This adds meaning beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Structured JSON snapshot of a project's graph state' and lists specific contents: identity, node/edge counts, graph commit, repository HEAD, freshness. It also differentiates from the sibling get_graph_stats by calling it the 'Machine counterpart' and saying 'parse it instead of the text output.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names get_graph_stats as the alternative and instructs to use this tool for machine parsing instead of text output. Also provides project parameter usage guidance: 'Leave empty if only one project is loaded.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Understand-Anything-MCP MCP server](https://glama.ai/mcp/servers/VIethoangnguyenle/Understand-Anything-MCP/badges/card.svg)](https://glama.ai/mcp/servers/VIethoangnguyenle/Understand-Anything-MCP)

Score Badge

Copy to your README.md:

[![Understand-Anything-MCP MCP server](https://glama.ai/mcp/servers/VIethoangnguyenle/Understand-Anything-MCP/badges/score.svg)](https://glama.ai/mcp/servers/VIethoangnguyenle/Understand-Anything-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/VIethoangnguyenle/Understand-Anything-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server