Click on "Deploy 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., "@Hermes Atlas MCP Server search for memory persistence tools"
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.
MCP server for the Hermes Atlas ecosystem directory — gives AI agents instant access to 169+ quality-filtered tools, skills, plugins, and integrations for Hermes Agent.
Hermes Agent has a massive and growing ecosystem. This MCP server turns that ecosystem into instant expandability — agents can discover, compare, and recommend tools without leaving their conversation.
Related MCP server: agent101-mcp
Add to your MCP client config:
{
"mcpServers": {
"hermes-atlas": {
"command": "npx",
"args": ["hermes-atlas-mcp"]
}
}
}Or with Docker/stdio:
{
"mcpServers": {
"hermes-atlas": {
"command": "node",
"args": ["/path/to/hermes-atlas-mcp/dist/index.js"]
}
}
}Tool | Description | Example |
| Full-text search across 169 repos |
|
| Browse 12 ecosystem categories |
|
| Detailed repo info + AI summary |
|
| Match tools to your use case |
|
| Trending/rising repos this week |
|
| Curated lists overview |
|
| Specific curated list with per-repo descriptions |
|
| Aggregate stats, category breakdown, latest version |
|
| RAG over research knowledge base (requires embeddings) |
|
The ask_atlas tool provides RAG-powered answers grounded in 27 research files (6,500+ chunks) covering Hermes Agent installation, architecture, skills system, deployment, and best practices.
Install the embeddings (~70MB) separately:
npx hermes-atlas-mcp install-embeddings
# or equivalently:
npx hermes-atlas-installThe server auto-detects the embeddings at startup and adds the ask_atlas tool when available. Without embeddings, all other tools work perfectly using the summaries index.
┌────────────────────────────────────────────┐
│ hermes-atlas-mcp │
│ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ repos │ │ summaries │ │
│ │ (169) │ │ (AI-generated│ ← bundled │
│ └────┬─────┘ │ per-repo) │ or fetched│
│ │ └──────────────┘ │
│ ┌────┴──────────────────────┐ │
│ │ lists, featured, stats │ ← cached │
│ └───────────────────────────┘ (4hr TTL) │
│ │
│ ┌───────────────────────────┐ optional │
│ │ chunks.json (70MB) │ ← install │
│ │ RAG knowledge base │ separately│
│ └───────────────────────────┘ │
└────────────────────────────────────────────┘
│
stdio (MCP)Zero-config: Works immediately with no API keys needed
Offline-capable: Bundled data works without network; fresh data fetched in background
Light: Core data is ~300KB; embeddings are opt-in at 70MB
Fast: Full-text search and recommendations complete in <50ms
All data sourced from ksimback/hermes-ecosystem — a community-curated directory security-reviewed before inclusion.
File | Size | Content |
| 60KB | 169 repos — owner, name, description, stars, category, official flag |
| 189KB | AI-generated summaries + highlights per repo |
| 2KB | 6 curated lists (best memory, top skills, deployment, etc.) |
| 26KB | Per-repo descriptions within each curated list |
| 241B | Currently featured/trending repos |
| 374B | Latest Hermes Agent version |
| 70MB | 6,554 research chunks with pre-computed embeddings (optional) |
git clone https://github.com/your-user/hermes-atlas-mcp.git
cd hermes-atlas-mcp
npm install
npm run build
# Test interactively
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0.1"}}}' | npm start
# Watch mode
npm run devMIT. Data sourced from hermes-ecosystem (MIT/CC BY 4.0).
Get aggregate ecosystem statistics — total repos, total stars, category breakdown, latest Hermes version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It implies a read-only operation without side effects, but it does not explicitly state that it is non-destructive or requires no authentication. The description is adequate but not explicit.
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 a single concise sentence that front-loads the purpose and lists key data points. Every word is informative, with no redundancy or filler.
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 simplicity (no parameters, no annotations, no output schema), the description sufficiently explains what it does and what data it returns. It could be improved by specifying the return format (e.g., JSON object), but it is largely complete for a basic aggregation 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?
The tool has zero parameters, and schema description coverage is 100%. Per guidelines, 0 parameters defaults to baseline 4. No additional parameter information is needed.
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 retrieves aggregate ecosystem statistics, listing specific items like total repos, total stars, category breakdown, and latest Hermes version. It uses a specific verb ('Get') and resource, and it distinguishes itself from siblings that focus on individual items.
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 no guidance on when to use this tool versus alternatives like get_repo or list_categories. It does not mention scenarios where the tool is appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currently featured/trending repos in the Hermes ecosystem — the best new additions and rising projects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It discloses the return of featured/trending repos but omits details like ordering, pagination, or read-only nature. Adequate for a simple zero-param tool.
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 with no extraneous words. Front-loaded with purpose. Highly concise and clear.
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 tool with no parameters, no output schema, and no annotations, the description is functionally complete. Could mention output format or count of items, but current version is sufficient.
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, so schema coverage is 100%. Description adds value by explaining what the tool returns, beyond just the schema. Baseline for zero parameters is 4.
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 verb 'Get', resource 'featured/trending repos', and scope 'Hermes ecosystem'. Distinguishes from siblings like search_repos and get_repo.
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?
Implies use for discovering trending repos but does not explicitly state when to use this tool versus alternatives like search_repos or list_categories. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific curated list with per-repo descriptions and recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | List slug (e.g. 'best-memory-providers', 'deployment-options') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states the basic action without revealing whether the operation is read-only, any prerequisites, or potential side effects. A simple retrieval is implied but not confirmed.
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 a single sentence that efficiently conveys the core purpose without any filler or redundant information. Every word serves a purpose, making it easy for the agent to parse quickly.
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 simplicity of this tool (one parameter, no output schema), the description is adequate but leaves some ambiguity. It does not explain what 'per-repo descriptions and recommendations' means practically, nor does it describe the response format. A bit more detail about what the agent can expect in the output would improve completeness.
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?
The input schema already includes a full description of the 'slug' parameter with examples, achieving 100% schema coverage. The tool description adds no additional semantic value beyond what the schema provides, so it meets the baseline but does not exceed it.
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 action 'Get' and the resource 'specific curated list', and adds key details about the response including per-repo descriptions and recommendations. This distinguishes it from sibling tools like 'get_lists' which likely retrieves multiple lists, and 'get_repo' which gets a single repository.
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 does not provide any guidance on when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tools serve different purposes. The agent must infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get curated lists (best memory providers, top skills, deployment options, etc.). Each list has a title, description, and per-repo descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions the return structure (title, description, per-repo descriptions) but does not disclose whether it is read-only, idempotent, requires authentication, or any side effects. The word 'Get' implies read, but not explicitly.
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, no wasted words. Purpose is front-loaded, examples are helpful. Every sentence earns its place.
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 zero-parameter tool without output schema, the description is fairly complete: it explains what lists contain and gives examples. However, it could clarify that it returns all available curated lists (implied but not explicit). No mention of pagination or count, but acceptable for this simplicity.
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?
The input schema has zero parameters, so description needs to add no parameter semantics. Following the guideline for 0 params, baseline is 4. The description does not contradict the 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?
The description clearly states the tool gets curated lists, with concrete examples (best memory providers, top skills, deployment options). It distinguishes from siblings like get_list (which presumably gets a single list) and search_repos (which searches by query). The verb 'Get' and resource 'curated lists' are specific.
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?
No guidance on when to use this tool versus alternatives like get_list, search_repos, or get_featured. The description does not provide context for selection, making it difficult for an AI agent to choose correctly without external knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific repo including its AI-generated summary, highlights, and category. Use owner/repo format (e.g. 'NousResearch/hermes-agent').
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Repo slug in owner/repo format (e.g. 'NousResearch/hermes-agent') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the type of information returned (AI summary, highlights, category) but does not mention authorization needs, rate limits, or potential side effects. For a read-only tool, this is adequate but not comprehensive.
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 consists of two sentences: the first defines the purpose, the second provides usage guidance with an example. Every word earns its place; there is no redundancy.
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 tool with one parameter and no output schema, the description is fairly complete. It hints at return values (summary, highlights, category). However, it omits error conditions (e.g., repo not found) and does not explain the output format, which is partially mitigated by the simplicity.
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% (the slug parameter has a description in the schema). The description adds an example ('NousResearch/hermes-agent') and clarifies the format, providing value beyond the schema. Baseline 3 plus extra value gives 4.
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 'Get detailed information about a specific repo including its AI-generated summary, highlights, and category.' It also specifies the input format, distinguishing it from sibling tools like get_list or search_repos which handle multiple repos.
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 an example of the expected slug format but does not explicitly guide when to use this tool versus alternatives like search_repos or get_featured. It implies usage for a single specific repo but lacks context on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ecosystem categories with repo counts. Useful for discovering what types of tools exist in the Hermes ecosystem.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It correctly conveys a read-only list operation without side effects, but does not mention any potential pagination or sorting behavior. However, the tool is simple with no parameters, making the description 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?
The description is two concise sentences, front-loaded with the primary action and followed by a brief usage context. Every sentence serves a purpose without redundancy.
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 tool with no parameters and no output schema, the description fully covers what the tool does and its typical use case. It provides sufficient information for an AI agent to decide to invoke it.
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?
There are no parameters, and schema coverage is 100%. Baseline for zero params is 4 since the description adds no parameter-specific information but also does not need to. It correctly avoids misleading statements.
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 all ecosystem categories with repo counts, using specific verb and resource. It distinguishes from siblings like get_repo and ecosystem_stats by focusing exclusively on categories.
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 indicates it is useful for discovering tool types, but does not explicitly state when to use alternatives or when not to use this tool. The context of siblings implies usage boundaries, but it is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get personalized recommendations for Hermes ecosystem tools based on a use case description. Matches repos using AI-generated summaries and highlights. Great for answering 'what should I use for X?' questions.
| Name | Required | Description | Default |
|---|---|---|---|
| use_case | Yes | Describe what you're trying to accomplish (e.g. 'I need persistent memory for my agent', 'I want to deploy Hermes on Kubernetes') | |
| limit | No | Max recommendations (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It notes that the tool uses AI-generated summaries and highlights for matching, but does not mention authentication, rate limits, or how 'personalized' recommendations are generated (e.g., based on user history). The description is adequate 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 concise (two sentences) and front-loaded with the purpose. It includes an example in the use_case parameter description, which is helpful. Could be slightly more structured, but efficient overall.
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 no output schema and low complexity (2 simple parameters), the description is fairly complete. It explains the tool's purpose, how it works, and when to use it. However, it does not describe the output format or any limitations, which would be beneficial for a recommendation 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%, and both parameters have clear descriptions. The tool description does not add extra meaning beyond what the schema already provides, so 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?
The description clearly states the verb ('Get'), resource ('personalized recommendations for Hermes ecosystem tools'), and context ('based on a use case description'). It distinguishes from sibling tools like search_repos by mentioning AI-generated summaries and highlights, and gives a concrete use case ('what should I use for X?').
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 explicitly indicates when to use the tool ('Great for answering what should I use for X? questions'). It does not mention when not to use it or provide alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Hermes Atlas ecosystem for repos matching a query. Searches across repo names, descriptions, categories, and owners. Returns ranked results with star counts and official badges.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g. 'memory persistence', 'cybersecurity skills', 'deployment docker') | |
| category | No | Optional category filter (e.g. 'Skills & Skill Registries', 'Memory & Context') | |
| official_only | No | Only return official Nous Research repos | |
| limit | No | Max results to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states results are ranked and include star counts and badges, but does not disclose defaults (e.g., limit=20), pagination behavior, or whether the operation is read-only. While not misleading, more detail would improve transparency.
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, front-loaded with the main purpose and followed by search scope and result details. Every sentence adds value with no redundancy.
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?
With 4 parameters and no output schema, the description covers the main behavior but omits details like default limit, sorting criteria, and how to interpret results. It is adequate but not fully complete for complex use cases.
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%, so baseline is 3. The description adds no parameter-specific meaning beyond the schema descriptions, which already define each parameter clearly.
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 searches for repos in the Hermes Atlas ecosystem, specifies the search fields (names, descriptions, categories, owners), and mentions returned results include star counts and badges. This distinguishes it from siblings like get_repo (single repo) or list_categories.
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?
No explicit guidance on when to use search vs alternative tools such as get_repo for exact matches or list_categories for browsing. Usage is implied as a general search, but lacks exclusions or context.
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.
v0.1.0ecosystem_statsget_featuredget_listget_listsget_repolist_categoriesrecommendsearch_reposScored across 8 tools
Each tool targets a distinct function: stats, featured repos, curated lists, single repo details, categories, personalized recommendations, and search. No two tools have overlapping purposes, minimizing agent confusion.
Most tools follow a verb_noun pattern with underscores (get_featured, get_list, search_repos), but ecosystem_stats uses noun_verb and recommend lacks an underscore, creating mild inconsistency.
Eight tools are appropriate for an ecosystem explorer, covering search, browsing, recommendations, and stats without being overwhelming or sparse.
The set covers key exploration tasks: searching, filtering by category or list, getting details, and recommendations. Missing is a bulk listing of all repos, but search_repos can substitute, so only minor gaps.
Directory of APIs, merchants, and tools AI agents can actually use.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Independent directory of agentic AI tools — search, compare & recommend via MCP. Read-only.
Search, inspect, recommend, and explain rated AI tools through Agent Radar.
