AgentIndex
Server Details
Search a curated directory of open-source AI agents, MCP servers and AI developer tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 5 tools
Each tool maps to a clearly distinct action: search by keyword/category, browse top-ranked tools, list categories, fetch one record by id, and submit a new tool. The descriptions explicitly cross-reference when to use one over another (search_tools vs get_trending), leaving no real overlap.
All five tools follow a clean verb_noun snake_case pattern (get_tool_detail, get_trending, list_categories, search_tools, submit_tool). No mixing of conventions or vague single-word names.
Five tools is a tight, well-scoped set for a directory server: discover (search/trending/categories), inspect (detail), and contribute (submit). It is slightly lean — no filtering or submission-status tooling — but nothing feels redundant.
The core read lifecycle is well covered: broad browsing, filtered search, category enumeration, and full detail retrieval, plus a submission path with documented constraints. Minor gaps exist (no way to check a submission's status or deep-filter results), but agents can work around them.
Available Tools
5 toolsget_tool_detailGet tool detailsARead-onlyInspect
Get the full AgentIndex record for one tool when you already have its id (from search_tools, get_trending or an AgentIndex URL such as agentindex.app/en/tool//). Returns name, description, long intro, summary, features, use cases, pros and cons, when to choose or skip it, compatibility, install command, license, stars, last update date, tags, rank_score, website and GitHub URL. Fields that were never filled in are omitted. Returns an isError result if no tool has that id; use search_tools to find the right id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Tool id exactly as returned by search_tools or get_trending, usually "<github-owner>-<repo>", e.g. "hangwin-mcp-chrome". |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Tool id for get_tool_detail |
| cons | No | Weaknesses |
| name | Yes | |
| pros | No | Strengths |
| tags | No | |
| stars | No | GitHub stars, e.g. "12.3k" |
| ai_tags | No | |
| license | No | |
| skip_if | No | When to pick something else |
| summary | No | Short summary, { en, zh } or a string |
| website | No | |
| category | No | |
| features | No | Feature list |
| choose_if | No | When to pick this tool |
| use_cases | No | Use case list |
| github_url | No | |
| intro_long | No | Longer introduction |
| rank_score | No | AgentIndex rank, 0-100 |
| description | No | |
| last_updated | No | |
| compatibility | No | Compatible clients and platforms |
| install_command | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral context beyond that: unfilled fields are omitted from the response, and a missing id yields an isError result rather than an empty record. It stops short of anything about response size or latency, but the mutation/error profile is well disclosed.
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 first sentence is well front-loaded and the error-handling sentence earns its place, but the middle sentence enumerates roughly twenty returned fields that the output schema already defines — that list is the bulk of the description and is largely redundant padding.
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 single-parameter read tool with an output schema, an agent needs only the precondition, what comes back, and the failure mode — all three are present, along with the alternative to use on failure. Nothing required for a correct call is missing.
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% and the single 'id' parameter's format ('<github-owner>-<repo>', example given) lives in the schema. The description only echoes the provenance of the id ('as returned by search_tools or get_trending'), adding no syntax or validation detail, so this is the baseline case where the schema does the work.
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?
States a precise verb+resource ('get the full AgentIndex record for one tool') and scopes it to the single-record-by-id case, which cleanly separates it from search_tools, get_trending and list_categories. An agent can pick this tool without 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the precondition ('when you already have its id') and names the upstream sources that supply that id (search_tools, get_trending, an AgentIndex URL). It also names the fallback ('use search_tools to find the right id') for the failure case, so both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trendingGet top-ranked toolsARead-onlyInspect
Get the highest-ranked tools across the whole AgentIndex directory, for questions like "what are the best/most popular open-source AI tools right now". Ranking is by rank_score (0-100), which combines GitHub stars, how recently the repository was updated and the quality of its documentation; it is not a weekly-growth chart. Use search_tools instead when the user needs a specific kind of tool. Returns an array of {id, name, category, description, stars, rank_score, ai_tags, website, github_url}.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of tools to return (1-50, default 10). |
Output Schema
| Name | Required | Description |
|---|---|---|
| tools | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description still adds real value by explaining what rank_score measures (GitHub stars, recency, documentation quality) and what it does not measure. It does not mention pagination or result-set behavior, which is the only remaining gap.
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?
Front-loads the purpose, then qualifies usage, then explains ranking, then lists return fields. Every sentence carries information, though enumerating the return fields is somewhat redundant given the output schema exists.
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?
Coverage is complete for this tool's complexity: usage intent, alternative routing, ranking semantics, and return shape are all stated, while annotations carry the safety profile and an output schema documents the return structure.
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% and the single 'limit' parameter is fully documented in the schema (1-50, default 10). The description adds no extra meaning about the parameter, so the baseline 3 applies.
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?
States a specific verb and resource ('Get the highest-ranked tools across the whole AgentIndex directory') and immediately scopes it against the sibling alternatives, so an agent can distinguish it from search_tools 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the triggering user intent ('what are the best/most popular open-source AI tools right now'), explicitly names the fallback ('Use search_tools instead when the user needs a specific kind of tool'), and clarifies a common misread ('it is not a weekly-growth chart'). When/when-not/alternative are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList categoriesARead-onlyInspect
List every category in the AgentIndex directory with the number of tools in it, largest first. Call this before using the category filter of search_tools to get valid names, or to give the user an overview of the directory. Returns an array of {category, count}. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| categories | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description still adds useful behavior: descending sort order by tool count and confirmation that no arguments are needed. It doesn't discuss staleness/caching, but for a static directory listing that is a minor gap.
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?
Three short sentences, front-loaded with the action and ordering, followed by usage and return shape. Every sentence carries information; no 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?
The output schema exists and the description still summarizes the return shape ({category, count}), plus routing guidance to the dependent sibling tool. Combined with read-only annotations, an agent has everything needed to call it 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?
Zero parameters, so the baseline is 4. The description even confirms 'Takes no arguments', which matches the empty schema and prevents an agent from hunting for filter arguments.
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?
States a specific verb and resource ('List every category in the AgentIndex directory') and adds scope details — count per category, sorted largest first. Clearly distinguishable from siblings like search_tools or get_trending.
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 call it: before using the category filter of search_tools to obtain valid names, or to give the user a directory overview. Names the sibling tool whose parameter it feeds, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_toolsSearch toolsARead-onlyInspect
Find AI agents, MCP servers and AI developer tools in the AgentIndex directory by keyword and/or category. Use this when the user describes a need ("MCP server for Postgres", "browser automation agent"); use get_trending instead to browse the best tools without a query. Every keyword must appear (case-insensitive) in the name, description, tags or category. Results are ordered by rank_score, highest first. Returns an array of {id, name, category, description, stars, website, github_url, tags, rank_score}; an empty array means no match, so retry with fewer or broader keywords. Pass an id to get_tool_detail for features, use cases and the install command.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (1-50, default 10). | |
| query | No | Space-separated keywords, all of which must match, e.g. "postgres mcp" or "browser automation". Omit to list the top tools of a category. | |
| category | No | Exact category name from list_categories (case-insensitive), e.g. "Browser Automation" or "RAG / Knowledge Base". Omit to search all categories. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tools | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint=false, so the description carries the real behavioral load: it explains the AND-all-keywords matching rule, the fields searched (name, description, tags, category), case-insensitivity, sort order by rank_score descending, and that an empty array is a legitimate no-match result. That is well beyond what the annotations provide.
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?
Front-loads purpose, then usage routing, then matching semantics, then return shape — each sentence introduces new information with no padding. The example queries are short and directly actionable.
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?
An output schema exists, yet the description still names the sibling routing targets (list_categories for categories, get_tool_detail for the follow-up call), which is what an agent needs to chain tools correctly. Everything required for a correct zero-required-param call is present.
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%, including the AND semantics for query, the exact-category constraint and the limit bounds, so the schema already does the heavy lifting. The description restates the matching rule but adds no format, syntax or default detail the schema lacks, so the baseline 3 applies.
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?
States a specific verb (Find) and resource (AI agents, MCP servers, AI developer tools in the AgentIndex directory) plus the retrieval axis (keyword and/or category). It explicitly names the sibling get_trending as the no-query alternative, so an agent can distinguish it without opening either schema.
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?
Gives a concrete when-to-use trigger ('when the user describes a need') with example phrasings, names the alternative and the condition that selects it ('use get_trending instead to browse the best tools without a query'), and adds a recovery path for the empty-result case ('retry with fewer or broader keywords').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_toolSubmit a toolAIdempotentInspect
Suggest a GitHub repository (an AI agent, MCP server or AI developer tool) for listing on AgentIndex. No login or API key needed. The submission is queued for human review, usually within 1-3 days; it does not appear in search results immediately. Tools are listed only if the repository is public and has at least 100 stars. Check with search_tools first that the tool is not already listed. Returns {success, message, github_url}, or an isError result if the URL is not a GitHub repository URL or the submission service is unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Optional address that receives an email when the review is done. Only send it if the user provided it. | ||
| github_url | Yes | Repository URL in the form https://github.com/<owner>/<repo>, e.g. https://github.com/modelcontextprotocol/servers. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| success | Yes | |
| github_url | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnlyHint=false, idempotentHint=true, openWorldHint=true). The description adds genuinely new behavior: the submission is queued for human review in 1-3 days, does not appear in search immediately, and returns an isError result when the URL is not a GitHub repo URL or the service is down. That is real operational context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action in the first clause, then prerequisites, timing, and return shape. Information-dense with little waste, though it is a very long single paragraph and the return-shape sentence is somewhat redundant given an output schema exists.
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?
Covers identity, eligibility, timing expectations, duplicate-check guidance, and error conditions for a two-parameter tool with an output schema. An agent has everything needed to decide whether and how to invoke it; nothing material is missing.
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% (both parameters fully documented, including the email 'only send if the user provided it' caveat), so the baseline is 3. The description adds semantic value by explaining what makes a github_url acceptable at the tool level (public GitHub repo, 100+ stars) and what failure looks like, going beyond the regex pattern in 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?
States a specific verb and resource ('Suggest a GitHub repository ... for listing on AgentIndex') and scopes the acceptable inputs (AI agent, MCP server, AI developer tool). An agent can distinguish this submission tool from the read-only siblings like search_tools and get_tool_detail without inspecting any schema.
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 check search_tools first to avoid duplicate submissions, states no login/API key is needed, and gives the eligibility gate (public repo with 100+ stars). This is exactly the when-to-use, prerequisite, and alternative guidance the dimension asks for.
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 updates
- Changed
get_tool_detail2 fields changed- changed
Input schema / properties / id / descriptionPrevious value: -"Tool ID (e.g. \"owner-repo-name\")"New value: +"Tool id exactly as returned by search_tools or get_trending, usually \"<github-owner>-<repo>\", e.g. \"hangwin-mcp-chrome\"." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "ai_tags": { + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "category": { + "type": [ + "string", + "null" + ] + }, + "choose_if": { + "description": "When to pick this tool" + }, + "compatibility": { + "description": "Compatible clients and platforms" + }, + "cons": { + "description": "Weaknesses" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "features": { + "description": "Feature list" + }, + "github_url": { + "type": [ + "string", + "null" + ] + }, + "id": { + "description": "Tool id for get_tool_detail", + "type": "string" + }, + "install_command": { + "type": [ + "string", + "null" + ] + }, + "intro_long": { + "description": "Longer introduction" + }, + "last_updated": { + "type": [ + "string", + "null" + ] + }, + "license": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "pros": { + "description": "Strengths" + }, + "rank_score": { + "description": "AgentIndex rank, 0-100", + "type": [ + "number", + "null" + ] + }, + "skip_if": { + "description": "When to pick something else" + }, + "stars": { + "description": "GitHub stars, e.g. \"12.3k\"", + "type": [ + "string", + "number", + "null" + ] + }, + "summary": { + "description": "Short summary, { en, zh } or a string" + }, + "tags": { + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "use_cases": { + "description": "Use case list" + }, + "website": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "id", + "name" + ], + "type": "object" +}
- Changed
get_trending6 fields changed- added
Input schema / properties / limit / defaultAdded value: +10 - changed
Input schema / properties / limit / descriptionPrevious value: -"Number of results (default 10, max 50)"New value: +"Number of tools to return (1-50, default 10)." - added
Input schema / properties / limit / maximumAdded value: +50 - added
Input schema / properties / limit / minimumAdded value: +1 - changed
Input schema / properties / limit / typePrevious value: -"number"New value: +"integer" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "tools": { + "items": { + "properties": { + "ai_tags": { + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "category": { + "type": [ + "string", + "null" + ] + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "github_url": { + "type": [ + "string", + "null" + ] + }, + "id": { + "description": "Tool id for get_tool_detail", + "type": "string" + }, + "name": { + "type": "string" + }, + "rank_score": { + "description": "AgentIndex rank, 0-100", + "type": [ + "number", + "null" + ] + }, + "stars": { + "description": "GitHub stars, e.g. \"12.3k\"", + "type": [ + "string", + "number", + "null" + ] + }, + "website": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "tools" + ], + "type": "object" +}
- Changed
list_categories1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "categories": { + "items": { + "properties": { + "category": { + "type": "string" + }, + "count": { + "type": "integer" + } + }, + "required": [ + "category", + "count" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "categories" + ], + "type": "object" +}
- Changed
search_tools8 fields changed- changed
Input schema / properties / category / descriptionPrevious value: -"Filter by category name"New value: +"Exact category name from list_categories (case-insensitive), e.g. \"Browser Automation\" or \"RAG / Knowledge Base\". Omit to search all categories." - added
Input schema / properties / limit / defaultAdded value: +10 - changed
Input schema / properties / limit / descriptionPrevious value: -"Max results (default 10, max 50)"New value: +"Maximum number of results (1-50, default 10)." - added
Input schema / properties / limit / maximumAdded value: +50 - added
Input schema / properties / limit / minimumAdded value: +1 - changed
Input schema / properties / limit / typePrevious value: -"number"New value: +"integer" - changed
Input schema / properties / query / descriptionPrevious value: -"Search keyword"New value: +"Space-separated keywords, all of which must match, e.g. \"postgres mcp\" or \"browser automation\". Omit to list the top tools of a category." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "tools": { + "items": { + "properties": { + "category": { + "type": [ + "string", + "null" + ] + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "github_url": { + "type": [ + "string", + "null" + ] + }, + "id": { + "description": "Tool id for get_tool_detail", + "type": "string" + }, + "name": { + "type": "string" + }, + "rank_score": { + "description": "AgentIndex rank, 0-100", + "type": [ + "number", + "null" + ] + }, + "stars": { + "description": "GitHub stars, e.g. \"12.3k\"", + "type": [ + "string", + "number", + "null" + ] + }, + "tags": { + "items": { + "type": "string" + }, + "type": [ + "array", + "null" + ] + }, + "website": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "tools" + ], + "type": "object" +}
- Changed
submit_tool5 fields changed- changed
Input schema / properties / email / descriptionPrevious value: -"Contact email for review updates (optional)"New value: +"Optional address that receives an email when the review is done. Only send it if the user provided it." - added
Input schema / properties / email / formatAdded value: +"email" - changed
Input schema / properties / github_url / descriptionPrevious value: -"GitHub repository URL (e.g. https://github.com/owner/repo)"New value: +"Repository URL in the form https://github.com/<owner>/<repo>, e.g. https://github.com/modelcontextprotocol/servers." - added
Input schema / properties / github_url / patternAdded value: +"^https://github\\.com/[^/\\s]+/[^/\\s]+/?$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "github_url": { + "type": "string" + }, + "message": { + "type": "string" + }, + "success": { + "type": "boolean" + } + }, + "required": [ + "success", + "message" + ], + "type": "object" +}
5 tool updates
- First observed
get_tool_detail - First observed
get_trending - First observed
list_categories - First observed
search_tools - First observed
submit_tool
Related MCP Connectors
Search a curated directory of 300+ verified AI agents, MCP servers, and agentic tools.
Search a curated directory of AI tools, AI agents and MCP servers by task, pricing and platform.
Search 7,500+ MCP servers, agent skills and open-source AI projects. Verified official links.
31Search curated AI resources: AI tools, MCP servers, prompts, skills, plugins, learning.
Related MCP Servers
- AlicenseAqualityCmaintenanceMCP server that searches 3,800+ open-source AI agents by capability, ranked by real traction (stars, activity). Query it from Claude Desktop, Cursor, Cline, or Windsurf.353 npmMIT
- AlicenseAqualityDmaintenanceEnables AI agents to search a directory of 13,870+ MCP servers, 4,384+ agent skills, and plugins from Remote OpenClaw, returning install commands directly.352 npm6MIT

Archestackofficial
AlicenseAqualityBmaintenanceSearch, rank and compare open-source AI projects (self-hosted AI apps, coding agents, MCP servers) with scores, GitHub facts and open-source picks for paid tools.6170 npmMIT- AlicenseAqualityBmaintenanceEnables AI agents to search a curated directory of Claude Code agent skills, MCP servers, and plugin marketplaces ranked by community signal.451 npm1MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.