codelattice
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| codelattice_workflowA | AI intent router and orchestration layer. Use this FIRST when unsure which CodeLattice tool or root to call. Use ask for natural-language routing, explore for progressive project/workspace orientation, diagnose_issue for symptoms, and before_edit only once you have a concrete target. |
| codelattice_projectA | Project-level analysis for a SINGLE project root. Use this for structure, entry points, components, and static risk orientation after root selection. Prefer quick first, standard for module/risk review, deep for detailed static evidence, diagnose for issue localization, and job modes for large repos. For monorepo/workspace roots, use codelattice_workspace or workflow explore first, then switch to a manifest-backed sub-project root. |
| codelattice_symbolA | Symbol-level queries for a SINGLE project root after root selection. Use search/context when you know a symbol or name; use callers/callees/call_chains for relationships and flow. For large projects, use mode=job to submit an engine-backed analysis job with progress tracking, then mode=job_status and mode=job_detail. |
| codelattice_change_reviewA | Concrete pre/post edit review for a SINGLE project root when the target is known. Use impact before editing a symbol/path, native_review after local diffs, breaking_change for public API concerns, and job modes for large repos. If the target is unclear, use codelattice_workflow first. |
| codelattice_workspaceA | Workspace/monorepo analysis for project boundaries, dependency graph, cross-project impact, overview, or engine-backed job mode. Use this on workspace roots; use codelattice_project only after selecting a manifest-backed project root. |
| codelattice_cacheA | Cache management (optional performance layer, NOT availability gate): status, clear, explain, prewarm. Disabled persistent cache does NOT prevent fresh static analysis — CodeLattice works fine without it. Use mode=status to check memory and persistent cache state. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
This server cannot be deployed
TDQS
Scored across 6 tools
Each tool targets a distinct layer: workflow routing, project analysis, symbol-level queries, change review, workspace analysis, and cache management. The boundaries are mostly clear from the descriptions, with only mild overlap between project/workspace/change-review for monorepo roots and some project-level diagnosis modes.
All tool names follow the consistent codelattice_ + domain noun snake_case pattern, and there are no mixed conventions or style breaks. The names are highly predictable across the set, making the tool surface easy to scan and predict.
Six tools is an appropriate size for this server; the surface is neither bloated nor too sparse. Each tool earns its place and internally organizes multiple modes, avoiding fragmentation into dozens of smaller endpoints, and each tool covers a meaningful domain.
The surface covers the main analysis workflow: orienting via workflow, analyzing projects, querying symbols, reviewing changes, handling workspaces, and cache management. Minor gaps exist around explicit cross-project free-text search or direct root enumeration outside the workflow router, but agents can still complete realistic workflows without dead ends.