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., "@cc-sensei How does Claude Code compact long conversations?"
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.
π© "I've already dug deep into Claude Code's source, but when I ask my AI to help me build an Agent, it has no idea what I'm talking about β what I read, it didn't."
π« "I'd love to build a knowledge base so my AI can learn from Claude Code, but the moment I open it β 300K+ lines, 1,250 files β both my AI and I are scared off."
π΅ "I've barely looked at Claude Code's source, but I still want an Agent just as powerful β where do I even begin?"
If any of these hit home β this project is built for you.
Related MCP server: ontomics
Agent Architecture Oracle distills Claude Code's 310K lines of source and 1,250 files into 32 core modules with 40K lines of structured analysis, and serves it directly to your AI through the MCP protocol.
It covers every core capability of Claude Code:
π Agent main loop Β· π οΈ Tool system & execution pipeline Β· π‘οΈ Permissions & security sandbox Β· π Model API & streaming π§ Context engineering & compaction Β· π File / Shell / Git tools Β· π MCP protocol Β· π¨ Ink rendering engine Β· 𧩠Skills/plugins πΎ Persistent memory Β· β‘ Prompt cache break detection Β· π€ Sub-agents & task system β¦ (22 core + 10 deep-dive supplements)
It establishes a complete index pipeline: natural language β module β design decision β reusable pattern β corresponding source code:
You say one thing Oracle automatically does five things
βββββββββββββββββββββββββ ββββββββββββββββββββββββββββββββββββββββββ
"How do you compact long βββΊ β Match natural language to M06 (Context Engineering)
conversations?" β‘ Return the 4-tier compaction architecture & 9-section summary prompt
β’ List 5 directly-copyable engineering principles
β£ Cross-trace the 12 modules touched by prompt cache
β€ Pull up services/compact/microCompact.ts source on demandAfter plugging it into Claude Desktop / Cursor / Qoder / your own Agent, your AI gains a "Chief Architect of Claude Code" as its consultant β whether you're cloning the whole thing or just stealing one design, it tells you exactly where to look, why it works, and how to copy it.
In one night, your AI becomes a world-class Agent architect.
npx cc-senseiThis downloads and runs the server directly. Skip to Step 3 to connect your AI.
git clone https://github.com/contradictory-body/cc-sensei.git && cd cc-senseiCopy-paste again:
pnpm install && pnpm buildπ‘ Don't have pnpm? Run
npm install -g pnpmfirst. π‘ This step parses 32 module analyses, generates the knowledge index, and compiles the server. One-time only.
When done, you should see: β
module-registry.json (32 modules) and β
Build success.
Add this snippet to your MCP client's configuration file (replace the path with the one you just cloned to):
{
"mcpServers": {
"cc-sensei": {
"command": "node",
"args": ["/your/absolute/path/cc-sensei/dist/server.js"]
}
}
}Don't know where the config file is? Common locations:
Client | Config file path |
Claude Desktop (macOS) |
|
Claude Desktop (Windows) |
|
Cursor | Settings β MCP β Add new server |
Qoder | Settings β MCP β Edit mcpServers |
Restart your client. Done! Your AI just gained 6 new skills.
Just say to your AI:
"Use cc-sensei to tell me how Claude Code optimizes prompt cache."
It will call the tools on its own and return a complete analysis with source-code references. That's it.
Tool | One-line capability | When to use |
| List all 32 modules and their concerns | "Which modules does Claude Code break down into?" |
| Natural-language search with 3 depth levels (brief/standard/deep) | "How do they prevent long-conversation context overflow?" |
| Drill into one module's specific section (responsibility / architecture / decisions / principles / relations) | "Show me M06's design principles" |
| Trace one concern across all 32 modules, ranked by hit count | "Which modules touch 'prompt cache'?" |
| Bulk-extract reusable patterns with built-in size limiting | "Give me every cache-related design I can copy" |
| Read Claude Code source directly (with line numbers, ranges, and directory listings) | "Show me |
Every tool comes with:
β
Path-prefix tolerance β both src/... and bare paths are accepted; no more copy-paste failures
β Result rate-limiting β 800 chars per section and 12 sections by default, so your AI's context window stays alive
β
Path-traversal protection β attacks like ../../../etc/passwd are rejected outright
β Graceful degradation β bad arguments return friendly hints instead of crashes
You: "How do you compact conversation history to avoid hitting the token limit?"
Oracle (query_architecture, 103ms):
β Hit M06: Context Engineering
β Returns the 4-tier compaction architecture comparison table
(microCompact / sessionMemoryCompact / autoCompact / reactiveCompact)
β Trigger conditions, whether LLM is invoked, key file locations β all listed
You: "Show me M06's key design principles"
Oracle (get_module section=principles, 102ms):
β "Sticky-on Beta Headers β performance over simplicity"
"Single message-level cache_control marker (max 4)"
"9-section summary structure β eval-driven prompt"
β Each principle includes: where it lives, code snippet, why, how to reuse, the trade-off
You: "How many modules does 'prompt cache' span?"
Oracle (trace_concern, 118ms):
β 12 modules ranked by hit count
β Each with 5 lines of file:line excerpts
You: "Show me src/services/compact/microCompact.ts"
Oracle (get_source_code, 99ms):
β Source with line numbers + total line countA complete "understand β copy β ship" loop, averaging ~110ms.
π 32 module analyses (40K lines of distilled insight covering 310K lines of source)
βββ M01-M22 Core modules
β M01 Process bootstrap & lifecycle Β· M02 Agent main loop Β· M03 Tool system
β M04 Permissions & security Β· M05 Model API & streaming Β· M06 Context engineering
β M07 File/Shell/Git tools Β· M08 MCP protocol Β· M09 LSP integration
β M10 Bridge/IPC Β· M11 Ink rendering engine Β· M12 Message rendering
β M13 Input system Β· M14 Sub-agents & tasks Β· M15 Skills/plugins
β M16 Command system Β· M17 Configuration & settings Β· M18 Telemetry & analytics
β M19 State management Β· M20 Hotkeys & focus Β· M21 Buddy/voice Β· M22 Testability
βββ SUPP-* 10 deep-dive supplements
AgentSummary Β· SessionMemory Β· autoDream Β· ColorDiff
extractMemories Β· fileIndex Β· largeFiles Β· speculation
teamMemorySync Β· yogaLayout
ποΈ Indexes: 390 keywords / 104 concerns / full section-line mappings
π» Full source code: claude-code-main/src/ available for direct local readsThis project is dogfooding itself β built using the methods Claude Code teaches, made to serve Claude.
Claude Code's design philosophy | How this project applies it |
Build-time indexing + zero runtime analysis | Section line ranges, keywords, and concerns are all computed in |
Path-traversal gatekeeping |
|
Graceful degradation > unhandled crashes | Section not found? Return the "available types" hint |
Structured prompt-as-spec | All 32 MODULE_NOTES strictly follow a 10-section template |
Rate-limiting by default | search_patterns defaults to 800 chars per section, 12 sections cap, configurable |
p50 = 105ms p95 = 118ms max = 125ms
Average response size: 7K chars
Fully local, 0 network dependencypnpm exec tsx scripts/test-suite.ts # 30 baseline functional tests
pnpm exec tsx scripts/regression-3fixes.ts # 11 UX-fix regression tests
pnpm exec tsx scripts/e2e-comprehensive.ts # 24 real-scenario E2E testsTest suite | Cases | Result |
Baseline functionality (6 tools Γ multiple branches) | 30 | β 30/30 |
UX-fix regression | 11 | β 11/11 |
Real user-scenario E2E (3 personas) | 24 | β 24/24 |
Total | 65 | β 65/65 |
cc-sensei/
βββ src/
β βββ server.ts # MCP server entry
β βββ retrieval/engine.ts # Retrieval engine
β βββ source-reader.ts # Source reading + path safety
β βββ taxonomy.ts # 32-module mapping table
β βββ tools/ # 6 MCP tools
βββ scripts/
β βββ build-index.ts # Parses MODULE_NOTES into indexes
β βββ test-suite.ts
β βββ regression-3fixes.ts
β βββ e2e-comprehensive.ts
βββ knowledge/ # Build artifacts
β βββ module-registry.json
β βββ keyword-index.json
β βββ concern-map.json
βββ claude-code-main/ # Claude Code source + 32 module analyses
β βββ src/ # β Source
β βββ MODULE_NOTES/ # β Analyses
βββ dist/server.js # Bundle outputEnv var | Purpose | Default |
| Claude Code source root |
|
| Module-analysis directory |
|
Point these to anywhere else and Oracle becomes a knowledge server for any project β as long as that project has analyses written to the same MODULE_NOTES template.
Incremental indexing (only re-parse changed MODULE_NOTES)
More section types (performance / security / observability)
HTTP / SSE transport (in addition to stdio)
Multi-codebase support (mount several projects at once)
MIT
Can't read 310K lines of source? Let 40K lines of distilled analysis read it for you, and let your AI copy from it.
If this project helped you, drop a β so more Agent developers can find it.
Get detailed content from a specific module. Can optionally return only a specific section type (responsibility, architecture, decisions, principles, or relations).
| Name | Required | Description | Default |
|---|---|---|---|
| module_id | Yes | Module ID (e.g., 'M01', 'M02', ..., 'M22', 'SUPP-AgentSummary', 'SUPP-SessionMemory', etc.) | |
| section | No | Optional: return only a specific section type. If omitted, returns the full module. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It indicates a read operation but does not mention error handling, permissions, or that it is read-only. The description is adequate but not rich.
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 two sentences, front-loads the main purpose, and has no unnecessary words. Every sentence adds value.
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 retrieval tool with two well-documented parameters, the description covers the essential functionality. The absence of an output schema is acceptable as the return type (detailed module content) is implied.
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 the schema describes parameters completely. The description adds minimal value by listing section types already in the schema. Baseline 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 tool retrieves detailed content from a specific module, with an optional section filter. It distinguishes itself from siblings like list_modules (which lists modules) and get_source_code (which retrieves code).
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 does not provide guidance on when to use this tool versus alternatives. It lacks context for choosing between get_module and other sibling tools like query_architecture or trace_concern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read actual Claude Code source code files. Use this to see implementation details referenced in module analysis. Supports line-range extraction. Returns at most 500 lines per call.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Relative path within src/ (e.g., 'entrypoints/cli.tsx', 'services/api/claude.ts'). A leading 'src/' prefix is also accepted and will be stripped automatically. | |
| start_line | No | Optional: starting line number (1-based). Defaults to 1. | |
| end_line | No | Optional: ending line number (1-based). Defaults to start_line + 499. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: 'Supports line-range extraction' and 'Returns at most 500 lines per call.' This is good for a read tool, though it doesn't mention any potential limits on file paths (e.g., only within src/) or error cases.
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?
Three short sentences (20 words total) convey the purpose, usage context, and a key constraint. No wasted words; front-loaded with the main verb and resource. Perfectly concise for this simple tool.
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 read-only tool with 3 parameters and no output schema, the description is largely complete. It covers what the tool does, when to use it, and a key behavioral constraint. It could mention the return format (plain text?), but that is not essential given the simplicity. Slight gap: no mention of error handling or whether file path must be relative.
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%, and the schema already describes all three parameters with clear descriptions. The description adds value only by summarizing ('Supports line-range extraction'), which is useful but not essential beyond the schema. Baseline 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 uses a specific verb 'read' and explicitly states the resource ('actual Claude Code source code files'). It distinguishes from sibling tools like 'get_module' (module abstraction) and 'list_modules' by indicating this is for raw implementation details referenced in module analysis.
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 clear context: 'Use this to see implementation details referenced in module analysis.' This implies when to use it relative to siblings. However, it does not explicitly state when not to use it or mention alternatives, so slight room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available architecture modules. Returns module IDs, titles, and key concerns for each module. Use this to discover what knowledge is available before querying specific modules.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional: filter by category. 'core' = M01-M22 main modules, 'supplement' = SUPP-* deep-dive supplements. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must supply behavioral context. Describes return data but omits details like sorting, pagination, or empty result handling. Adequate for a simple listing tool, but lacks depth.
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?
Two concise sentences with no fluff. First sentence states purpose and output; second provides usage guidance. Every word earns its place.
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, description reasonably hints at return structure (IDs, titles, concerns). Covers filtering by category. Lacks details on sorting or limits, but sufficient for typical discovery use.
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?
Single parameter 'category' with enum values. Schema already fully describes it (100% coverage). Description adds minor clarification (M01-M22, SUPP-*), but not substantial beyond schema. Baseline 3 applies.
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 action 'List all available architecture modules' with specific return fields (IDs, titles, key concerns). Differentiates from siblings like get_module (single) and search_patterns.
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?
Explicitly says 'Use this to discover what knowledge is available before querying specific modules,' providing clear context. Could be improved by mentioning when not to use (e.g., for specific details use get_module), but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Claude Code architecture knowledge base. Returns relevant module analysis at the requested depth level. Use this to understand how specific features, patterns, or subsystems are implemented.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language query about Claude Code architecture (e.g., 'how does context trimming work', 'permission system', 'streaming tool execution') | |
| depth | No | Level of detail: 'brief' = module overview (fast), 'standard' = architecture + key decisions, 'deep' = full module content | |
| modules | No | Optional: limit search to specific module IDs (e.g., ['M02', 'M06']). If omitted, searches all modules. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool searches and returns results at requested depth, which covers core behavior. However, it does not disclose potential limitations (e.g., no results, rate limits) or explicitly confirm read-only nature.
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: two sentences covering purpose and usage, plus an example-based parameter guide. No superfluous words, and front-loaded with the main action.
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 complete for a search tool given no output schema: it explains what is returned (module analysis at depth) and how to use parameters. However, it could briefly mention the return format (e.g., text summaries) to fully inform the agent.
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?
With 100% schema coverage, baseline is 3, but the description adds significant value: for 'query' it provides examples; for 'depth' it explains each enum value with detail; for 'modules' it clarifies optionality and format. This greatly aids correct parameter usage.
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 searches the architecture knowledge base and returns module analysis at a requested depth. It distinguishes from siblings by specifying 'features, patterns, or subsystems', which are not covered by sibling tools like search_patterns or trace_concern.
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 a clear usage context: 'Use this to understand how specific features, patterns, or subsystems are implemented.' This tells when to use the tool but lacks explicit exclusions or alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for reusable design patterns and principles extracted from Claude Code's architecture. Returns 'directly-reusable' patterns that you can adapt for your own Agent implementation. Output is paginated: each section is capped (default 800 chars) and total sections capped (default 12). Use module_id to focus, or get_module(section="principles") for the full text of a specific module.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern_type | No | Type of patterns to search: 'reusable' = patterns you can copy, 'anti-pattern' = patterns to avoid, 'all' = both. | |
| keywords | No | Optional: filter patterns by keywords (e.g., ['cache', 'retry', 'streaming']). | |
| module_id | No | Optional: restrict to a single module (e.g., 'M05'). Useful when you already know the relevant module. | |
| max_per_section | No | Optional: per-section character cap (default 800). Truncated sections include a hint to fetch full content via get_module. | |
| max_sections | No | Optional: maximum total number of sections to return (default 12). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination, character and section caps, and hints to fetch full content via get_module. Since no annotations are present, this adequately informs about expected behavior without missing critical details.
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?
Two sentences, no unnecessary words. First sentence states core function and return type; second explains pagination and module usage. Efficient and well-structured.
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?
Covers key behavioral aspects (pagination, caps, get_module link) given no output schema and 5 parameters. Missing explicit return format or error handling, but overall sufficient for effective use.
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?
Adds value beyond the schema by explaining defaults (800 chars, 12 sections), the purpose of module_id for focusing, and the get_module fallback. Schema coverage is 100%, but description enriches understanding.
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?
Clear verb 'search' and specific resource 'reusable design patterns and principles'. Distinguishes from sibling get_module by explicitly suggesting its use for full content retrieval.
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?
Provides clear context for when to use (searching patterns) and how to focus (module_id). Mentions get_module as alternative for full text, but no explicit 'when not to use' or list of all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace a specific architectural concern across all modules. Shows how one concept (e.g., 'prompt cache', 'error recovery', 'streaming') is handled at different layers of Claude Code's architecture.
| Name | Required | Description | Default |
|---|---|---|---|
| concern | Yes | The architectural concern to trace (e.g., 'prompt cache', 'error recovery', 'abort signal', 'streaming', 'retry'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the tool 'Shows how one concept is handled at different layers', giving a behavioral hint but lacks details on output format, side effects, or whether the operation is read-only.
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 extremely conciseβtwo sentences, no fillerβwith the purpose front-loaded and immediately understandable.
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 tool's simplicity (one parameter, no output schema), the description is nearly sufficient, though mentioning the return type or that it is read-only would improve 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?
Schema description coverage is 100% for the single parameter 'concern', and the description does not add further semantics 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('trace') and resource ('architectural concern across all modules') and provides concrete examples ('prompt cache', 'error recovery') that distinguish it from sibling tools which focus on modules, source code, or patterns.
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 clearly implies when to use the tool (to see how a concept spans layers), but it does not explicitly mention when not to use it or direct to alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_moduleget_source_codelist_modulesquery_architecturesearch_patternstrace_concernEach tool has a clearly distinct purpose: listing modules, getting module content, searching architecture knowledge, searching patterns, tracing concerns, and reading source code. No two tools overlap significantly, and descriptions clarify any potential ambiguity.
All tools follow a consistent verb_noun pattern (e.g., get_module, list_modules, trace_concern) with clear, descriptive verbs. No mixing of conventions.
Six tools is well-scoped for an architectural knowledge base, providing essential operations without being overwhelming. Each tool serves a necessary role.
The tool surface covers all major activities: discovering modules (list_modules), retrieving module details (get_module, get_source_code), searching across the knowledge base (query_architecture, trace_concern), and accessing design patterns (search_patterns). No obvious gaps for a read-only reference server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/contradictory-body/cc-sensei'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
