Skip to main content
Glama

Swarm Tips — Solana Bounties, Lean 4 Proofs & Agent Wallet MCP

search_mcp_servers

Read-onlyIdempotent

[READ] BM25 relevance search over the ingested MCP-server catalog (official registry + awesome-lists; live size = corpus_size). Free-text capability query; results are relevance-gated then ordered by automated quality signals (source corroboration, GitHub stars, npm downloads, upstream scores, LLM confidence) — no manual curation; each hit discloses ranking_signals. Footgun: category/currency/tier filters apply WITHIN the top-400 BM25 candidates — tighten the query rather than relying on a narrow filter. Omit query to browse quality-ordered. For earn/spend opportunities use discover_opportunities.

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": "search_mcp_servers"
  }
}

Input Schema

NameRequiredDescriptionDefault
tierNoFilter by automated provenance: `"first-party"` (endpoint/repo on a swarm.tips-operated domain) or `"external"`. Unknown values return zero results.
limitNoMaximum results to return. Default 50, max 200.
queryNoFree-text capability query, BM25-ranked against server name, description, classification, and README excerpt (e.g. "solana defi swap"). Omit for browse mode (quality-ordered, filters still apply). Queries matching nothing return zero results.
categoryNoFilter by classified category (substring, case-insensitive): bounty, content, payment, infrastructure, game, social, devtools, data, other.
currencyNoFilter by currency the server deals in (e.g. "usdc", "sol").

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: results are relevance-gated then ordered by automated quality signals, no manual curation occurs, each hit exposes ranking_signals, and live corpus size is available via corpus_size. The [READ] prefix reinforces the readOnlyHint/idempotentHint annotations without contradicting them.

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?

Every sentence earns its place: algorithm, result ordering, footgun, browse mode, and sibling routing. The most important scoping facts are front-loaded, and there is no filler or restatement of the schema.

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 read-only search tool with 100% schema coverage and strong annotations, the description covers invocation modes, result quality behavior, ranking signal disclosure, and a known operational pitfall. No output schema is present, but the description gives enough about result behavior to let an agent call it correctly.

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?

The schema already documents every parameter in detail (limit default/max, tier values, query behavior, category substring matching), so the description does not need to repeat them. It adds one critical cross-parameter fact: category/currency/tier filters apply only within the top-400 BM25 candidates, which materially changes how limits and query should be set.

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 ('search'), a specific resource ('ingested MCP-server catalog'), and a precise algorithm (BM25 relevance), then explicitly routes earn/spend queries to discover_opportunities. It distinguishes itself from siblings by scope and behavior, so an agent can tell it apart without opening the schema.

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 states when to use the tool (free-text capability queries), when to use browse mode ('Omit query'), and names the alternative for earn/spend opportunities ('discover_opportunities'). The footgun about filters applying only within the top-400 BM25 candidates gives concrete operational guidance for when filters will be misleading.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.