cognee-mcp

Overview Schema Source Related Servers Discussions Admin

code_search

Search an indexed code graph for symbols, call paths, dependencies, impact, architecture, and index changes, or ask plain-language questions about source code.

Instructions

Search Cognee's indexed code graph with a structured operation.

This tool is for source-code structure, symbols, call/dependency paths, impact, architecture, and index changes. It does not search conversational memory. Choose an operation and pass its operation-specific fields in arguments. For example, use operation="query_facts" with arguments={"kinds": ["module", "symbol"], "limit": 100}, or operation="impact_analysis" with arguments={"seeds": ["UserService"]}. For a question in plain words ("how does checkout work?"), use operation="ask" with the question as query: it returns matching symbols, entry-point flows, their neighbourhood and file:line citations.

Input Schema

TableJSON Schema

Name	Required	Description
`query`	No	Optional seed text, used by explore when no explicit seed is supplied in arguments, and the text or question for search and ask.
`top_k`	No	Maximum number of results to return (default: 15).
`datasets`	No	Comma-separated Cognee dataset names containing indexed code.
`arguments`	No	Operation-specific structured arguments. Do not include an "operation" key here; select it with the operation parameter.
`operation`	Yes	Code-graph operation: query_facts, explore, traverse, find_path, impact_analysis, insights, architecture, delta, capabilities, search, neighbors, subgraph, flows, hubs, or ask.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.6.5Oct 17, 2026

changedInput schema / properties / operation / description

Previous value: -"Code-graph operation: query_facts, explore, traverse, find_path,\nimpact_analysis, insights, architecture, or delta."New value: +"Code-graph operation: query_facts, explore, traverse, find_path,\nimpact_analysis, insights, architecture, delta, capabilities, search,\nneighbors, subgraph, flows, hubs, or ask."

changedInput schema / properties / operation / enum

Previous value: -[
-  "query_facts",
-  "explore",
-  "traverse",
-  "find_path",
-  "impact_analysis",
-  "insights",
-  "architecture",
-  "delta"
-]New value: +[
+  "query_facts",
+  "explore",
+  "traverse",
+  "find_path",
+  "impact_analysis",
+  "insights",
+  "architecture",
+  "delta",
+  "capabilities",
+  "search",
+  "neighbors",
+  "subgraph",
+  "flows",
+  "hubs",
+  "ask"
+]

changedInput schema / properties / query / description

Previous value: -"Optional seed text, primarily used by explore when no explicit seed is\nsupplied in arguments."New value: +"Optional seed text, used by explore when no explicit seed is supplied\nin arguments, and the text or question for search and ask."

Addedv1.6.4Oct 14, 2026

TDQS

A4/5.0

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 behavioral burden. It discloses some return context ('returns matching symbols, entry-point flows, their neighbourhood and file:line citations') and the seed-vs-query behavior of explore, but says nothing about read-only semantics, permission requirements, cost/latency of the heavier operations, or how the fifteen operations differ in behavior.

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?

Front-loads purpose, then scope exclusion, then operation guidance with runnable examples. Every sentence earns its place and there is no filler; only mild redundancy in re-listing the operation enum, which the schema already carries.

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?

An output schema exists, so return values need not be described, and the description is otherwise well scoped. But for a tool with 15 operations funnelling through a freeform `arguments` object, exemplifying only 3 operations leaves the agent without the operation-specific argument shapes needed to call most of the enum correctly.

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%, so the baseline is 3, but the description goes beyond it by showing concrete operation-specific contents for the opaque `arguments` object (kinds/limit for query_facts, seeds for impact_analysis), which the schema does not enumerate. It also clarifies that `query` doubles as seed text or plain-language question depending on operation.

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?

States a specific verb and resource ('Search Cognee's indexed code graph') and then enumerates exactly what is in scope: source-code structure, symbols, call/dependency paths, impact, architecture, index changes. It also explicitly excludes conversational memory, so an agent can distinguish it from the memory-oriented siblings without opening the schema.

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?

Gives concrete when-to-use guidance by routing three named operations with example payloads: query_facts for fact queries, impact_analysis for seeds, ask for plain-language questions. However, only 3 of the 15 operations are explained, so the agent gets no guidance on when to pick traverse, find_path, hubs, flows, or the other ten, and there is no statement of exclusion beyond 'not conversational memory'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server