find_in_all_binariesSearch strings or function names across all analyzed binaries to find shared features or common code traits in a sample set. Use it for cross-sample matching beyond single-file analysis.
跨所有已分析的二进制搜索（旧的单文件 MCP 做不到的核心能力）。
kind: "string" 或 "function"。query 为子串（不区分大小写）。 典型用途：在一批样本中找共同的函数名/字符串特征。最多扫描最近分析的 200 个二进制。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| query | Yes | ||
| limit_per_binary | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose useful traits: case-insensitive substring matching and a scope cap of the 200 most recently analyzed binaries. It omits return format, aggregation behavior, and any permission/error context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose in the first clause and stays compact with no wasted sentences. The parenthetical about the old MCP is slightly self-promotional but brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, a use case, two params, and the 200-binary scan cap, which is adequate for a 3-param read tool with no annotations or output schema. However, it leaves the limit_per_binary behavior and the shape of returned results unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It usefully defines kind ('string' or 'function') and query (case-insensitive substring), but says nothing about limit_per_binary (default 20), leaving one of three parameters undocumented in both schema and text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: search across all analyzed binaries, and contrasts it with the 'single-file MCP' it supersedes. It does not name the sibling search_functions_by_name, but the cross-binary scope is clearly distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives one typical use case (finding shared function names/string features across a batch of samples), which implies when to reach for it. It never explicitly states when NOT to use it or names the single-binary alternative, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.