golestan_code_mcp

Overview Schema Source Related Servers Discussions Admin

search_code

Read-only

Locate code by behavior or identifier using plain-English queries, returning ranked snippets, symbols, and wiki pages from indexed repositories.

Instructions

Find code by what it does or by name: "how are requests routed?", "where are sessions saved?", "url_for". Use this first when you do not yet know which symbol to look at. If you already know the name, use get_symbol to read it, find_callers for its call sites, or impact_of for what a change would affect. Returns up to limit hits (default 10), best first. Each hit has the repository, path, symbol name, kind, language, line range, a snippet of the symbol's opening lines, and the scores behind its rank: the score, the relevance (the score before feedback), the feedback boost, the keyword rank and the semantic rank (null when that side did not find it). The feedback field is the boost from earlier sessions marking the result used: at most 0.2 (20 percent), fading over 30 days; relevance is the score before it. Keyword and semantic search are fused, and the definitions of an exact identifier come first. A hit of kind page is a wiki page about a whole module: its name is the page name, its path is the module's directory, its line range is null and its state says whether it is fresh or stale; read it with read_wiki. A hit of kind fact is something an earlier session worked out about the code at its path; recall lists all of them. Next step: call get_symbol with a hit's name to read its full source, or read_wiki with a page hit's name.

Input Schema

Name	Required	Description
`repo`	No	Search only this registered repository, for example flask. list_repositories gives the valid names. Default: all repositories.
`limit`	No	How many hits to return, 1 to 50. Default 10.
`query`	Yes	A question in plain English (how are requests routed) or an identifier (url_for). Taken literally; there is no query syntax.
`feedback`	No	Raise results that earlier sessions used, by at most 20 percent of their score. false ranks by relevance alone, exactly as with no feedback recorded. Default true.
`language`	No	Search only files of this language: one of batch, c, cpp, csharp, css, go, html, ini, java, javascript, json, kotlin, markdown, php, proto, python, rst, ruby, rust, shell, sql, swift, text, toml, tsx, typescript, yaml. Default: all languages.

Output Schema

Name	Required	Description	Default
`reason`	Yes
`status`	Yes
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.4.2Oct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, and the description is consistent with a read-only search. Beyond that, it discloses ranking mechanics, feedback fading over 30 days, fused keyword/semantic search, special hit kinds (page and fact), and state semantics for wiki pages.

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 front-loaded with purpose and usage, then details results and next steps. It is somewhat long and repeats the feedback/relevance relationship and default limit that the schema already covers, so it is not maximally concise.

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 complex search tool with an output schema, the description supplies the semantic context an agent needs: ranking fields, feedback behavior, page/fact hit meanings, stale/fresh state, and next steps. Nothing essential for correct invocation or interpretation is missing.

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 schema already documents all five parameters. The description adds useful meaning for feedback behavior (max 20 percent boost, fading over 30 days, relevance as pre-feedback score) and limit/return behavior, though it does not add much for repo or language beyond the schema.

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 and resource: 'Find code by what it does or by name,' with concrete query examples. It explicitly distinguishes itself from siblings by saying to use it first when the symbol is unknown, and routing known-name lookups to get_symbol, find_callers, or impact_of.

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 when-to-use guidance: use this first when you do not yet know which symbol to look at. It also names the alternatives for known symbols, call sites, and impact analysis, plus concrete next steps after a hit.

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

Deploy Server