Skip to main content
Glama
plugandship

plugandship-mcp

Official
by plugandship
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

plugandship-mcp

An MCP server for Plug and Ship. It lets your coding agent search the Plug and Ship index of MCP servers, agent skills and coding-agent plugins without leaving the chat.

It is read-only. It calls the public Plug and Ship API (/api/v1) and needs no API key.

Listed in the official MCP Registry as dev.plugandship/plugandship-mcp.

Tools

Tool

Arguments

What it returns

search_tools

query, type? (mcp / skill / plugin), client? (claude-code / cursor / codex / grok-bot), limit? (1 to 50, default 10)

Matching tools with stars, install command and page link. client: "grok-bot" keeps only MCP servers with a public remote (HTTP) endpoint.

get_tool

slug

Full details for one tool: description, repo, stars, tags, install command, remote endpoint if any.

trending

period (day / week / month), type?, limit?

Repos created in the period, ranked by stars per day.

list_best

topic?, limit?

A curated "best of" list. Leave topic empty to list topics (for example grok-bot-connectors, voice-agents, postgres-mcp-servers).

Related MCP server: remoteopenclaw-mcp

Use the hosted endpoint (no install)

Remote MCP server, Streamable HTTP, stateless, no auth:

https://plugandship.dev/mcp

Claude Code

claude mcp add --transport http plugandship https://plugandship.dev/mcp

Cursor (~/.cursor/mcp.json or .cursor/mcp.json in a project)

{
  "mcpServers": {
    "plugandship": { "url": "https://plugandship.dev/mcp" }
  }
}

Codex (~/.codex/config.toml)

[mcp_servers.plugandship]
url = "https://plugandship.dev/mcp"

Run it locally (stdio)

Requires Node.js 18 or newer. Runs straight from GitHub, no npm package needed (the built dist/ is committed):

npx -y github:plugandship/plugandship-mcp

Claude Code

claude mcp add plugandship -- npx -y github:plugandship/plugandship-mcp

Cursor

{
  "mcpServers": {
    "plugandship": {
      "command": "npx",
      "args": ["-y", "github:plugandship/plugandship-mcp"]
    }
  }
}

Codex

[mcp_servers.plugandship]
command = "npx"
args = ["-y", "github:plugandship/plugandship-mcp"]

From a checkout

git clone https://github.com/plugandship/plugandship-mcp
cd plugandship-mcp
npm install
npm run build
node dist/index.js

Self-host Streamable HTTP

node dist/index.js --http --port 3333 --host 127.0.0.1
# endpoint: http://127.0.0.1:3333/mcp

Stateless, JSON responses, POST only. Requests with a browser Origin other than localhost are rejected. It binds to 127.0.0.1 by default. Put it behind HTTPS before exposing it anywhere.

Configuration

Env var

Default

Purpose

PLUGANDSHIP_API_URL

https://plugandship.dev

API base URL (use http://localhost:3000 against a local site).

The public API is cached and rate-limited (about 60 requests per minute per IP). On a 429 the tool returns a short "try again in a minute" error.

Test

npm test                                            # stdio + local HTTP, against https://plugandship.dev
PLUGANDSHIP_API_URL=http://localhost:3000 npm test  # against a local site
MCP_REMOTE_URL=https://plugandship.dev/mcp npm run test:remote  # the hosted endpoint

npm test builds the server, starts it over stdio and over Streamable HTTP, connects with the official MCP SDK client, lists the tools and calls each one, including error cases (unknown slug, invalid input, foreign Origin). test:remote runs the same checks against a remote endpoint.

Registry

server.json is the MCP Registry entry: a remote-only listing (streamable-http, https://plugandship.dev/mcp) under the dev.plugandship namespace, verified by DNS.

License

MIT

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
NameRequiredDescriptionDefault
slugYesTool 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 readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds genuine value by enumerating the returned payload (stars, install command, remote endpoint, license, tags, last commit), which matters because there is no output schema. It does not mention behavior for a nonexistent slug.

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?

One sentence, front-loaded with the action and key, then a tight enumeration of returned fields. No filler, every clause earns its place.

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?

With no output schema, listing the returned fields is exactly the right compensation, and read-only/idempotent/open-world behavior is covered by annotations. Minor gap: no mention of error behavior 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% and the single slug parameter is well documented with a pattern and example, so the baseline is 3. The description adds the provenance of the value ('from search_tools'), which is real semantic value the schema cannot express.

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') and narrows the lookup key to a Plug and Ship slug, which separates it from list_best/trending/search_tools. It also names search_tools as the origin of the slug, so the agent can route between the two tools without opening a schema.

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 this is a follow-up step in an existing workflow, which is clear usage context. It stops short of explicit when-not-to-use guidance or stating what to do for an unknown/ambiguous slug.

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

list_bestBest-of listB
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
NameRequiredDescriptionDefault
limitNo
topicNoTopic slug; omit to list topics

TDQS

B3.4/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 profile is covered. The description adds that results are ranked and topic-scoped, but says nothing about result size, the limit parameter's effect, or pagination behavior.

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?

A single front-loaded sentence with a compact example list; every clause earns its place. The example enumeration is slightly long but directly aids parameter formatting.

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?

For a simple two-parameter read tool with no output schema, the description covers what the tool returns and how to scope it, but omits the limit semantics and any sense of result ordering/size, which an agent needs to call it optimally.

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%; topic carries its own description and the description's examples reinforce the slug format and the omit-to-list-all behavior. The limit parameter (1-50) is undocumented in both the schema and the description, leaving half the surface unexplained.

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

Purpose4/5

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

States the resource precisely ('a ranked best-of list by topic') and grounds it with concrete topic examples, so an agent knows it returns a curated ranking, not raw search matches. It does not explicitly distinguish itself from the sibling 'trending', which is the nearest overlapping concept.

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?

'Omit topic to list all topics' gives a usable condition for the parameter, but there is no guidance on when to pick this tool over search_tools or trending. Usage is implied by the topic examples rather than stated.

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

Search the Plug and Ship index of MCP servers, agent skills (SKILL.md) and coding-agent plugins. Results are ranked by name match, then GitHub stars, and include install commands. Use client to narrow to a coding agent (grok-bot returns only MCP servers with a public HTTPS endpoint).

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoOnly this kind of tool
limitNoMax results, default 10
queryYesKeywords, e.g. 'postgres', 'figma', 'browser automation'
clientNoOnly tools for this coding agent

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the description is free to add behavior — ranked results (name match, then GitHub stars), inclusion of install commands, and the notable grok-bot constraint that only MCP servers with a public HTTPS endpoint are returned. That last detail is genuinely non-obvious and actionable.

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?

Three tight sentences: what is searched, how results are ranked/returned, and how to narrow with client. It is front-loaded with the core purpose and no sentence is filler.

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?

With no output schema, the description does most of the work by naming ranking order and install commands in the results. Exact result fields and pagination behavior remain unspecified, but nothing essential to invoking the tool correctly is missing.

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 enum descriptions for type and client and defaults for limit, so the baseline is 3. The description adds meaning beyond the schema by explaining what the client enum actually filters on (grok-bot → only MCP servers with a public HTTPS endpoint), which the schema alone does not convey.

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

Purpose4/5

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

States a specific verb (search) and resource (the Plug and Ship index of MCP servers, agent skills, and coding-agent plugins), so the scope is unambiguous. It never names the siblings (list_best, trending, get_tool) or contrasts itself with them, which keeps it short of a 5.

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?

Usage is implied: keyword search across the index, with the client parameter for narrowing to a coding agent. It does not say when to reach for list_best, trending, or get_tool instead, so the alternative-routing guidance an agent needs 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. 4 tool updatesv0.1.0
    • First observedget_tool
    • First observedlist_best
    • First observedsearch_tools
    • First observedtrending
Deploy Server
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

TDQS

A3.7/5.0

Scored across 4 tools

Disambiguation4/5

Each tool has a distinct role: list_best surfaces curated topic rankings, search_tools queries the index, get_tool fetches one slug's detail, and trending ranks new items by star velocity. The only mild overlap is between list_best and trending, both being ranked lists, but their framing (topic vs recency) keeps them separable.

Naming Consistency4/5

Three tools follow a clean verb_noun pattern (list_best, search_tools, get_tool). trending breaks the pattern with a bare gerund/noun, a minor deviation but not confusing.

Tool Count4/5

Four tools is on the lean side but fits a compact directory/index API where search plus detail plus two curated views is the core surface. Nothing feels redundant or dead-weight.

Completeness4/5

The lifecycle of discover (search_tools/list_best/trending) and inspect (get_tool) is covered, and list_best with no topic effectively enumerates topics. Minor gaps exist, such as tag/language filtering or explicit topic enumeration, but the core workflow is intact.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers