Skip to main content
Glama
Sign In
codelattice

codelattice

by aiulms
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

codelattice_symbol

Read-onlyIdempotent

Query symbols, definitions, callers, callees, and call chains in a single project root to map code relationships and flow; submit large analyses as tracked jobs.

Instructions

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "codelattice_symbol"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoFilter by symbol kind
modeNoQuery mode. call_chains returns readable static paths; job_status/job_detail use jobId only after a job response.search
nameNoSymbol name (required for context, callers, callees modes)
pageNojob_detail page index
rootNoAbsolute path to project root. Required for search/context/callers/callees/graph/job; not needed for job_status/job_detail.
depthNoCall depth for callers/callees
jobIdNoRequired for job_status and job_detail; root is not required for these modes
limitNoMax results
queryNoSearch query (for search mode)
compactNo
languageNoauto
pageSizeNojob_detail page size
includeSnippetNoFor context/call modes: include source snippets. Defaults to false in compact mode and true in full mode.
snippetContextNoLines of context around source snippets; compact mode caps this to 3.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.17.0-beta.3
    • changedInput schema / properties / language / enum
      Previous value: -[
-  "rust",
-  "cangjie",
-  "arkts",
-  "typescript",
-  "javascript",
-  "c",
-  "cpp",
-  "python",
-  "shell",
-  "auto"
-]New value: +[
+  "rust",
+  "cangjie",
+  "arkts",
+  "typescript",
+  "javascript",
+  "c",
+  "cpp",
+  "python",
+  "shell",
+  "objc",
+  "auto"
+]
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower, yet the description still adds the prerequisite that a root must be selected first and the stateful ordering constraint that jobId is only usable after a job response. The job submission flow with progress tracking is behavior the annotations do not convey. It does not describe cost, latency, or job lifetime, so it is not exhaustive.

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?

Three sentences, each doing distinct work: scope, mode routing, then the large-project job path. The scope constraint is front-loaded. The mode enumeration is dense but not padded, and no sentence is redundant.

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

Completeness4/5

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

For a 14-parameter, 10-mode tool with no output schema, the description covers the main decision tree, the root prerequisite, and the multi-step job workflow, which is what an agent needs to start. Gaps remain around graph semantics and job_cancel, which appear in the enum but are never explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 86%, so the schema already documents mode, root, name, jobId, and pagination requirements per mode. The description adds only routing meaning (which mode fits which intent) rather than parameter-level detail such as depth semantics or compact/snippet interaction. The 3 baseline applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource precisely (symbol-level queries scoped to a SINGLE project root after root selection) and enumerates the query modes, so an agent knows this is the code-intelligence entry point. It does not explicitly distinguish itself from the listed sibling tools (cache/project/workspace), but the mode taxonomy is concrete enough to identify what the tool does.

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?

It gives explicit routing rules: search/context when a symbol or name is known, callers/callees/call_chains for relationships and flow, and mode=job for large projects followed by job_status and job_detail. That is real when-to-use guidance across the modes. It falls short of a 5 because it never says when to avoid this tool in favor of the sibling tools, and it omits guidance for graph and job_cancel.

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

Deploy Server

Other Tools