Skip to main content
Glama

search_strings

Idempotent

Search recognized ELF strings by literal substring or regular expression to locate indicators in native Android libraries during reverse engineering.

Instructions

Search recognized ELF strings using a literal substring or regular expression.

Input Schema

NameRequiredDescriptionDefault
modeNoliteral
patternYes
documentNo
case_sensitiveNo
analysis_project_idNoOptional investigation to retain this tool result in. Does not prove target identity or causal relationships.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

B3.2/5.0
Behavior2/5

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

Annotations say readOnlyHint=false, idempotentHint=true, and destructiveHint=false, but the description frames the operation purely as a search and never discloses the retention side effect implied by analysis_project_id. It adds useful mode context but does not explain the non-read-only behavior an agent should be aware of. This is an omission rather than a direct contradiction.

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 a single front-loaded sentence with no filler. Every phrase contributes to the core operation: search, recognized ELF strings, and literal/regex matching.

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?

For a five-parameter search tool with 20% schema description coverage and no output schema, one sentence leaves important context unstated: document scoping, case sensitivity, and the non-read-only retention behavior. It is enough to attempt a basic pattern search but not enough to fully understand parameter choices or side effects.

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?

Schema description coverage is only 20%, so the description must compensate. It explains the literal-versus-regex distinction for pattern/mode, which adds meaning beyond the schema. But it leaves document, case_sensitive, and analysis_project_id unexplained, with the retention behavior documented only in the schema.

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 recognized ELF strings. It also specifies the search mechanism as literal substring or regular expression. It does not explicitly differentiate itself from siblings such as list_strings, so it is clear but not fully sibling-aware.

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

Usage Guidelines3/5

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

The phrase 'using a literal substring or regular expression' implies this tool is for targeted string searches rather than bulk listing. However, it gives no explicit when-to-use guidance, no exclusions, and no named alternatives like list_strings. Usage is therefore only implied.

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