Plug and Ship

Name: Plug and Ship
Author: plugandship

Server Details

Search MCP servers, agent skills and coding-agent plugins: trending tools and best-of lists.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-10-16 06:44
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: plugandship/plugandship-mcp
GitHub Stars: 0
Server Listing: plugandship-mcp

TDQS

A3.6/5.0

Scored 2026-10-16 04:50 across 4 tools

Disambiguation4/5

Each tool has a distinct purpose: search_tools finds by task, get_tool fetches one item's details, list_best returns curated topic rankings, and trending surfaces fastest-growing items. search_tools, list_best, and trending all return ranked discovery lists, so there is mild overlap, but the descriptions clearly separate keyword search, editorial best-of, and velocity ranking.

Naming Consistency4/5

Three tools follow a clean verb_noun pattern (get_tool, list_best, search_tools), while trending is a bare noun. The deviation is minor and the names remain readable and predictable.

Tool Count4/5

Four tools is a reasonable, well-scoped set for a read-only discovery registry, with each tool earning its place. It is slightly lean, since browsing the full catalog relies on list_best with an omitted topic rather than a dedicated browse tool.

Completeness4/5

The surface covers the core discovery lifecycle: keyword search, single-item detail retrieval, curated rankings, and trend data. Minor gaps exist, such as no full-catalog browse endpoint, no pagination or related-tool retrieval, and no submission/publish path.

Available Tools

4 tools

get_toolGet tool detailsA

Read-onlyIdempotent

Inspect

Full details for one tool by its Plug and Ship slug (from search_tools): description, stars, install command, remote endpoint, license, tags and last commit.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Tool slug, e.g. 'github-mcp-server'

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, openWorld, and idempotent, so the safety profile is covered. The description adds real value by enumerating the returned payload (description, stars, install command, remote endpoint, license, tags, last commit), which is critical since there is no output schema.

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?

A single front-loaded sentence with no filler; the identifying key appears first and the field list is compact.

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 one-param lookup with no output schema, the description compensates by listing the returned fields, so the agent knows what it will get. Missing only edge behavior such as what happens for an unknown slug.

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% with a pattern and example, so the baseline is 3. The description adds provenance the schema cannot express — that the slug originates from search_tools — which helps the agent construct a valid value rather than invent one.

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 ('Full details for one tool') with the exact key ('slug'), and names the sibling that produces that key (search_tools), so an agent can distinguish it from list_best, search_tools, and trending immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical '(from search_tools)' tells the agent when this tool is applicable and what feeds it, which is meaningful routing guidance. It stops short of an explicit when-not clause (e.g. use search_tools to find slugs rather than guessing them).

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

list_bestBest-of listC

Read-onlyIdempotent

Inspect

A ranked best-of list by topic, e.g. 'grok-bot-connectors', 'voice-agents', 'local-models', 'figma-mcp-servers', 'mcp-servers-for-databases'. Omit topic to list all topics.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`topic`	No	Topic slug; omit to list topics

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety and repeatability profile is covered. The description usefully adds that results are 'ranked' and that omitting the topic switches to a topic-listing mode (a change in return shape), but says nothing about pagination, default limit, or result count. Adequate but thin on top of the annotations.

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?

Two sentences, front-loaded with the core resource definition and followed by the omission rule. The example list is long-ish but each example is short and helps the agent construct a valid slug. No filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing return values, and it only says 'ranked list' without indicating what a best-of entry contains (name, rank, URL, score?). Safety behavior is covered by annotations and the topic-mode switch is explained, but the entry shape remains unknown for a tool whose entire job is returning entries.

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 50%: the 'topic' parameter has a pattern and a description, while 'limit' has only min/max bounds and no textual explanation anywhere. The description compensates well for the topic parameter by giving five realistic slug examples, which is genuine added value beyond the regex, but the undocumented limit parameter keeps this at baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource returned (a ranked best-of list scoped by topic) and gives concrete topic examples, so the agent knows what data comes back. However, it is a noun phrase with no verb, and it never distinguishes this tool from siblings like 'trending' or 'search_tools', both of which also surface ranked content. Purpose is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is 'Omit topic to list all topics', which is a parameter-mode hint rather than tool-selection advice. There is no statement of when to use list_best versus trending or search_tools, and no exclusions. An agent must infer the routing decision entirely.

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

search_toolsSearch agent toolsA

Read-onlyIdempotent

Inspect

Find MCP servers, agent skills (SKILL.md) and coding-agent plugins for a task. Pass a plain-language task (e.g. 'query my Postgres from Cursor', 'post to Slack from Claude Code') or keywords. The task is parsed for kind (MCP/skill/plugin), client (Cursor, Claude Code, Codex, VS Code), remote vs local and language; results are ranked by relevance (full-text + semantic match), with stars, recent commits, a valid one-click config and a license only as tie-breakers. Every result explains why it matches. type, client and remote are strict filters (client grok-bot = MCP servers with a public HTTPS endpoint).

ParametersJSON Schema

Name	Required	Description
`task`	No	What you want to do, in plain language. Used instead of query when given.
`type`	No	Only this kind of tool
`limit`	No	Max results, default 10
`query`	No	Keywords or a short task, e.g. 'postgres', 'browser automation', 'query my Postgres from Cursor'
`client`	No	Only tools that name this coding agent (grok-bot: hosted HTTPS MCP servers)
`remote`	No	Only MCP servers with a public HTTPS endpoint (nothing to install)

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`query`	Yes
`results`	Yes
`interpreted`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent, so the safety profile is covered. The description goes further and discloses behavior the annotations cannot: how the task is parsed (kind, client, remote vs local, language), how results are ranked (full-text + semantic), what is only a tie-breaker, and that filters are strict.

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?

Front-loaded with the purpose, then calling guidance, then ranking behavior, then filter semantics — a logical order. It is dense for four sentences but every clause carries information an agent needs.

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?

An output schema exists, so return values need not be explained; the description still notes that each result explains its own match, which is the useful part. Query semantics, filters, ranking and result shape are all covered for a 6-parameter search tool.

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% and includes enum values and the task/query precedence, so the baseline is 3. The description adds real semantics on top: 'type, client and remote are strict filters' and the grok-bot special case meaning hosted HTTPS MCP servers, clarifying filter behavior rather than just restating fields.

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 set ('Find MCP servers, agent skills (SKILL.md) and coding-agent plugins') and is clearly distinguishable from browse-oriented siblings like list_best and trending. The scope of what is searchable is explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete calling guidance ('Pass a plain-language task ... or keywords') with two worked examples, which sets the context for use. It never names the alternatives (get_tool, list_best, trending) or states when a browse-style tool would be better, so the sibling routing is left to inference.

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

trendingTrending toolsA

Read-onlyIdempotent

Inspect

Fastest-growing MCP servers, skills and plugins: stars gained in the period (day, week or month) from Plug and Ship's own daily star snapshots. While less than one period of history exists, a damped lifetime velocity fills in (repos with 20+ stars and a commit in the last 30 days).

ParametersJSON Schema

Name	Required	Description
`type`	No
`limit`	No
`period`	Yes	Time window

TDQS

A3.9/5.0

Behavior4/5

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

Annotations cover readOnly/idempotent/openWorld, and the description adds the fallback behavior (damped lifetime velocity) and its gating condition (20+ stars, commit in last 30 days). That fallback is genuinely non-obvious behavioral context beyond what annotations provide, though the return format and fail behavior are not covered.

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?

Front-loaded with the core purpose and the ranking metric, then the fallback qualifier. Dense and efficient, though the parenthetical '(day, week or month)' partially repeats the period enum.

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?

No output schema, so the description would ideally describe the return shape; it doesn't. But it does cover the ranking basis, the default fallback, and the data source, which is enough context for an agent to select and invoke it correctly.

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 33%, so the schema under-documents. The description explains the 'period' concept (day/week/month via snapshots) but says nothing about 'limit' or 'type' semantics, so it only partially compensates for the coverage gap.

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+resource ('Fastest-growing MCP servers, skills and plugins') and the ranking metric (stars gained in period). The siblings get_tool and search_tools are retrieval tools while this one ranks by growth, so the distinction is clear from the verb 'fastest-growing'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage – an agent can infer this is for discovering trending tools ranked by growth – but there's no explicit when-to-use vs alternatives like list_best or search_tools. The choice between trending and list_best is left to inference.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 16, 2026

Changedsearch_tools7 fields changed

changedInput schema / properties / client / description

Previous value: -"Only tools for this coding agent"New value: +"Only tools that name this coding agent (grok-bot: hosted HTTPS MCP servers)"

changedInput schema / properties / query / description

Previous value: -"Keywords, e.g. 'postgres', 'figma', 'browser automation'"New value: +"Keywords or a short task, e.g. 'postgres', 'browser automation', 'query my Postgres from Cursor'"

changedInput schema / properties / query / maxLength
```
Previous value: -100New value: +300
```

addedInput schema / properties / remote

Added value: +{
+  "description": "Only MCP servers with a public HTTPS endpoint (nothing to install)",
+  "type": "boolean"
+}

addedInput schema / properties / task

Added value: +{
+  "description": "What you want to do, in plain language. Used instead of query when given.",
+  "maxLength": 300,
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "query"
-]
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "interpreted": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "client": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "kind": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "language": {
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "local": {
+              "type": "boolean"
+            },
+            "remote": {
+              "type": "boolean"
+            },
+            "terms": {
+              "items": {
+                "type": "string"
+              },
+              "type": "array"
+            }
+          },
+          "required": [
+            "kind",
+            "client",
+            "remote",
+            "local",
+            "language",
+            "terms"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "query": {
+      "type": "string"
+    },
+    "results": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "description": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "install": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "language": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "last_commit": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "license": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          },
+          "page": {
+            "type": "string"
+          },
+          "reasons": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "remote_endpoint": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "score": {
+            "type": "number"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "stars": {
+            "type": "number"
+          },
+          "type": {
+            "enum": [
+              "mcp",
+              "skill",
+              "plugin"
+            ],
+            "type": "string"
+          },
+          "why": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "name",
+          "type",
+          "description",
+          "stars",
+          "install",
+          "remote_endpoint",
+          "page",
+          "language",
+          "license",
+          "last_commit"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "query",
+    "interpreted",
+    "count",
+    "results"
+  ],
+  "type": "object"
+}

4 tool updatesOct 15, 2026
- First observedget_tool
- First observedlist_best
- First observedsearch_tools
- First observedtrending

Related MCP Connectors

MCP Charts A
com.mcpcharts
Find MCP servers, skills, plugins, agents, prompts and rules for any task.
Search Developer Tools
31
StackResolve C
dev.stackresolve
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Developer Tools
151
Meyhem — MCP Server Discovery & Agent Search A
io.github.c5huracan
Discover 6,700+ MCP servers and 15,000+ OpenClaw skills. Agent-native search with outcome ranking.
Search Developer Tools Agent Orchestration
24
agentswitchboard A
io.github.assafbar2
Search a curated directory of 300+ verified AI agents, MCP servers, and agentic tools.
Search
32

Related MCP Servers

beacon-mcp
AI & Machine Learning Developer Tools Search
enrichgateagent-png
A
license
A
quality
C
maintenance
MCP server that searches 3,800+ open-source AI agents by capability, ranked by real traction (stars, activity). Query it from Claude Desktop, Cursor, Cline, or Windsurf.
Updated 3 months ago (2026-07-13 17:16 UTC)
3
53 npm
MIT
Meyhem
Search Agent Orchestration
c5huracan
F
license
Not graded
quality
D
maintenance
Finds the right MCP server for a task from over 1,400 indexed servers ranked by community trust. Also provides outcome-ranked web search for AI agents with no API key or rate limits.
Updated 7 months ago (2026-03-14 17:36 UTC)
4
-
loaditout-mcp-serverofficial
Developer Tools Search
loaditoutadmin
A
license
A
quality
D
maintenance
MCP server for discovering and installing AI agent skills from Loaditout. Search 20,000+ security-gradedMCP servers, check A/B/C/F grades, get install configs, and browse trending skills and curated packs.
Updated 6 months ago (2026-04-07 11:24 UTC)
21
26 npm
1
MIT
remoteopenclaw-mcp
Developer Tools Search
aidevelopers2
A
license
A
quality
D
maintenance
Enables AI agents to search a directory of 13,870+ MCP servers, 4,384+ agent skills, and plugins from Remote OpenClaw, returning install commands directly.
Updated 3 months ago (2026-07-02 11:15 UTC)
3
52 npm
6
MIT

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

loaditout-mcp-serverofficial

Glama MCP Gateway

Resources