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., "@agentalmanac-mcp search for an MCP server for PostgreSQL"
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 searching the Agent Almanac — the public catalog of 9,000+ Model Context Protocol servers.
The MCP server for finding MCP servers. Discover, inspect, and install MCP tools from inside any MCP-aware agent.
{
"mcpServers": {
"agentalmanac": {
"command": "npx",
"args": ["-y", "agentalmanac-mcp"]
}
}
}Add this to your Claude Desktop / Cursor / Continue / Zed MCP config. No auth, no setup.
Related MCP server: mcp-server-mcpindex
Tool | What it does |
| Search the catalog by capability, name, or description (FTS5-backed) |
| Full per-server info: install command, tool list, repo, version |
| Most recently updated MCP servers in the catalog |
After installing, ask your agent:
Find me an MCP server for working with Postgres.
Get details on
io-github-proompteng-bilig-workpaper.
What's been updated in the MCP ecosystem this week?
The server returns formatted text. Your agent does the rest.
agentalmanac.org is a neutral, open catalog of MCP servers. It ingests from the official Model Context Protocol Registry and surfaces searchable, installable entries. No login. Free. JSON API: https://agentalmanac.org/api/v1/mcp/servers.
Env var | Default | Use |
|
| Override for testing against a different base URL |
MIT. Issues + PRs: https://github.com/survivorforge/agentalmanac-mcp
Get full details on a specific MCP server by its slug (from search results). Returns install command, tool list, repository link, version, transports.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The server's catalog slug (e.g. 'io-github-proompteng-bilig-workpaper'). Get this from search_mcp_servers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral info. It lists what the tool returns (install command, tool list, etc.) but does not mention side effects, authentication needs, rate limits, or any other behavioral traits. Adequate but not complete.
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?
Single sentence that is concise and front-loaded with the action and resource. No wasted words, though additional structure (e.g., bullet points for return fields) could improve readability.
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 lookup tool with one parameter, the description provides sufficient context about input source and output fields. However, no output schema is provided, and the description lacks detail on response structure or error conditions, making it minimally complete.
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 coverage is 100% with description for the only parameter 'slug' already provided in the input schema. The description adds 'from search results' context, marginally adding value, but baseline 3 is appropriate.
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?
Description clearly states the verb 'Get', resource 'full details on a specific MCP server', and the unique identifier 'slug' derived from search results. It also lists the returned fields, distinguishing it from sibling tools like search_mcp_servers that return lists.
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?
Description explicitly instructs to obtain the slug from search results (search_mcp_servers), providing a clear prerequisite. It does not explicitly state when not to use, but the context implies this tool is for detailed retrieval after search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recently updated MCP servers in the catalog. Use to discover what's new or being actively maintained.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent servers to return (default 10, max 50) | |
| transport | No | Optional: filter by transport type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool lists recent servers but omits details on result ordering, pagination, or any side effects. For a read-only list, this is acceptable but lacks depth.
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 two sentences long, front-loading the purpose and use case without wasted words. Every sentence adds value.
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 only two simple parameters and no output schema, the description adequately covers purpose and usage. It could mention output format or pagination behavior but is largely complete for a straightforward list tool.
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 coverage is 100% with parameter descriptions already provided. The description adds no extra meaning or examples beyond what the schema offers, so a baseline score of 3 is appropriate.
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 tool lists the most recently updated MCP servers, with a specific use case: discovering what's new or actively maintained. It differentiates from siblings like search_mcp_servers and get_server_details by focusing on recency.
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 advises using the tool to discover new or maintained servers, providing clear context. However, it does not explicitly mention when not to use it or direct users to alternatives like search_mcp_servers for filtered queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Agent Almanac catalog of 9,000+ MCP (Model Context Protocol) servers by name, capability, or description. Use this when the user is looking for an MCP server that does a specific thing (e.g. 'an MCP server for postgres', 'MCP server for github issues', 'video processing MCP').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query — e.g. 'postgres', 'video processing', 'github actions' | |
| transport | No | Optional: filter by transport type | |
| limit | No | Max results (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses the scope (9,000+ servers) and search fields. Does not mention pagination or result format, but for a search tool this is adequate.
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 that are front-loaded and efficient. First sentence states purpose, second gives usage context with examples. No wasted 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?
Given 3 params, no output schema, and no annotations, the description covers purpose, usage, and examples. It could mention the return format, but is largely complete for an agent to invoke correctly.
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 description adds little beyond schema. It reiterates that query searches by name/capability/description, but does not explain transport or limit beyond schema.
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 the tool searches MCP servers by name/capability/description. Distinguishes from siblings 'get_server_details' and 'list_recent_servers'.
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 when to use: 'Use this when the user is looking for an MCP server that does a specific thing'. Provides examples. Does not mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: get_server_details retrieves details for a specific server, list_recent_servers lists recently updated servers, and search_mcp_servers searches the catalog. No functional overlap.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_server_details, list_recent_servers, search_mcp_servers), making them predictable and easy to understand.
With only 3 tools, the server is well-scoped for its purpose of discovering and getting details about MCP servers. Each tool is essential, and the count is not excessive or insufficient.
The tool set covers the core workflows: searching, browsing recent additions, and retrieving full details. Minor gaps exist (e.g., no pagination or filtering beyond search), but the surface is adequate for typical use.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
Search and get install details on MCP servers, right from your agent -- a unified marketplace index.
Search a curated directory of 300+ verified AI agents, MCP servers, and agentic tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/survivorforge/agentalmanac-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
