Skip to main content
Glama

Find Code

find_code
Read-onlyIdempotent

Search the user's project when you do not know which file holds something. Ranked hits; the definition of that name comes first, not a call site like const user = await name(). ALWAYS call instead of guessing a path. ALWAYS call when the user says where is, find, who uses, usages, or rename X everywhere. If they named Zephex or MCP and asked to find something in their code, this is the tool. Prefer this over native Grep when location is unknown — results are ranked and hand off to read_code. intent=symbol — they named a function/class/type. intent=concept — a topic; pass also_try synonyms (rate limit + throttle). intent=snippet — they pasted a line from the editor. intent=everywhere — every occurrence before a rename (whole_word:true). Works on any local project on their machine, any language. Local/stdio: omit path to search the editor cwd, or pass path as their project folder. No disk: inline_files, or a public GitHub URL. Returns summary, data.matches, files_hit, next_calls. Then call read_code with target set to that symbol name, or mode=file/outline with files=[path]. Not for stack/scripts (get_project_context). Not when you already have the exact file and symbol (read_code). Example: find_code({ query: "validateToken", intent: "symbol" }). Rename: find_code({ query: "OldName", intent: "everywhere", whole_word: true }). Topic: find_code({ query: "encrypt", intent: "concept", also_try: ["cipher", "AES"] }). If the first hit is the wrong file, follow next_calls or tighten with file_pattern / include=code. Do not fall back to guessing a path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoThe user's project folder. Local/stdio: omit to use editor cwd, or pass the absolute folder. Hosted: public GitHub URL or inline_files.
queryYesRequired. Text to find: pasted editor line, symbol name (validateToken), or topic keyword (encrypt).
intentNoSearch mode. snippet=paste exact line. symbol=find definition. concept=topic hunt. everywhere=all hits before rename.
includeNoLimit file types. code=src. docs=md/readme. config=json/yaml. data=sql/prisma. all=default.
also_tryNoExtra keywords merged in parallel. concept=topic synonyms. everywhere=rename variants (crystal, CRYSTAL, crystal-app).
whole_wordNoWith intent everywhere. true = whole word only (Crystal not Crystalline). Use before renames.
file_patternNoCustom glob; overrides include. Examples: src/**/*.ts, **/*.md.
inline_filesNoHosted MCP only: {"path/to/file.ts": "file contents"}. Use when path disk is unavailable.
case_sensitiveNotrue = match exact casing (Crystal vs crystal). Default false.
response_formatNoconcise=line preview per hit. detailed=full function/class block when AST available.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / path / description
      Previous value: -"Project folder to search. Local MCP: absolute path (/Users/jane/myapp). Hosted MCP: public GitHub URL or inline_files."New value: +"The user's project folder. Local/stdio: omit to use editor cwd, or pass the absolute folder. Hosted: public GitHub URL or inline_files."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds significant behavioral context: results are ranked, definitions first, hand-off to read_code, rate limiting/throttle for concept intent, and output details (summary, matches, files_hit, next_calls). No contradiction with annotations.

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 long but well-structured with a clear intro, usage rules, parameter explanations, and examples. It is front-loaded with purpose. While verbose for a simple tool, the complexity of 10 parameters justifies the length. Could be slightly trimmed but still effective.

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

Completeness5/5

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

Given 10 parameters, no output schema, and complex behavior (intents, rate limits, hosted vs local, rename workflow), the description fully covers what the agent needs: when to use, how to construct queries, what to expect in results, and what to do next (call read_code). It even addresses edge cases like inline_files and next_calls.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description goes beyond by providing examples for each intent, explaining whole_word usage with rename, and detailing also_try synonyms. This adds meaning but some parameter details are also in schema descriptions.

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?

The description clearly states 'Search the user's project when you do not know which file holds something.' It uses strong action verbs and differentiates from siblings like read_code (exact location) and get_project_context (stack/scripts).

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?

Explicitly says when to use ('ALWAYS call instead of guessing a path', 'ALWAYS call when the user says where is, find, who uses, usages, or rename'), when not to use ('Not for stack/scripts (get_project_context)', 'Not when you already have the exact file and symbol (read_code)'), and provides a clear alternative (read_code).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct domain: URL auditing, package checking, tests, architecture, code search, project context, planning, memory, code reading, and expert guides. Descriptions are extremely detailed and explicitly state when not to use each tool, leaving no ambiguity.

Naming Consistency4/5

Most tools follow the verb_noun snake_case pattern (audit_headers, check_package, check_test, explain_architecture, find_code, get_project_context, read_code), but project_memory (noun_noun) and Zephex_dev_info (brand_noun) deviate, and keep_thinking uses a gerund instead of a noun. The pattern is strong but not perfectly uniform.

Tool Count5/5

10 tools is well-scoped for a comprehensive development assistant. Each tool serves a clear purpose without redundancy, covering security, package management, testing, code understanding, project context, planning, memory, and expert knowledge. The count is neither too few nor excessive.

Completeness4/5

The tool surface covers a wide range of development analysis tasks: security auditing, package checking, test running, architecture mapping, code search, project context, planning, memory, code reading, and developer guides. Minor gaps include the lack of direct code editing or project execution/build tools, but the server appears intentionally focused on read-only information and planning.

Resources