lowdown-proxy

Find MCP servers by observed facts

find_servers

Read-onlyIdempotent

List public MCP servers by facts Lowdown observed, when you do not have a server name yet. Use does to find servers by what they do (words in the Registry name or tool names, e.g. 'postgres'). Filter by the latest daily check (e.g. state 'answered' = answered initialize and tools/list without credentials), days answered in the last 30, how long the tool list has been unchanged, tool count, Registry status and package state; sort by one key. No score or ranking: order is only the chosen sort key. Each result carries a lookup URL; call get_lowdown with its name for the full record. Tool lists are recorded from 2026-10-20, so a long stable_days returns nothing yet.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_servers"
  }
}

Input Schema

Name	Required	Description
`q`	No	Part of the Registry name, e.g. 'github' or 'io.github.user'
`does`	No	What the server does: 1-3 words separated by spaces, e.g. 'postgres' or 'github issue'. Every word must appear in the Registry name or in a tool name from the latest observed tool list; results show matched_in
`sort`	No	Sort key (default name). tools = tool count, answering = days answered, stable = tool list unchanged longest, newest, updated, changed, release
`limit`	No	1-50, default 20
`order`	No	Default depends on sort
`state`	No	Latest daily check result (only servers checked in the last 2 days). 'answered' = answered tools/list with no credentials
`offset`	No	For the next page, use next_offset from the previous answer
`package`	No	ok = declared packages with no deprecated/yanked/404 latest; flagged = at least one; none = no declared packages
`registry`	No	MCP Registry status
`tools_max`	No	Maximum tool count
`tools_min`	No	Minimum tool count
`stable_days`	No	Current tool list first observed at least this many days ago
`answered_days`	No	Minimum daily checks in the last 30 days that answered tools/list

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

addedInput schema / properties / does

Added value: +{
+  "description": "What the server does: 1-3 words separated by spaces, e.g. 'postgres' or 'github issue'. Every word must appear in the Registry name or in a tool name from the latest observed tool list; results show matched_in",
+  "maxLength": 92,
+  "minLength": 2,
+  "type": "string"
+}

AddedOct 31, 2026

TDQS

A4.6/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, so the bar is lower; the description still adds real behavior: ordering is strictly the chosen sort key with no relevance score, every result carries a lookup URL for follow-up, and tool-history data only starts 2026-10-20 so stable_days filters will return nothing yet. It stops short of describing result-field shape or pagination behavior beyond the schema's offset note.

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?

Dense and front-loaded: identification, alternative routing, filter semantics, and the data caveat all arrive in order. Slightly marred by a clumsy opening clause ('List ... by facts Lowdown observed, when you do not have a server name yet') and a long compound filter sentence, but no filler.

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 13-parameter filter tool with no output schema, the description is sufficient: it names the follow-up tool, explains the matched_in result hint, states the ordering contract, and warns about the dataset start date that would otherwise produce confusing empty results.

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 baseline is 3; the description still adds semantic glue, notably that 'answered' means initialize and tools/list succeeded without credentials and that words in does must match the Registry name or a tool name. The stable_days data-coverage caveat is meaningful guidance the schema alone does not convey.

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 ('List public MCP servers by facts Lowdown observed') plus a scope condition ('when you do not have a server name yet') that distinguishes it from get_lowdown. It also explicitly denies ranking ('No score or ranking'), which tells an agent what kind of result set to expect.

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 an explicit entry condition ('when you do not have a server name yet'), names the sibling that takes over afterwards ('call get_lowdown with its name for the full record'), and explains the does-parameter intended usage with an example. The stable_days caveat about the 2026-10-20 recording start is a genuine when-not clause.

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

All lowdown-proxy tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.