How do I use Plugolis MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Plugolis MCP Server Find a maintained MCP server for Postgres and give me the Cursor config." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Plugolis MCP Server

Official

by plugolis

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Plugolis MCP server

Find MCP servers and fix MCP errors right from your AI assistant.

This server gives Cursor, Claude, VS Code and other MCP clients read-only access to the Plugolis directory. That covers MCP servers with install commands and ready-to-paste configs, plus step-by-step fixes for common errors like spawn npx ENOENT or MCP error -32000: Connection closed.

Read-only. It only reads Plugolis's public JSON API at https://plugolis.com/api/.
No API key, no account, no secrets.
Data is cached for 15 minutes, so repeated questions are fast.

Tools

Tool	What it does
`search_servers`	Search servers by words (`query`) and filter by `category`, `client` (e.g. Cursor), `status` (`maintained` / `stale`) and `transport` (`local` / `remote`).
`get_server`	Everything about one server (by slug): install command, config JSON, required env vars, repo, stars, maintenance status.
`list_categories`	All categories with their server counts.
`search_fixes`	Paste an error message to find the matching fix. You can filter by client.
`get_fix`	One fix in full: the error, the cause, numbered steps with code, and sources.

Example prompts:

"Find a maintained MCP server for Postgres and give me the Cursor config."
"Claude Desktop says spawn npx ENOENT. How do I fix it?"

Related MCP server: miyo-kado

Install

Requires Node.js 18 or newer.

Cursor

Add this to ~/.cursor/mcp.json (or .cursor/mcp.json in a project):

{
  "mcpServers": {
    "plugolis": {
      "command": "npx",
      "args": ["-y", "plugolis-mcp"]
    }
  }
}

Claude Desktop

Open Settings → Developer → Edit Config and add this to claude_desktop_config.json, then restart Claude:

{
  "mcpServers": {
    "plugolis": {
      "command": "npx",
      "args": ["-y", "plugolis-mcp"]
    }
  }
}

On Windows, if you see spawn npx ENOENT, use "command": "cmd" and "args": ["/c", "npx", "-y", "plugolis-mcp"].

Claude Code

claude mcp add plugolis -- npx -y plugolis-mcp

VS Code

Add this to .vscode/mcp.json. Note that VS Code uses servers, not mcpServers:

{
  "servers": {
    "plugolis": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "plugolis-mcp"]
    }
  }
}

Remote server (coming soon)

A hosted version that needs no install is planned at https://mcp.plugolis.com/mcp (Streamable HTTP). It is not live yet. Use the npx setup above until this note is removed.

Options

These environment variables are all optional:

Variable	Default	Meaning
`PLUGOLIS_API_URL`	`https://plugolis.com/api`	Where to read the data
`PLUGOLIS_CACHE_TTL_MS`	`900000` (15 min)	How long to cache it

Development

npm install
npm test              # builds, then runs the stdio server and calls every tool through a real MCP client
npm run test:worker   # runs the Cloudflare Worker with `wrangler dev` and calls every tool over HTTP
npm run typecheck

Set SKIP_LIVE=1 to skip the tests that use the live plugolis.com API.

Project layout:

src/data.ts: fetches the API, with caching, timeouts and clear errors
src/server.ts: the MCP tools (shared by both versions)
src/index.ts: the stdio entry point (npx plugolis-mcp)
workers/: the remote Streamable HTTP version for Cloudflare Workers (stateless, endpoint /mcp)

You can also try it in the MCP Inspector:

npm run build && npx @modelcontextprotocol/inspector node dist/index.js

Data and license

The data comes from plugolis.com. If you reuse it, credit Plugolis with a link. The code is released under the MIT license.

Available Tools

5 tools

get_fixGet MCP error fixA

Read-onlyIdempotent

The full fix for one MCP error by slug: the exact error, its cause, numbered steps with code, and sources.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Fix slug from search_fixes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare this a safe, idempotent, read-only lookup, so the safety profile is covered. The description adds genuine value by disclosing the shape of the returned content (exact error, cause, numbered steps with code, sources), which the agent cannot learn from 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the operation and then lists the return contents; every clause earns its place with no 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 usefully carries the return-shape burden, which is the key missing structured information. It omits only edge behavior such as what happens when a slug is not found, a minor gap for a simple one-parameter lookup.

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?

Only one parameter exists and schema coverage is 100%, so the baseline is 3. The phrase 'by slug' restates what the schema already defines as a string with length bounds and the 'from search_fixes' origin note adds nothing new.

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 and resource ('Get ... one MCP error by slug') and enumerates the payload it returns (error, cause, steps, sources). It implicitly contrasts with the plural search_fixes by emphasizing 'one' fix, but never names the sibling outright, so it falls short of full differentiation.

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 only implied: the singular 'one ... by slug' suggests a follow-up lookup after a search, and the schema note 'Fix slug from search_fixes' hints at the workflow, but the description itself states no when-to-use condition or alternative tool.

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

get_serverGet MCP server detailsA

Read-onlyIdempotent

Full details for one MCP server by slug: description, install command, ready-to-paste config JSON, required env vars, maintenance status and links.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Server slug from search_servers, e.g. 'github' or 'filesystem'

TDQS

A4/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, non-destructive, openWorld), so the description earns credit for adding payload context instead: install command, paste-ready config JSON, required env vars, maintenance status. It does not mention behavior on an unknown slug or any rate limiting, so it stops short of a 5.

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: identity and lookup key first, then the returned fields. Every clause carries information and nothing is padding.

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 usefully enumerates the returned artifacts (config JSON, env vars, links, maintenance status), which is the main completeness requirement for a simple single-param read tool. It omits error/not-found semantics, so it is strong but not exhaustive.

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% and there is only one parameter, whose format and source ('from search_servers, e.g. github') are fully documented in the schema. The description's 'by slug' merely restates the key, adding no syntax or constraint detail beyond the structured field.

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?

Specific verb (get) plus resource (one MCP server) scoped 'by slug', which cleanly separates it from the plural, query-driven search_servers sibling. It also enumerates the payload fields, so an agent knows exactly what kind of detail it returns before 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 Guidelines3/5

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

The phrase 'by slug' implies the caller must already have an identifier, which hints at the search_servers → get_server workflow, but the description never names search_servers as the prerequisite source or states when not to use it (the schema's slug field carries that pointer instead). Usage is inferable rather than stated.

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

list_categoriesList categoriesA

Read-onlyIdempotent

List every Plugolis server category with its slug, number of servers and the server slugs in it.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value by specifying the exact returned fields, but says nothing about pagination, result size, or whether all categories are always included.

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 that packs verb, scope and return payload with 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, the description usefully names the returned fields, which an agent needs to consume the response. Only pagination/volume guidance is missing, so it is close to complete.

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 tool takes no parameters, so the baseline is 4. The description correctly signals a no-input, list-everything operation rather than implying any filtering options.

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 ('List') and resource ('server category') and enumerates the returned fields (slug, server count, server slugs). An agent can clearly distinguish it from search_servers, get_server, search_fixes and get_fix, which all operate on servers or fixes rather than categories.

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?

The description implies a browsing/enumeration use case but never states when to prefer this over search_servers or get_server, nor any prerequisites. Usage is inferable from the name and purpose rather than explicit.

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

search_fixesSearch MCP error fixesA

Read-onlyIdempotent

Find step-by-step fixes for MCP errors. Paste the error message (or describe the problem) and optionally filter by client. Returns matching fixes; use get_fix for the full steps.

ParametersJSON Schema

Name	Required	Description
`error`	No	Error text or a description, e.g. 'spawn npx ENOENT' or 'server not showing in Cursor'. Omit to list all fixes.
`limit`	No	Max results (default 10)
`client`	No	Only fixes for this client, e.g. 'Cursor', 'Claude Desktop'

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is fully covered. The description adds that results are matching fixes rather than full instructions, which is useful, but says nothing about ranking, pagination, or whether zero-result searches are common. Modest added value against a rich annotation set.

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?

Two short sentences, zero filler, and the routing hint to get_fix is placed at the end after the core purpose and input guidance. Nothing is repeated unnecessarily.

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 no output schema, the description still tells the agent what comes back (matching fixes) and where the full answer lives (get_fix), which is exactly what a search tool needs. Nothing required for correct invocation 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 description coverage is 100%: the schema already documents the error text format, the limit default/max, and client filtering. The description only echoes the error/client inputs at a high level, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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 ('Find step-by-step fixes for MCP errors') and immediately differentiates itself from the sibling get_fix by scoping this tool to search-level results. An agent can tell it apart from search_servers, get_server, list_categories and get_fix 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?

Gives concrete invocation context ('Paste the error message or describe the problem') and names the follow-up alternative with its condition ('use get_fix for the full steps'). It lacks an explicit when-not (e.g., 'use get_fix directly if you already have a fix id'), so it falls just short of a 5.

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

search_serversSearch MCP serversA

Read-onlyIdempotent

Search the Plugolis directory of MCP servers. All filters are optional; with no arguments it lists every server. Returns name, slug, category, status and a link for each match. Use get_server for install details.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (default 20)
`query`	No	Words to match against name, description and category, e.g. 'postgres' or 'browser automation'
`client`	No	Only servers whose docs mention this client, e.g. 'Cursor', 'Claude Desktop', 'VS Code'
`status`	No	'maintained' = updated in the last 6 months, 'stale' = not
`category`	No	Category name or slug, e.g. 'Databases' or 'databases'. See list_categories.
`transport`	No	'local' runs on your machine, 'remote' is a hosted URL (servers offering both match either)

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 and openWorld, so the safety profile is covered. The description adds useful behavior beyond that: the default no-filter enumeration behavior and the returned fields (name, slug, category, status, link), which matters since there is no output schema. It stops short of noting pagination or ordering behavior.

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 short sentences, front-loaded with purpose, then default behavior, then sibling routing. Every clause carries information an agent would otherwise have to infer.

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 six-parameter read-only search with full schema coverage and annotations covering the safety profile, the description supplies the two things structured data does not: default no-filter behavior and the shape of the result set. Nothing needed to call it correctly 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 description coverage is 100%, with every parameter including enums documented in-schema (e.g. maintained/stale, local/remote), so the schema does the heavy lifting. The description only adds the general fact that filters are optional, which is already implied by zero required parameters.

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 ('Search the Plugolis directory of MCP servers') and scopes the domain clearly against the sibling search_fixes. It also names get_server as the follow-up tool, so an agent can place it in the tool graph 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 Guidelines5/5

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

Explicitly says all filters are optional and that a no-argument call lists every server, which removes the biggest ambiguity for a 0-required-param tool. It also routes the agent elsewhere ('Use get_server for install details'), giving a concrete when-to-use-this-vs-sibling condition.

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.

5 tool updatesv0.1.1Oct 19, 2026
- First observedget_fix
- First observedget_server
- First observedlist_categories
- First observedsearch_fixes
- First observedsearch_servers

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

A4.1/5.0

Scored 2026-10-19 04:35 across 5 tools

Disambiguation4/5

The set forms two clean search/get pairs for distinct resources (servers and fixes), so an agent can easily tell which to call. The only mild overlap is between search_servers with no arguments (lists every server) and list_categories (lists categories plus their server slugs), but the descriptions clarify the intended split.

Naming Consistency5/5

All five tools follow a strict verb_noun snake_case pattern: search_servers, get_server, list_categories, search_fixes, get_fix. The search/get/list verbs are used predictably for the same resource actions throughout.

Tool Count4/5

Five tools is a lean but sensible surface for a read-only directory covering two content types plus categorization. It sits at the low edge of the ideal range; nothing is redundant, though the set is thin enough that any missing lookup path would be noticeable.

Completeness4/5

Search and retrieval are covered for both the server directory and the error-fix library, which matches the read-only nature of the domain. Minor gaps exist, such as no direct tool to enumerate servers within a given category without going through search_servers, but agents can bridge this easily.

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

MCP Marketplace A
io.mcp-marketplace
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
Developer Tools Search
72
LLMemoryOAuth
io.github.meir-may
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Search Knowledge & Memory
2
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5365
Skill of Skills A
io.911fund.skills
Quality-ranked, cross-platform directory of AI coding skills, plugins and MCP servers.
Developer Tools AI & Machine Learning
6211

Related MCP Servers

mcpcatalogs
Search Developer Tools
mcpcatalogs
A
license
A
quality
D
maintenance
Enables AI assistants to search, compare, and get detailed information about MCP servers from the mcpcatalogs.com directory.
Updated 5 months ago (2026-05-17 09:06 UTC)
4
4 npm
MIT
miyo-kado
Note Taking File Systems Knowledge & Memory
MMoMM-org
A
license
Not graded
quality
A
maintenance
Security-first MCP server plugin for Obsidian that gives AI assistants granular, permissioned access to vault notes and files through tools like read, write, delete, rename, search, and open-notes.
Updated 18 days ago (2026-10-05 10:46 UTC)
5
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 4 months ago (2026-07-02 11:15 UTC)
3
21 npm
6
MIT
MCP Verdict MCP Server
Documentation Access Search Developer Tools
Dhoomlegeche
A
license
A
quality
C
maintenance
Enables AI assistants to search independent, source-reviewed evaluations of MCP servers and retrieve full reviews or individual sections covering capabilities, setup, security, permissions, token costs, and maintenance status, along with setup guides and comparisons. Content is fetched live from mcpverdict.com and needs no API key.
Updated 17 days ago (2026-10-06 10:48 UTC)
3
MIT