plugmcp

Official

by plugmcp-ai

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

Search MCP servers

search_servers

Read-onlyIdempotent

Find MCP servers by product name, publisher, or topic and return relevance-ranked cards with trust signals so users can shortlist servers before fetching install details.

Instructions

Find MCP servers by product name, publisher, or topic. Ranked by relevance (exact name, then publisher, then tags and description); the product's own server comes first when there is one (jira finds Atlassian's), duplicates merged. Returns compact cards with trust signals; call get_install next. When the user describes a job rather than a product, recommend_servers is one call instead of two.

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_servers"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Results per page. Default 8. Without a key at most 10.
`query`	No	Product, publisher, or topic, for example github, postgres, send email. Empty lists the most used servers.
`client`	No	Only servers that work in this client (chatgpt keeps remote servers only). With fields=[install], adds the snippet for it.
`cursor`	No	next_cursor from the previous page.
`fields`	No	Extra card fields. install (needs client) and tools_count need a PlugMCP key.
`category`	No	Category slug: developer-tools, design-tools, databases, browser-automation, web-scraping, cloud-infrastructure, devops, productivity, communication, knowledge-memory, search, finance, security, data-science-ml, marketing, e-commerce, content-management, collaboration, analytics-monitoring, voice-agents, telephony, speech, autonomous-agents, project-management, documentation, game-development, mobile-development, social-media. list_categories has counts.
`remote_only`	No	Only hosted servers with a remote URL, no local install.
`voice_ready`	No	Only servers suited to voice agents.
`official_only`	No	Only servers published by the product they connect to.
`verified_only`	No	Only servers that passed the live health check.
`response_format`	No	json (default) or markdown for a human-readable text block. structuredContent is always JSON.

Output Schema

Name	Required	Description
`hint`	No
`count`	Yes
`query`	No
`total`	Yes	Matches, counted up to 1000.
`servers`	Yes
`next_cursor`	No
`total_capped`	No	True when there are more than 1000 matches.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.4Nov 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real behavior: ranking order (exact name, then publisher, then tags/description), the product's own server being promoted ('jira finds Atlassian's'), and duplicate merging. It does not mention pagination limits or result caps, which the schema covers only indirectly.

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?

Four tight sentences: purpose, ranking behavior, return shape plus next step, then the sibling alternative. Each sentence contributes new information and there is no padding.

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 an output schema present the description needn't enumerate return fields, and it still summarizes the card contents ('compact cards with trust signals'). For an 11-parameter search tool with all-optional params, the description covers purpose, ranking, workflow chaining, and the sibling alternative — nothing an agent needs is missing.

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 baseline is 3. The description adds only marginal meaning over the schema — the ranking rationale for query and the 'product's own server first' behavior — while the 11 parameters themselves (client, category, remote_only, etc.) are fully documented in the schema already.

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 ('Find MCP servers by product name, publisher, or topic') and immediately distinguishes itself from siblings by naming recommend_servers and get_install. An agent can tell which tool to pick without opening any 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?

Explicit routing: 'call get_install next' for the workflow, and 'When the user describes a job rather than a product, recommend_servers is one call instead of two' gives a clear when-not-to-use case with the alternative named. This is exactly the when/when-not/alternative guidance the dimension asks for.

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

Deploy Server