Skip to main content
Glama
Sign In
LiuHe

LiuHe

by wulun811
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

code_query

Locate code symbols, references, callers, and file contents in a workspace without creating a task. Use read-only modes to outline, search, map impact, or validate changes.

Instructions

Look things up fast, no task needed: where is X, who calls it, what's in this file. mode: outline|symbols|body|map|search|impact|references|callers|callees|tests|validate|capabilities. Read-only.

Input Schema

NameRequiredDescriptionDefault
dirNomap only: subdir inside workspace_dir (escapes rejected).
fileNoRequired for outline/callers/callees/impact/tests/validate; optional with symbol for references.
kindNoreferences only: filter by kind (call,import,use,assign,extends,implements; comma-separated).
lineNocallers/callees: disambiguate a line.
modeYesmap=compact paged overview (+dir drill); body=read file/symbol content without a task; search=code_search intent search; tests=find_tests candidates; validate=sandbox_validate content; capabilities=list; capability=describe by name.
nameNocapability mode: exact original tool name.
pageNomap only: page number (default 1; pass next_page).
richNobody only: include rich projection (outline).
depthNocallers/callees/impact: traversal depth.
limitNoMax rows (symbols, references).
queryNoRequired for symbols (substring); capabilities: optional name/summary filter.
cursorNocapabilities mode: pagination offset (from next_cursor).
symbolNoRequired for references; optional with file for callers/callees/impact.
optionsNoAdvanced per-mode passthrough to the original tool (e.g. callers: max_callers; impact: symbols/change_type; body: locators/context_lines). Protected keys rejected; full schema via mode=capability.
categoryNocapabilities mode: filter by category (e.g. query/audit/maintain).
page_sizeNomap only: entries per page (default 12; packing hint).
max_tokensNomap only: map token budget (default 700).
budget_hintNobody only: max chars (default 1200; 0 = full, hard-capped).
new_contentNovalidate only: candidate full content to check (no write).
workspace_dirYesRoot (abs). Any workspace path works — a fresh one is indexed automatically on first read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.29
    • changedInput schema / properties / workspace_dir / description
      Previous value: -"Root (abs)."New value: +"Root (abs). Any workspace path works — a fresh one is indexed automatically on first read."
  2. Addedv0.5.28

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses 'Read-only' and 'no task needed', which are useful traits, but it does not explain mode-specific effects, output behavior, or the workspace indexing side effect mentioned in the schema.

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?

The description is compact and front-loads the core purpose before listing modes. The mode list is long but necessary; it omits 'capability' even though the schema enum includes it, which slightly reduces precision.

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

Completeness2/5

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

This is a complex 20-parameter, multi-mode tool with no output schema and no annotations. The description does not explain return values, mode selection, pagination, or the auto-indexing behavior, leaving significant gaps for an agent to infer from the schema alone.

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 100%, so the schema already documents all 20 parameters in detail. The description lists the mode names and gives high-level lookup examples but does not add parameter meaning beyond what the schema provides.

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 a clear lookup purpose and gives concrete examples: 'where is X, who calls it, what's in this file.' It lists the available modes, making the tool's scope distinguishable from task-oriented siblings. It stops short of naming a sibling, so it is clear but not fully differentiated.

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

Usage Guidelines3/5

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

The phrase 'no task needed' implies when to use this instead of task-based tools, and 'Read-only' clarifies the safety posture. However, it does not explicitly compare against siblings like code_read, code_task, or code_search, nor does it explain when each mode should be selected.

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