Constellation
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONSTELLATION_ACCESS_KEY | Yes | API key required for all requests to the Constellation service. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| code_intelA | 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: 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 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, IMPORTANT: The The optional |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| api-types | TypeScript type summaries for every Code Mode API method in one document (~20KB). Prefer constellation://types/api/{methodName} when you need only one method. |
| code-mode-guide | Full method reference, response shapes, composition recipes, and error recovery patterns. Read this when writing code_intel queries. |
| metrics | Runtime metrics: execution counts, durations, error rates, and API call patterns. |
| searchSymbols types | Type definitions for api.searchSymbols() |
| getSymbolDetails types | Type definitions for api.getSymbolDetails() |
| getDependencies types | Type definitions for api.getDependencies() |
| getDependents types | Type definitions for api.getDependents() |
| findCircularDependencies types | Type definitions for api.findCircularDependencies() |
| traceSymbolUsage types | Type definitions for api.traceSymbolUsage() |
| getCallGraph types | Type definitions for api.getCallGraph() |
| impactAnalysis types | Type definitions for api.impactAnalysis() |
| findOrphanedCode types | Type definitions for api.findOrphanedCode() |
| getArchitectureOverview types | Type definitions for api.getArchitectureOverview() |
| ping types | Type definitions for api.ping() |
| getCapabilities types | Type definitions for api.getCapabilities() |
| Method Reference | Method lookup table, disambiguation guide, and parameter reference (~1,200 tokens) |
| Response Shapes & Recipes | Response contract, top 3 response shapes, and workflow recipes (~1,000 tokens) |
| Common Mistakes & Recovery | Common mistakes, empty result debugging, and error recovery patterns (~800 tokens) |
TDQS
Scored across 1 tool
With a single tool, there is no cross-tool ambiguity to resolve, and the description explicitly draws a clear boundary against Grep/Glob/Read (structure vs text search). The only residual overlap is internal (getDependents vs getCallGraph vs traceSymbolUsage), which the description addresses but does not fully resolve without running api.listMethods().
A single name cannot be internally inconsistent, and 'code_intel' is a clean, readable snake_case identifier. It is a noun phrase rather than a verb_noun pattern, so there is no predictable action convention to anchor on, but nothing is violated.
The one-tool design is intentional (a code-execution entry point fronting a multi-method api.* surface), which is defensible for this domain. However, as presented the server exposes exactly one thinly-described tool whose real capabilities are hidden behind api.listMethods()/api.help(), making the surface feel thin and requiring a discovery round-trip.
The stated domain — graph-backed code intelligence — is well covered: symbol search, dependencies/dependents, call graph, usage tracing, impact analysis, orphan detection, and architecture overview. Gaps are minor (e.g. no explicit symbol-level diff/change-scope or test-impact mapping), and read-only scope is appropriate for an intelligence tool.