Skip to main content
Glama

codelattice_project

Read-onlyIdempotent

Analyze a single project root to map structure, entry points, components, and static risks, with modes for quick orientation, module review, deep evidence, issue diagnosis, and large-repo jobs.

Instructions

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.

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_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoAnalysis mode. quick = orientation/read-first/top risks; standard = component and review-first map; deep = full static detail; diagnose = issue localization from symptom/error/query; job = non-blocking large project analysis.overview
pageNojob_detail page index
rootNoAbsolute path to project root. Required for overview/quick/standard/deep/quality/insights/diagnose/ai_context/full/job; not needed for job_status/job_detail.
jobIdNoRequired for job_status and job_detail; root is not required for these modes
queryNoKeyword query for diagnose mode
detailNoOutput detail tier for compact project responses. medium adds bounded dependency/framework digest and top navigation hints without returning the full graph.compact
compactNo
symptomNoBug symptom or user report for diagnose mode
languageNoauto
pageSizeNojob_detail page size
parallelNoUse parallel engine execution for job mode when available
errorTextNoObserved error text/log excerpt for diagnose mode
changedPathNoKnown changed or suspicious file path for diagnose mode

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

A4.3/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new context beyond them: the analysis is static (risk 'orientation', 'static evidence'), and job modes are framed as the non-blocking path for large repos. It stops short of saying how job modes are polled or what a 'manifest-backed sub-project root' verification looks like.

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 front-loaded sentences: scope first, then mode selection, then the monorepo escape hatch. Dense but every clause carries routing information; the final sentence is long but not padded.

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 13-parameter, mode-driven tool with no output schema, the description covers the critical decision points: which root, which mode, and when to defer to a sibling. Minor gap: it doesn't hint at response shape or the compact/detail tiering trade-off, though the schema describes those parameters.

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 coverage is 85%, so the schema already documents mode tiers, root, jobId, query, symptom, and paging. The description's mode guidance ('quick = orientation', 'diagnose = issue localization') largely restates the mode parameter's own schema description, adding sequencing advice rather than new per-parameter meaning.

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+resource ('Project-level analysis') and immediately bounds the scope to a SINGLE project root, then names the outputs it produces (structure, entry points, components, static risk orientation). It explicitly contrasts itself with codelattice_workspace for monorepo roots, so an agent can pick between them without opening either schema.

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?

Gives explicit routing rules: 'Prefer quick first, standard for module/risk review, deep for detailed static evidence, diagnose for issue localization, and job modes for large repos.' It also states the when-not condition and the alternative ('For monorepo/workspace roots, use codelattice_workspace or workflow explore first'), plus the prerequisite of a manifest-backed sub-project root.

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