Find MCP - Agentage MCP Directory
Server Details
Search the official MCP registry: 17,000+ servers with trust grades, stars, tools, install config.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 3 of 3 tools scored.
Each tool has a distinct purpose: search, get details, list categories. Their descriptions clearly differentiate them, leaving no ambiguity.
All tools follow a consistent mcp_verb_noun pattern (mcp_categories, mcp_get, mcp_search) using lowercase with underscores, making the convention predictable.
Three tools perfectly cover the core operations of a directory (search, detail retrieval, filter exploration) without being too few or excessive.
The tool set covers the full read-only lifecycle of directory exploration: discover filters, search, and retrieve full details. No obvious gaps for the stated purpose.
Available Tools
3 toolsmcp_categoriesList directory filter valuesARead-onlyInspect
List the directory's available filter values - every category, language, and license, each with how many servers carry it. Call this BEFORE mcp_search when you intend to filter, so you pass exact, existing values for the type/category/language/license arguments instead of guessing. Takes no input. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| licenses | Yes | SPDX licenses and their server counts |
| languages | Yes | Repository languages and their server counts |
| categories | Yes | Category labels and how many servers carry each |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and destructiveHint. The description adds that it takes no input and returns counts per value, providing context beyond annotations without contradiction.
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?
Two concise sentences, front-loaded with action and resource, no superfluous words.
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?
For a simple listing tool with no parameters and an output schema, the description fully covers purpose, usage context, and behavior (read-only, counts).
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?
No parameters exist, and schema coverage is 100%. Baseline of 4 is appropriate as description need not add param info.
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?
The description clearly states the verb 'list' and the resource 'directory's available filter values' (categories, languages, licenses), and distinguishes from siblings by positioning it as a prerequisite for mcp_search.
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?
Explicitly says 'Call this BEFORE mcp_search when you intend to filter' and explains why, providing clear when-to-use guidance and avoiding guesswork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_getGet one MCP serverARead-onlyInspect
Fetch the complete record for ONE MCP server in the agentage directory by its exact slug: full description, categories, the packages and remote endpoints it ships, the tools it exposes, a ready-to-run install command, and a README excerpt. Use this after mcp_search to get the depth a result card omits - pass a slug exactly as returned by mcp_search, never a guessed or constructed one. No slug yet? call mcp_search first. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact slug of one server, taken verbatim from a mcp_search result (do not guess or construct one). |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| slug | Yes | |
| title | Yes | |
| tools | Yes | The MCP tools this server exposes, from its live tools/list |
| install | No | The recommended way to run this server, derived from its first package/remote |
| license | No | |
| remotes | Yes | |
| category | Yes | |
| language | No | |
| packages | Yes | |
| description | Yes | |
| details_url | Yes | Human detail page for this server - open it for more information |
| is_official | Yes | |
| readme_excerpt | No | First ~2000 chars of the README; open details_url for the full document |
| transport_types | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description confirms 'Read-only' and adds context about needing slug from mcp_search, but does not disclose additional behavioral traits like rate limits. Still good overall.
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?
Two sentences with clear, front-loaded action. Every word contributes meaning; no fluff.
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?
Output schema exists, so return values are covered. Description is complete: explains what, how, when, and prerequisites. No gaps.
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?
Schema has 100% coverage, but description adds crucial semantics: the slug must be taken verbatim from mcp_search results and not guessed. This goes beyond the schema 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?
Clearly states it fetches the complete record for one MCP server by slug, listing included fields (description, categories, packages, endpoints, tools, install command, README). Distinguishes from siblings by mentioning it is used after mcp_search.
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?
Explicitly says to use after mcp_search, pass slug exactly as returned, do not guess, and call mcp_search first if no slug. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mcp_searchSearch the MCP directoryARead-onlyInspect
Search the agentage MCP directory - a public catalog of Model Context Protocol servers crawled from the official registry - for servers matching a keyword, optionally narrowed by type, category, language, or license. Use this FIRST whenever the user wants to discover, find, compare, or pick an MCP server ("is there an MCP for X", "which MCP servers do Y"). Results are ranked by text relevance to the query first, then by popularity, so the best match is on top. Returns a page of lean cards (slug, title, description, category, transport, match_score - text relevance the ranking is based on, details_url). To read one server's full packages, tools, and install command, call mcp_get with the slug from a result; open a card's details_url for the human detail page. To learn which category/language/license values exist before filtering, call mcp_categories. Read-only - never installs or runs anything.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Optional. 1-based page number; defaults to 1. Use pagination.total_pages to page. | |
| type | No | Optional. Restrict to one distribution type: npm | pypi | oci | mcpb | nuget, or "remote" for hosted (HTTP) servers. Omit to search every type. | |
| limit | No | Optional. Results per page; defaults to 20, capped at 50. | |
| query | Yes | What to search for - a keyword, product, capability, or server name (e.g. "github", "postgres", "web search"). Matched across names, titles, and descriptions. Prefer a single distinctive term over a long phrase. | |
| license | No | Optional. Restrict to an SPDX license id (e.g. "MIT", "Apache-2.0"). Exact; call mcp_categories for valid values. Omit for no license filter. | |
| category | No | Optional. Restrict to one category label. Must be an exact value from this taxonomy - call mcp_categories to see the categories that actually exist with their counts. Omit for no category filter. | |
| language | No | Optional. Restrict to a repository language (e.g. "TypeScript", "Python"). Exact, case-sensitive; call mcp_categories for valid values. Omit for no language filter. |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | The query the backend actually ran |
| results | Yes | |
| pagination | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and open-world behavior. The description adds further behavioral details: results are ranked by text relevance then popularity, result fields include match_score, and it explicitly states 'Read-only - never installs or runs anything'. No contradictions with annotations.
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?
The description is well-structured and front-loaded with the core purpose. It includes multiple informative sentences, each adding value: usage guidance, ranking explanation, result format, sibling references, and read-only note. Slightly lengthy but justified by complexity; could be trimmed slightly.
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?
Given the tool's complexity (7 parameters, pagination, multiple filters, sibling tools), the description covers all necessary aspects: purpose, when to use, result ordering, result fields, pagination hint, references to mcp_get and mcp_categories, and read-only nature. Output schema handles return values, so no gaps.
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?
Schema description coverage is 100%, so baseline 3. The description does not add significant meaning beyond what the schema already provides for individual parameters. While it contextualizes parameters as a group, it does not offer new semantics per parameter.
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?
The description clearly states it searches the MCP directory for servers matching keywords with optional filters. It uses a specific verb ('Search') and resource ('agentage MCP directory'). It distinguishes from siblings by explicitly referencing mcp_get and mcp_categories for further actions.
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?
The description provides explicit guidance: 'Use this FIRST whenever the user wants to discover, find, compare, or pick an MCP server'. It also tells when not to use it: for reading full server details (use mcp_get) or for learning available filter values (use mcp_categories). This clear differentiation helps the agent choose the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!