This server lets you discover, evaluate, and monitor other MCP servers using real-time handshake data.
Search MCP servers by keyword, category, client integration (e.g., Claude Desktop, Cursor, VS Code), install type, official status, or verification status.
Get detailed info on a specific server: install command, repository, supported clients, and current probe verdict.
Check real-time status of a server (or all servers) including reachability verdict, tool count, handshake latency, and protocol version.
View probe history with daily uptime sparkline, configurable time window up to 90 days.
List outages as reconstructed incidents (contiguous failed probes) filterable by ongoing/resolved.
Track schema drift to detect when servers add, remove, or change tools between probes.
Browse categories and client integrations with usage counts.
Get catalog-wide stats like verdict breakdown, transport mix, and latency percentiles.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MyMCPTools MCP Server check the status of the psephologist server"
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.
An MCP server for finding other MCP servers — and, more usefully, for checking whether the one you are about to recommend is actually reachable.
Every uptime figure it returns comes from a real MCP handshake against the server's remote endpoint, not from self-reported metadata in a README.
Backed by mymcptools.com. No API key required.
The server is hosted. If your client speaks Streamable HTTP, point it straight at:
https://mymcptools.com/api/mcpStateless, read-only, no auth, no API key. This is also the entry published to the
official MCP Registry as
io.github.shibley/mymcptools.
The code in this repo is a thin stdio adapter over that same endpoint, for clients that don't speak Streamable HTTP yet. It is not on npm yet, so build it from source (Node.js 18+):
git clone https://github.com/shibley/mymcptools-mcp-server.git
cd mymcptools-mcp-server
npm install && npm run buildThen point your client at the built entrypoint:
{
"mcpServers": {
"mymcptools": {
"command": "node",
"args": ["/absolute/path/to/mymcptools-mcp-server/dist/index.js"]
}
}
}Add that to claude_desktop_config.json (Claude Desktop), .cursor/mcp.json (Cursor), or your client's equivalent.
Set MYMCPTOOLS_MCP_URL to override the upstream endpoint the adapter talks to.
Related MCP server: MCP Registry Server
Tool | What it answers |
| Which servers match this keyword, category, client integration or install type? |
| Full entry for one server: install command, repo, supported clients, current probe verdict. |
| Is this server reachable right now? Verdict, exposed tool count, handshake latency, negotiated protocol version. |
| Trailing probe history and a daily uptime sparkline for one server. |
| Reconstructed outages — contiguous runs of failed probes, with start, end and duration. |
| Which servers added, removed or changed tools between probes. Useful for spotting breaking changes. |
| Every category and client integration, with counts. Returns the valid slugs for the filters above. |
| Population-level health: verdict breakdown, transport mix, latency percentiles. |
Worth stating plainly, because the numbers are easy to misread:
The catalog carries ~2,700 entries, but only ~44 are probeable — that is, they publish a remote endpoint something can actually connect to.
The rest are local-only servers (stdio, run via npx or docker on your machine). There is no remote endpoint to handshake against, so they are reported as UNPROBEABLE rather than assigned a made-up status. For those, get_mcp_server falls back to a static repo-freshness signal.
UNPROBEABLE therefore means "not remotely checkable", not "broken".
So treat the live-verification tools as high-confidence for remote/hosted servers, and treat the catalog entry itself as the useful part for local ones.
Verdict | Meaning |
| Handshake succeeded and the server listed its tools. |
| Reachable, but something was off — slow handshake or a degraded response. |
| Endpoint is live but needs credentials before it will list tools. |
| Endpoint is published but the handshake failed. |
| No remote endpoint to probe — typically a local stdio server. |
npm install
npm run buildSmoke-test the built server over stdio:
printf '%s\n%s\n%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
| node dist/index.jsMIT
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Catalog slug, as returned by search_mcp_servers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Trailing window in days. | |
| slug | Yes | Catalog slug. | |
| limit | No | Max raw probe rows. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Catalog slug. Omit for a catalog-wide snapshot. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Restrict to one server. Omit for the whole catalog. | |
| limit | No | Max drift events. Newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Restrict to one server. Omit for the whole catalog. | |
| limit | No | Max incidents. Newest first. | |
| status | No | Filter by incident state, e.g. 'ongoing', 'resolved'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results. Default 20. | |
| query | No | Free-text search across name, description and author. | |
| category | No | Category slug from list_categories. | |
| official | No | Restrict to vendor-official servers. | |
| integration | No | Client integration slug, e.g. 'claude-desktop', 'cursor', 'vs-code'. | |
| install_type | No | Install method, e.g. 'npx', 'docker', 'remote'. | |
| only_verified | No | Restrict to servers whose remote endpoint answered a live MCP handshake. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_catalog_statsget_mcp_serverget_server_historyget_server_statuslist_categorieslist_schema_driftlist_server_incidentssearch_mcp_serversTool names target distinct aspects (search, get, status, history, incidents, schema drift, categories, stats) with only possible overlap between get_mcp_server and search_mcp_servers. Without descriptions, ambiguity is minimal.
Inconsistent verb usage: mixes 'search_', 'get_', and 'list_' prefixes. Also singular vs plural (get_mcp_server vs search_mcp_servers) and no clear pattern.
8 tools is a reasonable number for a server focused on querying and monitoring MCP servers, not overly large or small.
Tools cover searching, fetching details, status, history, incidents, schema drift, categories, and catalog stats, but missing common operations like create, update, or delete. Domain completeness is unclear without descriptions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Trust, freshness, policy, and discovery layer for public MCP servers.
Search a nightly-refreshed directory of MCP servers by keyword, category or topic.
Publish and discover MCP servers via the official MCP Registry. Powered by HAPI MCP server.
MCP server registry — validated by live handshake, scored on reliability, monitored continuously.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shibley/mymcptools-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
