treeweft-mcp

Official

Overview Schema Source Related Servers Discussions Admin

search_code

Find code by meaning, not just exact strings. Search across indexed repositories to understand flows, plan changes, and locate implementations by behavior.

Instructions

PRIMARY code-search tool — use FIRST for any question about how indexed code works, to plan a change, trace a flow, or find an implementation by behavior. Prefer this over grep/Read for indexed repos: grep needs exact strings, this finds code by meaning. Embeds the query, vector-searches Milvus, expands via Neo4j graph neighbors (callers/callees/imports/inheritance) and community summaries, reranks, returns chunks with file_path, start_line, end_line, snippet, score. Each chunk carries a citation field (e.g. 'repo@sha12:path') and the response includes a top-level sources map with commit_sha and permalink_base per source for building file-level permalinks. top_k defaults to 5 (the benchmarked sweet spot) — raise it only when a first search shows the answer spans many files. Optional filter: language (e.g. 'python'). SCOPE IS REQUIRED: pass source_id (from list_indexed_sources) or path_prefix (e.g. '/repo/src/') to scope to one repo, OR cross_repo=true to search the whole multi-repo index — exactly one, not both, or the search is rejected. Set check_staleness=true to add an is_stale flag per source (does live git HEAD resolution — slightly slower). response_mode (opt-in, default 'full'): 'facet' returns ranked metadata + a one-line header per hit with NO code body (cheaper — then fetch ranges with read_file); 'summary_tail' keeps the top-2 snippets and replaces lower-ranked bodies with their indexed one-line summary. Returns compact markdown by default (~20% fewer tokens); pass response_format='json' to get the structured dict instead (for programmatic callers).

Input Schema

TableJSON Schema

Name	Required	Default
`query`	Yes
`top_k`	No
`language`	No
`use_hyde`	No
`source_id`	No
`cross_repo`	No
`use_hybrid`	No
`path_prefix`	No
`rerank_pool`	No
`adaptive_topk`	No
`response_mode`	No	full
`strip_imports`	No
`check_staleness`	No
`response_format`	No	markdown
`adaptive_topk_gap`	No
`use_graph_scoring`	No
`use_summary_vector`	No
`query_class_payload`	No
`include_community_summaries`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2026.9.23Sep 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations to provide a safety profile, the description carries the full burden and does so thoroughly: it explains the embedding/vector-search/graph-expansion pipeline, what fields chunks contain, citation format, response modes, staleness checking with a performance cost, and output format. No annotation contradiction exists.

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

Conciseness5/5

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

The description is long but every sentence earns its place; it is front-loaded with the most important usage information and then layers supporting detail. Dense structure with scoping rules and response modes, but no filler or repetition.

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

Completeness4/5

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

Coverage is strong for common use cases: scope requirements, response modes, citations, and performance trade-offs are all present, and an output schema exists so return-value details are redundant. It loses one point because the many advanced schema parameters remain undocumented and there is no explicit distinction from the sibling search_code_enhanced tool.

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?

The description adds meaning to several core parameters (query, top_k, language, source_id, path_prefix, cross_repo, check_staleness, response_mode, response_format) beyond a schema that has 0% description coverage. However, 10+ parameters (use_hyde, use_hybrid, rerank_pool, adaptive_topk, strip_imports, include_community_summaries, etc.) are left completely unexplained, which is a clear gap for a tool with 19 parameters.

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 states a precise purpose: semantic code search over an indexed repository, returning ranked code chunks. It explicitly differentiates itself from grep/Read and establishes itself as the PRIMARY search tool, making the resource and behavior unmistakable.

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?

It gives explicit when-to-use guidance ('use FIRST for any question about how indexed code works...') and names alternatives with the condition that selects them ('Prefer this over grep/Read for indexed repos: grep needs exact strings'). It also tells the agent when to raise top_k and warns against invalid scope combinations.

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