Skip to main content
Glama

Search code

search
Read-onlyIdempotent

Find code by meaning or keyword and return ranked results with file paths and line ranges, so you can locate definitions and answer without opening files.

Instructions

Find code by meaning or by keyword: "where is...", "how does... work", "find the code that...", "what handles...". Returns ranked results with file path and line range. The first three carry the whole function or class, so you can answer without opening the file. A query can hold exact names (parse_config RetryPolicy): their definitions come first. For the whole code of a result that is cut, call find_symbol with its name. Source files rank before test files unless the query asks for tests. For an exact string or a file you already know, your built-in grep or read is just as good.

Input Schema

NameRequiredDescriptionDefault
limitNoMax results (default 10)
queryYesWhat to find, in plain words or code terms. Exact names (parse_config) first

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.1.0
    • removedInput schema / properties / language
      Removed value: -{
      -  "default": "",
      -  "description": "Filter by language (e.g. 'python')",
      -  "type": "string"
      -}
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default 10, max 100)"New value: +"Max results (default 10)"
    • removedInput schema / properties / live_grep
      Removed value: -{
      -  "default": false,
      -  "description": "Force live-grep fallback (rg/grep)",
      -  "type": "boolean"
      -}
    • removedInput schema / properties / mode
      Removed value: -{
      -  "default": "hybrid",
      -  "description": "Search mode: 'hybrid', 'vector', or 'bm25'",
      -  "type": "string"
      -}
    • changedInput schema / properties / query / description
      Previous value: -"Natural language or code query (e.g. 'retry logic')"New value: +"What to find, in plain words or code terms. Exact names (parse_config) first"
    • removedInput schema / properties / rerank
      Removed value: -{
      -  "default": true,
      -  "description": "FlashRank reranking (default True)",
      -  "type": "boolean"
      -}
    • removedInput schema / properties / symbol_type
      Removed value: -{
      -  "default": "",
      -  "description": "Filter by type (e.g. 'function', 'class')",
      -  "type": "string"
      -}
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare read-only/idempotent, and the description adds genuinely useful beyond-schema behavior: ranked results with file path and line range, the top three containing whole definitions, and source-before-test ranking. It stops short of saying how ranking is scored or when the index may be stale, which would matter for trust.

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?

Front-loaded with purpose then escalating detail (result shape, query syntax, fallbacks), and every sentence carries an actionable rule. Slightly long, and the exact-names-first point is stated twice (prose and again in the schema-echoed phrasing at the end).

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?

For a 2-parameter search tool with an output schema, this covers everything an agent needs: how to phrase a query, what a result contains, how many are trustworthy without opening files, and which sibling to reach for otherwise.

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 the baseline is 3, but the description adds meaning the schema lacks: multi-name queries ('parse_config RetryPolicy') resolve exact definitions first. The `limit` parameter is left entirely to the schema, which is fine.

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?

Opens with a specific verb+resource ('Find code by meaning or by keyword') and immediately grounds it in real query phrasings. It explicitly separates itself from siblings by naming `find_symbol` for truncated results and built-in grep/read for exact strings.

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 concrete when-to-use trigger phrases, states the condition for switching to `find_symbol` (result is cut), and explicitly says when a built-in tool is just as good. Both an alternative tool and an exclusion are named.

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