Provides tools for C++ code intelligence via clangd, including finding definitions, references, type information, symbol search, implementations, diagnostics, and hierarchy queries.
Integrates with clangd, the LLVM-based C++ language server, to enable code navigation and analysis capabilities for large C++ codebases.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@clangd-mcp-server Find definition of Logger::Log in logger.h"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol server for clangd on large C++ codebases.
This MCP provides coding agents like Claude Code with a collection of tools that they may use to answer natural language queries from the user:
find_definition: Jump to symbol definitions
"Find the definition at src/foo.cpp:42:10"
find_references: Find all references to a symbol
"Find all references to the function at bar.h:100"
get_hover: Get type information and documentation
"What's the type at baz.cpp:200:15?"
workspace_symbol_search: Search symbols across workspace
"Find symbols matching 'HttpRequest'"
find_implementations: Find interface/virtual method implementations
"Find implementations of interface.h:50"
get_document_symbols: Get hierarchical symbol tree for a file
"Show all symbols in main.cpp"
get_diagnostics: Get compiler errors, warnings, and notes
"Show errors in src/foo.cpp"
get_call_hierarchy: Get function callers and callees
"Show callers/callees at main.cpp:100:5"
get_type_hierarchy: Get base classes and derived classes
"Show base/derived classes at foo.h:42"
Node.js >= 18.0.0
clangd
A C++ project with compile_commands.json
Related MCP server: LSP-MCP
# From npm (eventually!)
# npm install -g clangd-mcp-server
# From source
git clone https://github.com/felipeerias/clangd-mcp-server.git
cd clangd-mcp-server
npm install && npm run build && npm linkCMake: cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON /path/to/source
GN (Chromium): gn gen out/Default
gn gen --export-compile-commands out/default
ln -sf out/Default/compile_commands.json .
claude mcp add clangd-mcp-server clangd-mcp-serverOther: Check your project's documentation.
claude mcp add clangd-mcp-server clangd-mcp-serverOr add manually to ~/.claude.json or .claude.json:
{
"mcpServers": {
"clangd": {
"command": "clangd-mcp-server",
"env": {"PROJECT_ROOT": "/path/to/your/project"},
"alwaysAllow": ["*"]
}
}
}The alwaysAllow: ["*"] field allows all tools to run without prompting for user approval.
To help Claude Code automatically use clangd MCP tools for your C++ project, add to your project's CLAUDE.md:
## C++ Code Navigation
This project uses the clangd MCP server for C++ code intelligence. Use these tools for:
- Finding definitions and references
- Getting type information
- Searching symbols
- Finding implementations
- Getting diagnosticsVariable | Description | Default |
| Project workspace root | Current directory |
| Path to compile_commands.json directory | Auto-detected |
| Path to clangd binary | Auto-detected |
| Additional clangd arguments | Auto-configured |
| MCP log level (ERROR/WARN/INFO/DEBUG) |
|
| Clangd log level |
|
Clangd auto-detection order: CLANGD_PATH → project bundled (Chromium: third_party/llvm-build/.../clangd) → system PATH
Some large projects bundle their own clangd.
Chromium is auto-detected at third_party/llvm-build/Release+Asserts/bin/clangd.
For other projects in a similar situation, set CLANGD_PATH to specify the bundled clangd.
For bettern performance, background indexing is disabled by default. Usually there is already an axisting clangd server taking care of indexing the codebase. You can enable it with:
{"env": {"CLANGD_ARGS": "--background-index --limit-results=1000"}}Large projects might consider using remote index.
Verbose logging may be enabled with:
{"env": {"LOG_LEVEL": "DEBUG", "CLANGD_LOG_LEVEL": "verbose"}}Examples:
// Chromium (auto-detects bundled clangd)
{"mcpServers": {"clangd": {"command": "clangd-mcp-server",
"env": {"PROJECT_ROOT": "/home/user/chromium/src"},
"alwaysAllow": ["*"]}}}
// Custom clangd binary
{"mcpServers": {"clangd": {"command": "clangd-mcp-server",
"env": {"CLANGD_PATH": "/custom/path/clangd"},
"alwaysAllow": ["*"]}}}
// Custom args (e.g., enable background indexing)
{"mcpServers": {"clangd": {"command": "clangd-mcp-server",
"env": {"CLANGD_ARGS": "--background-index --limit-results=1000"},
"alwaysAllow": ["*"]}}}Claude Code
↓ MCP (stdio)
clangd-mcp-server
├── ClangdManager (lifecycle, health monitoring)
├── LSPClient (JSON-RPC over stdio)
├── FileTracker (didOpen/didClose)
└── Tools (find_definition, find_references, etc.)
↓ LSP requests
clangd subprocessnpm install # Install
npm run build # Build
npm run watch # Watch mode
npm test # Run tests
node dist/index.js # Test locallyMPL-2.0 - See LICENSE
Find the definition of a symbol at a given location in a file
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the source file | |
| line | Yes | Line number (0-indexed) | |
| column | Yes | Column number (0-indexed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose behavior such as language support, handling of missing symbols, or return value. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence that is front-loaded with the primary action, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description is minimally adequate for a simple navigation tool but lacks details on return values or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all parameters. Description adds no extra meaning beyond what schema already provides, achieving baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool finds a symbol's definition at a given file location, distinguishing it from siblings like find_references or find_implementations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like find_implementations or workspace_symbol_search. Lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find implementations of an interface or virtual method at a given location
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the source file | |
| line | Yes | Line number (0-indexed) | |
| column | Yes | Column number (0-indexed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the basic function but lacks details about scope (e.g., project vs whole workspace), behavior when location is not on an interface/virtual method, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it could be slightly more informative without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a tool with no output schema and three parameters. It lacks information about the return format, what happens when no implementations are found, and the expected location type (must be a declaration?).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the description adds no additional meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'implementations of an interface or virtual method', which is specific and differentiates from siblings like find_definition and find_references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding concrete implementations of abstractions but does not explicitly state when to use it vs alternatives or provide context where it is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all references to a symbol at a given location
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the source file | |
| line | Yes | Line number (0-indexed) | |
| column | Yes | Column number (0-indexed) | |
| include_declaration | No | Include the declaration in the results (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not explicitly state whether the operation is read-only, whether it has side effects, or what permissions are needed. The description implies a safe read operation but fails to confirm it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous words. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should inform the agent about the expected return format (e.g., list of locations). It does not, leaving the agent uncertain about the result structure. The tool is simple, but this missing context detracts from completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions. The tool description adds no additional meaning beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find all references to a symbol at a given location' uses a specific verb ('Find') and resource ('references'), and implicitly distinguishes from sibling tools like find_definition (which finds the definition) and find_implementations (which finds implementations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives such as find_definition or find_implementations. The agent must infer from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get call hierarchy showing incoming callers and outgoing callees for a function
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the source file | |
| line | Yes | Line number (0-indexed) | |
| column | Yes | Column number (0-indexed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic purpose. It does not disclose any side effects, performance implications, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with key purpose. However, it could benefit from a slightly more structured format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. Description does not specify return format, error cases, or that it only works for function symbols. Sibling tools provide alternative views but no guidance on when to use this specific tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional semantics beyond mentioning it works 'for a function'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a call hierarchy showing both incoming callers and outgoing callees for a function. However, it does not explicitly distinguish from sibling tools like 'find_references' which may also show call relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'find_references' or 'find_implementations'. No mention of prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get diagnostics (errors, warnings, notes) for a file
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the source file | |
| force_refresh | No | Force re-parsing of the file to get latest diagnostics (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It lacks behavioral details like caching behavior, performance implications of force_refresh, or whether diagnostics are from a specific source (e.g., linter).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence, concise and to the point. Could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no nested objects, no output schema), the description and schema together cover the tool's purpose adequately. Missing details about return format are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions are already present. The main description adds no further meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'diagnostics (errors, warnings, notes) for a file'. It distinguishes from siblings like 'find_definition' or 'get_hover' which 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, nor any conditions or exclusions. Agent is left without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a hierarchical list of all symbols in a document
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the source file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only mentions 'hierarchical list of all symbols', leaving out details like whether it includes unsaved changes, performance implications, or error handling for missing files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is overly minimal. It states the purpose concisely but omits useful context, making it less than optimal for an agent to understand the tool fully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no output schema, the description provides the core functionality. However, it lacks details about behavior (e.g., empty results, file not found) and does not leverage the opportunity to differentiate from siblings beyond the hierarchical aspect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (file_path described as 'Absolute path to the source file'), so baseline is 3. The description adds no additional parameter information, but the schema already provides adequate meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a hierarchical list of all symbols in a document', which clearly identifies the verb ('Get'), resource ('symbols'), and scope ('in a document'). It distinguishes from sibling tools (e.g., find_definition, find_implementations) by indicating it returns all symbols hierarchically, not a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention scenarios where this is preferred (e.g., exploring document structure) or exclusions (e.g., not for symbol-specific lookups).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get hover information (type, documentation) for a symbol at a given location
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the source file | |
| line | Yes | Line number (0-indexed) | |
| column | Yes | Column number (0-indexed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by stating 'get hover information.' However, no annotations exist, and it does not mention any potential side effects, authentication needs, or rate limits. Basic transparency is achieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. No extraneous words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic functionality and hints at return content (type, documentation), but fails to specify the exact output structure or potential edge cases. Adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning to the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves hover information (type, documentation) for a symbol at a given location. It distinguishes from sibling tools like find_definition or find_references, which 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.
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, such as find_definition for navigating to definitions. It lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get type hierarchy showing base classes (supertypes) and derived classes (subtypes)
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the source file | |
| line | Yes | Line number (0-indexed) | |
| column | Yes | Column number (0-indexed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits. It only states the output (base and derived classes) but fails to mention read-only nature, prerequisites, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks context on what the hierarchy looks like, language support, or behavior when position does not correspond to a type. Incomplete for an agent to reliably decide to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond schema for file_path, line, and column parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves type hierarchy including supertypes and subtypes, distinguishing it from sibling tools like find_definition or get_call_hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings (e.g., find_implementations for interfaces, get_call_hierarchy for methods). Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for symbols across the entire workspace
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for symbol names | |
| limit | No | Maximum number of results to return (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency, but it only provides a one-line summary. It does not disclose search semantics (e.g., case sensitivity, wildcard support), scope behavior, or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but lacks any structure. It is not overly long, but could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is minimally adequate but leaves gaps: no hint about the nature of symbols searched, no mention of error handling or limits beyond the schema. Slightly lacking given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage). The description adds no additional semantic value beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search) and resource (symbols across workspace). It is specific enough to distinguish from siblings like find_definition or get_document_symbols, though it could be more precise about symbol types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that more specific tools exist for definitions or implementations, nor does it provide context on when this broad search is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct code analysis purpose such as finding definitions, references, or diagnostics; there is no functional overlap.
All tool names follow a consistent verb_noun pattern (e.g., find_definition, get_diagnostics) using snake_case, making them predictable.
9 tools are well-scoped for a code intelligence server, covering the essential operations without being excessive.
The tool surface covers core navigation and inspection needs; minor gaps like rename or code completion are absent but not critical for the server's purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/felipeerias/clangd-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
