lynx-mcp

Overview Schema Source Related Servers Discussions Admin

deep_search

Read-onlyIdempotent

Run multiple search phrasings when initial results are weak or empty, then return the first set passing quality thresholds or the strongest available with a warning.

Instructions

Escalation for when search came back weak or empty: runs 2-4 genuinely different phrasings of the same need and returns the first set that passes the quality threshold, or the strongest weak set with a warning. Slower than search; do not start here.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	dense \| sparse \| hybrid (single source only).
`top_k`	No	Max results; default from config.
`source`	No	Source name, list of names, or omit for all sources, fused.
`queries`	Yes	2-4 genuinely different phrasings, tried in order.
`file_glob`	No	Restrict to paths matching this glob, e.g. `*.cs`.
`min_score`	No	Quality threshold override.
`extensions`	No	Restrict to these extensions, e.g. ['.cs'].
`min_results`	No	Minimum results for a variant to count as strong.
`path_contains`	No	Restrict to paths containing this substring.
`return_all_variants`	No	Include per-variant diagnostics (single source only).

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedv1.9.0Sep 6, 2026

changedInput schema / properties / extensions / description

Previous value: -"Restrict results to these file extensions, e.g. `['.cs', '.shader']`."New value: +"Restrict to these extensions, e.g. ['.cs']."

removedInput schema / properties / extensions / title
```
Removed value: -"Extensions"
```

changedInput schema / properties / file_glob / description

Previous value: -"fnmatch glob to restrict results by path/filename, e.g. `*.cs` or `**/Editor/*`."New value: +"Restrict to paths matching this glob, e.g. `*.cs`."

removedInput schema / properties / file_glob / title
```
Removed value: -"File Glob"
```

changedInput schema / properties / min_results / description

Previous value: -"Override the minimum number of results a variant must return to be considered strong."New value: +"Minimum results for a variant to count as strong."

removedInput schema / properties / min_results / title
```
Removed value: -"Min Results"
```

changedInput schema / properties / min_score / description

Previous value: -"Override the weakness threshold: a variant's results must beat this score to count as strong."New value: +"Quality threshold override."

removedInput schema / properties / min_score / title
```
Removed value: -"Min Score"
```

changedInput schema / properties / mode / description

Previous value: -"Retrieval mode override (single-source only): 'dense', 'sparse', or 'hybrid'. Defaults to the server's configured mode."New value: +"dense | sparse | hybrid (single source only)."

removedInput schema / properties / mode / title
```
Removed value: -"Mode"
```

changedInput schema / properties / path_contains / description

Previous value: -"Keep only results whose file path contains this substring."New value: +"Restrict to paths containing this substring."

removedInput schema / properties / path_contains / title
```
Removed value: -"Path Contains"
```

changedInput schema / properties / queries / description

Previous value: -"2-4 genuinely different phrasings of the same need (different angles, not paraphrases), tried in priority order."New value: +"2-4 genuinely different phrasings, tried in order."

removedInput schema / properties / queries / title
```
Removed value: -"Queries"
```

changedInput schema / properties / return_all_variants / description

Previous value: -"If true, include per-variant diagnostics in the response (single-source only)."New value: +"Include per-variant diagnostics (single source only)."

removedInput schema / properties / return_all_variants / title
```
Removed value: -"Return All Variants"
```

changedInput schema / properties / source / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / source / description

Previous value: -"Source name from `list_sources`. Omit to use the default: all sources for `search`/`deep_search` (RRF-fused), or the single applicable source for the others."New value: +"Source name, list of names, or omit for all sources, fused."

removedInput schema / properties / source / title
```
Removed value: -"Source"
```

changedInput schema / properties / top_k / description

Previous value: -"Maximum number of results to return. Defaults to the configured value."New value: +"Max results; default from config."

removedInput schema / properties / top_k / title
```
Removed value: -"Top K"
```
removedInput schema / title
```
Removed value: -"_deep_searchArguments"
```

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "_deep_searchOutput",
-  "type": "object"
-}New value: +null

First observedv1.5.1Jun 15, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful execution context: multiple phrasings are tried in order, a quality threshold gates acceptance, and a weakened result set includes a warning. It also mentions the performance cost ('slower than `search`').

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?

Two sentences convey purpose, trigger condition, execution behavior, return behavior, and performance trade-off. The key escalation framing is front-loaded, and every clause earns its place.

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?

For a tool with 10 parameters and no output schema, the description covers the essential call decision, execution behavior, and return outcome. It could be more explicit about the exact return format for the 'warning' case, but the core completeness is strong.

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 coverage is 100%, so the input schema already documents all parameters. The description reiterates the '2-4 genuinely different phrasings' concept for `queries`, which is already in the schema, but adds no new parameter-level meaning beyond that.

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 names a specific verb and resource: it is an escalation for `search`, runs 2-4 different phrasings, and returns the first set that passes a quality threshold or the strongest weak set with a warning. This clearly differentiates it from the sibling `search` and makes its role 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?

The description explicitly states when to use it ('when `search` came back weak or empty'), when not to start with it ('do not start here'), and names the alternative (`search`). This leaves no ambiguity about the escalation path.

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

Deploy Server

deep_search

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools