Skip to main content
Glama
Sign In
Wicked MCP server

Wicked MCP server

by WickedAPI
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Hybrid

registry_search_tools

Read-onlyIdempotent

Search x402 and MCP tools filtered by category, protocol, and minimum reliability score using uptime, latency, and schema conformance data.

Instructions

[Wicked Registry] Search x402/MCP tools by real reliability data (uptime, latency, schema conformance). Works via x402 (402 carries payment instructions) or a free API key (pass api_key, or set REGISTRY_API_KEY). No key yet? Call registry_onboarding_message then registry_create_api_key to get one yourself. For a quick free check of a known tool, use registry_lookup.

Use when you want to find x402/MCP tools filtered by category, protocol or minimum reliability score. Not for a quick free check of a known tool (use registry_lookup).

Behavior: read-only.

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

Input Schema

NameRequiredDescriptionDefault
sortNo"score" (default), "latency" or "recency".
limitNo1-200, default 50.
api_keyNoFree Wicked Registry API key (wr_...). Overrides REGISTRY_API_KEY.
categoryNoe.g. "data", "crypto".
protocolNo"x402", "mcp" or "rest".
min_scoreNoMinimum composite score 0-100; unchecked tools are excluded once set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.2
    • addedInput schema / properties / api_key
      Added value: +{
+  "description": "Free Wicked Registry API key (wr_...). Overrides REGISTRY_API_KEY.",
+  "type": "string"
+}
  2. First observedv0.3.1

TDQS

A4.4/5.0
Behavior4/5

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

The annotations already cover read-only, idempotent, open-world, and non-destructive behavior, so the bar is lower. The description adds meaningful auth and payment context: x402 is supported with payment instructions on 402, a free API key can be passed or set via REGISTRY_API_KEY, and onboarding tools are named for agents without a key, though it does not detail cost or rate limits.

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?

The description is front-loaded with the core search purpose and then adds auth and usage guidance. It is generally efficient, but the registry_lookup alternative is repeated in both the first paragraph and the explicit usage section, and 'Behavior: read-only' restates the annotation.

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?

With six optional parameters fully documented in the schema and annotations covering the safety profile, the description supplies the remaining context an agent needs: what the tool searches, how payment/auth works, the onboarding path, and when to choose a sibling tool instead. No output schema exists, and the description adequately describes the search result domain.

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 100%, so every parameter is already documented in the schema, including sort, limit, category, protocol, min_score, and api_key. The description mentions filtering by category, protocol, and minimum reliability score but adds no syntax, defaults, or behavior beyond what the schema already provides.

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 gives a specific verb and resource: searching x402/MCP tools, and explains the differentiating value of real reliability data (uptime, latency, schema conformance). It also explicitly distinguishes this tool from registry_lookup, so an agent can tell the two apart without opening either 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 exactly when to use the tool (finding tools filtered by category, protocol, or minimum reliability score) and when not to use it for a quick free check of a known tool. The alternative registry_lookup is named, and the auth/onboarding alternatives are also given for agents without a key.

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