Skip to main content
Glama
Sign In
mcp-code

mcp-code

by itgiup
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_code

Search code files for a query string and return file, line, and content matches to help locate references and inspect code across a read-only project.

Instructions

Tìm chuỗi trong code, trả về 'file:dòng: nội dung'.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_code"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNo.
queryYes
max_resultsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full disclosure burden, yet it only discloses the return format. It says nothing about whether matching is case-sensitive or regex-based, whether the search recurses into subdirectories, how binary or large files are handled, or what happens when no match is found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is front-loaded and free of filler, but its brevity comes at the cost of under-specification rather than economy. There is no structure to organize the missing behavioral and parameter detail.

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?

The existence of an output schema excuses explaining return values, but an unannotated search tool with three undocumented parameters still needs to state matching semantics and path scoping. Those gaps leave the definition materially incomplete for correct invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, and it does not. 'query' is only loosely implied by 'search string'; the meaning of 'path' (defaulting to '.') and 'max_results' (default 50) is never explained, including whether max_results truncates results silently.

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 specific verb and resource (search for a string in code) and names the output shape 'file:line: content', which is more than a restatement of the name. It does not distinguish this tool from siblings list_dir or read_file, so it falls short of a 5.

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

Usage Guidelines2/5

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

No guidance is given on when to prefer this over read_file or list_dir, nor on any prerequisites such as searching only within an allowed path. The agent must infer usage entirely from the tool name.

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