Skip to main content
Glama

Code Intelligence

code_intel
Read-onlyIdempotent

Analyze code structure and dependencies to assess impact of changes, find callers, and identify orphaned code using graph intelligence.

Instructions

DECISION RULE: Structure questions → this tool. Text search → Grep.

Before using Grep, ask: Is this a STRUCTURE question (definitions, callers, impact) or a TEXT question (strings, config)?

QUICK START: return await api.searchSymbols({query: "AuthService"}) — simple queries are one-liners. Run api.listMethods() for full API reference with signatures and descriptions. Run api.help("methodName") for inline TypeScript type definitions — no resource reads needed. Compose: const [impact, deps] = await Promise.all([api.impactAnalysis({symbolId}), api.getDependents({filePath})]);

WHY THIS TOOL: Graph-backed intelligence finds indirect relationships, transitive dependencies, and breaking change risks that text search cannot detect.

"What uses X?" disambiguation: getDependents (file imports) vs getCallGraph (call chain) vs traceSymbolUsage (all usages).

USE IMMEDIATELY WHEN: • BEFORE using Edit on a function/class → run impactAnalysis({symbolId}) first • BEFORE exploring an unfamiliar codebase → run getArchitectureOverview() • BEFORE refactoring → trace getDependencies + getDependents for blast radius • Running 3+ Grep calls for structure? STOP → use code_intel instead

TOP 5 QUESTIONS (query is case-insensitive substring match): • "Where is X defined?" / "Find function Y" → searchSymbols({query}) • "What calls X?" / "What imports this?" → getDependents({filePath}) or getCallGraph({symbolId}) • "What does X depend on?" → getDependencies({filePath}) • "Safe to modify X?" / "Blast radius?" → impactAnalysis({symbolId}) • "Find dead code" / "Unused exports?" → findOrphanedCode() • "Complex functions?" / "Refactoring targets?" → searchSymbols results include complexity.cyclomaticComplexity + complexityRisk per function

NOT FOR: literal string search, log messages, config values, or reading source code. Use Grep/Glob/Read for those. Supports TypeScript, JavaScript, Python, and more — run api.getCapabilities() to check your project. File-path-scoped methods (getDependencies, getDependents, getCallGraph, traceSymbolUsage, impactAnalysis) reject calls whose filePath extension is not in the project's configured languages with UNSUPPORTED_LANGUAGE — check api.getCapabilities() first.

WRONG TOOL SIGNAL: If you've run 3+ Grep calls for structure (callers, dependencies, impact), STOP and use code_intel instead. Typical workflow: code_intel to find (results include source snippets) → Edit to modify

Sandbox limits: 50 api.* calls per execution, 128 MB memory, 100 KB max code size, limit max 100 on any method with a limit param. Pure JS only — no require/import/fs/net/process (see constellation://docs/guide for full restrictions).

IMPORTANT: The cwd parameter is required — always set it to the target project directory path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesJavaScript code to execute. Can use top-level await. Available API methods: searchSymbols, getSymbolDetails, getDependencies, getDependents, findCircularDependencies, traceSymbolUsage, getCallGraph, impactAnalysis, findOrphanedCode, getArchitectureOverview
timeoutNoOptional execution-time override in milliseconds. When omitted, the sandbox derives the timeout from the static complexity of your code (heavier api.* methods raise the budget) and clamps the result to [1000, 60000]. The breakdown is returned in the response so you can see what was applied. Explicit values still win and are clamped to the same range.
cwdYesAbsolute path to the project directory being queried. Used to locate the correct constellation.json by finding the git repository root. Set this to the root of the repository or workspace folder you are working in.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
successYes
resultNo
logsNo
timeNo
asOfCommitNo
lastIndexedAtNo
resultContextNo
timeoutBreakdownNo
errorNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: sandbox limits (50 api calls, 128 MB memory, 100 KB code), timeout derivation, UNSUPPORTED_LANGUAGE rejection, and requirement for cwd to locate constellation.json. These reveal important constraints and behaviors beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is thorough but verbose. It uses headings, bullet points, and code examples effectively, and front-loads with the decision rule. However, some sections (e.g., sandbox limits, top 5 questions) are longer than necessary. A slightly more concise version would maintain completeness while improving scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple API methods, sandbox restrictions, dynamic timeouts, language support), the description covers all essential aspects: when to use, how to compose calls, error conditions (UNSUPPORTED_LANGUAGE), and limitations. Output schema exists, so return value documentation is not needed. Complete for its context.

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%, but description adds meaning: for 'code', it lists available API methods; for 'timeout', explains dynamic derivation and clamping; for 'cwd', explains its role in locating configuration. This enriches the agent's understanding beyond the schema, though the schema already covers parameter types and descriptions.

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 is for structure questions (definitions, callers, impact) versus text search (Grep). It uses specific verbs like 'find', 'trace', 'search' and explicitly distinguishes from sibling tools (Grep, Glob, Read) even though no siblings are listed. The 'WRONG TOOL SIGNAL' and 'NOT FOR' sections reinforce purpose clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Excellent guidelines: 'DECISION RULE' distinguishes structure vs text; 'USE IMMEDIATELY WHEN' lists specific scenarios before editing, exploring, refactoring; 'TOP 5 QUESTIONS' maps common intents to methods; 'NOT FOR' lists exclusions. Also provides workflow examples and wrong-tool signals.

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

Install Server

Other Tools

Latest Blog Posts

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/ShiftinBits/constellation-mcp'

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