MCP Code Flow Analyzer

by bsdnn

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between findCallers and whoTriggers, and between generateFlowDiagram and traceBusinessFlow. Descriptions help differentiate, but agents might occasionally confuse them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in camelCase (e.g., findCallers, generateFlowDiagram), making them predictable and easy to understand. 'whoTriggers' is slightly different but still verb-like.
Tool Count5/5
With 7 tools, the server is well-scoped, covering essential code flow analysis functions without being overwhelming. Each tool serves a clear role.
Completeness4/5
The tool set covers search, call graph analysis, critical point detection, and visualization. Minor gaps exist, such as lacking a tool for comparing flows or detailed function metadata, but it sufficiently handles core analysis tasks.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, error behavior for invalid entry points, or any side effects, leaving significant ambiguity.
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 very concise with two short sentences, front-loading the core purpose, but lacks any additional structure or detail that would enhance utility without bloating.
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?
For a simple tool with two parameters and no output schema, the description adequately states the output format and general purpose, but omits important context like read-only nature and error handling, making it minimally sufficient.
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?
The input schema covers both parameters with descriptions, achieving 100% coverage, so the description adds no additional parameter context beyond what the schema already provides, resulting in a baseline score.
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 that the tool generates a Mermaid call graph diagram for a function, and specifies that the output renders in any markdown viewer, making the purpose unambiguous and distinguishing it from sibling 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?
The description provides no guidance on when to use this tool versus alternatives like findCallers or getCriticalPoints, nor does it mention prerequisites or context for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear full responsibility for behavioral disclosure. It states what statistics are returned but does not mention read-only behavior, authorization needs, rate limits, or whether data is live.
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?
A single concise sentence that conveys the purpose without waste. However, it could benefit from a brief additional sentence about usage context.
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?
With no output schema, the description partially explains the return values (four statistics), but lacks details on format, ordering, or any limits. It is minimally adequate.
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?
The input schema has no parameters, and coverage is 100%, so baseline is 3. The description adds nothing beyond the 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 clearly states the tool returns project statistics and lists specific metrics (file count, symbol count, critical point count, languages detected), which distinguishes it from sibling tools like findCallers or generateFlowDiagram.
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 alternatives such as searchSymbols or getCriticalPoints, nor any prerequisites or context.
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 should disclose behavioral traits. It mentions 'reverse call graph' but does not explain whether results are transitive, shallow, or include call context (e.g., line numbers). There is no mention of performance or limits.
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 single, clear sentence that efficiently conveys the tool's purpose without any unnecessary words or repetition.
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 simplicity of the tool (one parameter, no output schema), the description covers the essential purpose. However, it could be more complete by mentioning the return value format (e.g., list of function names) or any limitations (e.g., does not cross module boundaries).
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?
The input schema already provides a clear description for the single parameter 'functionName'. The description adds no additional semantic value beyond restating the parameter's purpose, so it meets the baseline for 100% schema coverage.
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 identifies the action ('Find') and the resource ('functions that call a given function'), and uses the phrase 'reverse call graph' which distinguishes it from sibling tools like 'traceBusinessFlow' or 'getCriticalPoints'.
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 the tool is used when one needs to find callers of a function, but it lacks explicit guidance on when to prefer this over alternatives like searchSymbols or traceBusinessFlow, nor does it mention any preconditions or caveats.
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. It mentions 'reverse-BFS' as the algorithm, which indicates a read-only traversal. However, it does not disclose potential performance implications, authentication needs, or other side effects. Without annotations, a score of 3 is appropriate as it explains the operation but lacks comprehensive behavioral disclosure.
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: two sentences that state the purpose and provide a concrete example. Every sentence adds value without 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?
Given the tool's complexity (reverse tracing) and the lack of output schema, the description adequately explains what the tool returns conceptually ('entry points'). It could be more complete by specifying output format or structure, but it is sufficient for an agent to understand the purpose.
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 100% and the schema already documents the parameter well with examples. The description does not add significant additional meaning beyond the schema, so baseline score of 3 is correct.
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 it's a reverse trace tool that finds entry points calling a given function, with a concrete example ('what endpoints write to the order table?'). It distinguishes itself from siblings like findCallers (forward trace) by explicitly using 'reverse' and 'reverse-BFS'.
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 scenario and implies when to use it (to trace callers upstream). However, it does not explicitly state when not to use it or suggest alternatives, leaving some room for interpretation.
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 bears full responsibility for behavioral disclosure. It clearly states that the tool returns critical operations and gives concrete examples, indicating a read-only analysis. While it could mention whether the tool is expensive or has auth requirements, the description is sufficiently transparent for a static analysis 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 consists of two succinct sentences. The first sentence clearly states the purpose, and the second adds distinctive value. Every sentence earns its place without 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?
Given the tool has one optional parameter and no output schema, the description explains the core functionality and parameter optionality well. It lacks explicit mention of the return structure (e.g., list of operations with details), but for a simple tool, it is nearly complete.
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 100%, so the baseline is 3. The tool description adds context about 'critical operations' and the unique value, but does not provide additional semantics for the entryPoint parameter beyond what the schema already says. Thus, a score of 3 is appropriate.
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 verb 'Get all critical operations' and specifies the resource: critical operations reachable from a function. It lists examples (database reads/writes, HTTP requests, file I/O, exec calls) and explicitly highlights the unique value compared to raw search, distinguishing it from sibling tools like searchSymbols.
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 when to use this tool by stating 'This is the unique value of MCP vs raw search,' suggesting it's for semantic classification rather than simple search. However, it does not explicitly exclude alternative siblings or provide clear 'when not to use' guidance, so it achieves a 4.
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 provided, so the description carries the full burden. It explains that the tool parses function bodies to return a call graph, critical operations, and a diagram, which implies read-only behavior. However, it does not mention potential performance impacts or limitations.
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 two sentences with no redundancy. The first sentence states the core function and outputs, the second adds key features (fuzzy matching, Chinese keywords). Every word adds value.
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 no output schema, the description adequately explains the three return components (call graph, critical ops, diagram). The single parameter is well-documented, and special capabilities (fuzzy matching, Chinese support) are mentioned. No obvious 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 coverage is 100% for the single parameter 'entryPoint'. The description adds concrete examples ('handleLogin', '支付', 'createOrder') and explains that it supports fuzzy matching and Chinese keywords, which goes beyond the schema's generic description.
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 it traces the complete business flow chain from an entry point, specifying the outputs (call graph, critical operations, Mermaid diagram). It distinguishes from siblings like 'findCallers' and 'generateFlowDiagram' by focusing on comprehensive flow tracing with fuzzy matching and Chinese keyword support.
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 tells the user to provide an entry point and mentions fuzzy matching and Chinese keywords, but does not explicitly state when to use this tool over siblings (e.g., when needing a complete flow vs just callers) or when not to use it.
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 provided, so description carries the burden. It discloses the fuzzy matching behavior and support for Chinese and CamelCase, which goes beyond the schema. It does not mention read-only or side effects, but search tools are inherently non-destructive.
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?
Single sentence front-loads the core purpose ('Fuzzy search for symbols') and then concisely lists supported features. No wasted words.
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?
With one simple parameter and no output schema, the description adequately covers the tool's behavior. It might have mentioned result formatting or limits, but for a basic search it is sufficiently complete.
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 only parameter 'query' has minimal schema description ('Search query'). The tool description adds significant value by specifying supported input forms (partial names, Chinese keywords, CamelCase prefixes), which aids correct invocation.
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?
Clearly states 'fuzzy search for symbols' and specifies supported patterns like partial names, Chinese keywords, and CamelCase prefixes, which distinguishes it from sibling tools like findCallers or traceBusinessFlow.
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?
Implies usage for fuzzy searching symbols with specific features, but does not explicitly state when not to use it or provide alternatives. However, the context is clear enough for typical search scenarios.
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:

[![mcp-code-flow-analyzer MCP server](https://glama.ai/mcp/servers/bsdnn/mcp-code-flow-analyzer/badges/card.svg)](https://glama.ai/mcp/servers/bsdnn/mcp-code-flow-analyzer)

Score Badge

Copy to your README.md:

[![mcp-code-flow-analyzer MCP server](https://glama.ai/mcp/servers/bsdnn/mcp-code-flow-analyzer/badges/score.svg)](https://glama.ai/mcp/servers/bsdnn/mcp-code-flow-analyzer)

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/bsdnn/mcp-code-flow-analyzer'

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