An MCP server that wraps the Modrinth API, letting AI agents search/read Modrinth data and publish or manage Minecraft mods and versions.
Verify your Modrinth token and get the authenticated user (modrinth_whoami).
Search public Modrinth projects (modrinth_search_projects).
Get project metadata by slug or ID (modrinth_get_project).
List a project's published versions (modrinth_list_project_versions).
Create a new project as a draft and upload jars as new versions (modrinth_create_project, modrinth_create_version).
Edit metadata of existing versions (modrinth_modify_version).
Provides tools for interacting with the Modrinth API, allowing AI agents to search projects, retrieve project and version metadata, create new projects as drafts, publish new versions by uploading jar files, and edit existing version metadata.
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., "@modrinth-mcp Search for a mod that adds more ores"
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 that wraps the Modrinth API so an AI agent (Claude Code, Claude Desktop, Cursor, …) can search projects, read project/version metadata, and publish Minecraft mods — create projects and upload built jars as new versions.
Tool | Auth | What it does |
| ✅ | Verify your token; return the authenticated user. |
| – | Search public Modrinth projects. |
| – | Get a project's metadata by slug or id. |
| – | List a project's published versions. |
| ✅ | Publish a new version by uploading one or more jars. |
| ✅ | Create a new project (as a draft). |
| ✅ | Edit metadata of an existing version. |
Read-only tools work without a token. Anything that writes needs a Modrinth Personal Access Token.
Related MCP server: ModWrench MCP Server
Create a PAT at https://modrinth.com/settings/pats with these scopes:
Read projects
Read versions
Create versions
Write versions
Set it as the MODRINTH_TOKEN environment variable.
/plugin marketplace add justinscott12/modrinth-mcp
/plugin install modrinth-mcp@justinscott12It runs the published npm package under the hood via npx. Claude Code
plugins have no token-entry UI, so the server reads its token from the
MODRINTH_TOKEN environment variable in the environment Claude Code
runs in. Set it before launching Claude Code, e.g.:
# macOS/Linux (add to your shell profile to persist)
export MODRINTH_TOKEN=your-modrinth-pat
# Windows PowerShell (persist for your user)
setx MODRINTH_TOKEN "your-modrinth-pat"Then restart Claude Code and run modrinth_whoami to confirm. Read-only
tools (search, get project/versions) work without a token.
Add to your MCP client config (e.g. Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"modrinth": {
"command": "npx",
"args": ["-y", "@justinscott12/modrinth-mcp"],
"env": {
"MODRINTH_TOKEN": "your-modrinth-pat"
}
}
}
}Or in Claude Code directly:
claude mcp add modrinth --env MODRINTH_TOKEN=your-modrinth-pat -- npx -y @justinscott12/modrinth-mcpVariable | Default | Purpose |
| – | Modrinth Personal Access Token. Required for write actions. |
| unset | Set to |
|
| Override the User-Agent sent to Modrinth. |
modrinth_whoami — confirm auth works.
modrinth_create_project — create the project page (created as a draft).
modrinth_create_version — upload your built jar(s) with the target game_versions and loaders.
Submit the project for review on the Modrinth site when ready.
Note:
create_versionandcreate_projectpublish public content. Only call them when you actually intend to publish.
npm install
MODRINTH_STAGING=1 MODRINTH_TOKEN=your-staging-pat npm startThe server speaks MCP over stdio. stdout is reserved for the protocol; logs go to stderr.
Create a NEW Modrinth project (the initial project page). Created as a DRAFT — nothing is public until you submit it for review on the site or set requested_status. This is a write action; only call it when the user explicitly asks to create a new project. After it exists, publish jars with modrinth_create_version.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Long-form markdown description for the project page. | |
| slug | Yes | URL slug, 3-64 chars, e.g. 'no-anvil-limit'. Becomes modrinth.com/project/<slug>. | |
| title | Yes | Project display name, e.g. 'No Anvil Limit'. | |
| wiki_url | No | Wiki/docs URL. | |
| icon_path | No | Absolute path to an icon image (png/jpg/webp/gif/svg). | |
| categories | No | Featured categories, e.g. ['utility','game-mechanics']. Must be valid Modrinth categories for the project_type. | |
| issues_url | No | Issue tracker URL. | |
| license_id | No | SPDX license id, e.g. 'MIT', 'GPL-3.0-only', 'ARR'. | |
| source_url | No | Source code repo URL. | |
| client_side | No | Whether the mod is needed on the client. Editable later. | |
| description | Yes | Short one-or-two-sentence summary shown in search. | |
| discord_url | No | Discord invite URL. | |
| server_side | No | Whether the mod is needed on the server. Editable later. | |
| project_type | No | Project type. Defaults to mod. | |
| requested_status | No | Desired status once processed. Stays a draft until you submit for review on the site. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly=false but description adds critical context: the project is created as a DRAFT, nothing public until submission or requested_status set. This is essential behavioral disclosure beyond the schema, though it could detail whether creation is reversible or requires auth.
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 concise sentences, front-loaded with purpose and key behavior, no fluff. Efficient use of 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 the tool's complexity (15 params, 4 enums) and no output schema, the description gives enough context for safe use: draft creation, explicit user request, next steps. Could note more about potential errors, but adequate.
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 covers all 15 parameters with descriptions, but the tool description adds the key semantic of the 'requested_status' field (stays draft until review) and clarifies the draft workflow. This supplements the schema without redundancy.
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 it creates a new Modrinth project, explicitly notes it's a draft, and contrasts with sibling tool modrinth_create_version ('After it exists, publish jars with...'). This distinguishes it from related tools effectively.
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?
Provides explicit guidance: 'only call it when the user explicitly asks to create a new project' and explains draft status process. Names the alternative for publishing versions, offering clear when/why.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a NEW version to an existing Modrinth project by uploading one or more built jar files. This is a write action that publishes public content — only call it when the user has explicitly asked to publish. The project must already exist on Modrinth.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name for the version. | |
| loaders | No | Mod loaders, e.g. ['fabric']. Defaults to fabric. | |
| featured | No | Feature this version. | |
| changelog | No | Markdown changelog. | |
| file_paths | Yes | Absolute path(s) to the jar file(s) to upload. First is treated as the primary file. | |
| project_id | Yes | Target project slug or id (must already exist). | |
| dependencies | No | Dependencies. e.g. Fabric API as required: [{project_id:'P7dR8mSH', dependency_type:'required'}]. | |
| version_type | No | Release channel. | |
| game_versions | Yes | Supported Minecraft versions, e.g. ['1.21.8']. | |
| version_number | Yes | Version string, e.g. '1.21.8' or '2.0.0+1.21.8'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so it's a write operation. The description adds context beyond annotations by emphasizing that it 'publishes public content' and requires explicit user consent, plus the existence prerequisite. It doesn't contradict annotations and provides extra safety-relevant context, though it could note that published content becomes publicly visible.
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 three sentences, front-loaded with the main action, followed by safety guidance and a prerequisite. No redundant details or fluff. Every sentence adds value: the first states the core action, the second sets usage boundaries, the third notes a prerequisite.
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 has 10 parameters, no output schema, and annotations that cover safety hints, the description provides a high-level overview and important context (explicit user consent, existing project). It doesn't explain return values (no output schema required), and all parameters are documented in the schema. The description is sufficient for an agent to understand when and how 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?
Schema description coverage is 100%, so the schema already documents all 10 parameters with descriptions and examples (e.g., dependencies example). The description adds minimal extra meaning by referencing 'uploading jar files' (file_paths) and 'existing project' (project_id), but it doesn't compensate beyond the schema. Baseline 3 is appropriate given high coverage.
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: 'Publish a NEW version to an existing Modrinth project by uploading one or more built jar files.' It uses a specific verb ('publish') and resource ('version to existing project'), distinguishing it from siblings like modrinth_modify_version (modify) and modrinth_create_project (create project). It also scopes it to existing projects, which is clear.
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 usage conditions: 'only call it when the user has explicitly asked to publish' and 'The project must already exist on Modrinth.' This gives clear when-to-use guidance and a prerequisite, though it does not explicitly name alternative tools for other operations (e.g., modify). It implies when not to use it but lacks direct sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Modrinth project's metadata by slug or id (title, type, loaders, game_versions, published version ids, status).
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_slug | Yes | Project slug (e.g. 'no-anvil-limit') or id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds the specific metadata fields returned, which is useful. However, it doesn't disclose any additional behavioral traits like rate limits, authentication requirements, or error behavior (e.g., what happens if the slug/id doesn't exist). With annotations covering the safety profile, a 3 is appropriate.
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 is concise and front-loaded with the core purpose. It lists the metadata fields in parentheses, which is efficient. 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?
For a simple read-only tool with one parameter and no output schema, the description is fairly complete. It states what the tool does and what metadata is returned. The only gap is that it doesn't mention error handling or edge cases (e.g., invalid slug), but given the simplicity and the annotations, this is acceptable. A 4 is appropriate.
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 only parameter 'id_or_slug' is described as 'Project slug (e.g. 'no-anvil-limit') or id.' The description adds the example slug and clarifies that it can be either a slug or an id, which is helpful. However, it doesn't add much beyond the schema, so baseline 3 is correct.
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's purpose: 'Get a Modrinth project's metadata by slug or id' and lists the specific metadata fields returned (title, type, loaders, game_versions, published version ids, status). This is a specific verb+resource combination that distinguishes it from siblings like modrinth_search_projects (search) and modrinth_list_project_versions (list versions).
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 implies usage: use this when you need project metadata by slug or id. It doesn't explicitly state when not to use it or mention alternatives, but the sibling names (search, list versions) provide context. The description could be improved by noting that this is for fetching a single project's metadata, not for searching or listing versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a project's published versions (version_number, id, type, loaders, game_versions, download url of primary file).
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_slug | Yes | Project slug or id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, so safety is covered. The description adds behavioral context by explicitly listing the fields in the response, which is valuable given there is no output schema. No contradictions.
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, focused sentence that directly states the action and the returned data, with no wasted words. It front-loads the purpose and keeps the detail relevant.
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 (one parameter, read-only, no output schema), the description sufficiently covers the return fields, which helps the agent understand what to expect. It omits potential details like pagination or ordering, but these are not critical for a basic listing 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 only parameter id_or_slug is described in the schema ('Project slug or id.'), and the description repeats that without adding further detail. Since schema coverage is 100%, the description adds no extra semantic meaning, 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 specifies the exact action ('List a project's published versions') and enumerates the returned fields (version_number, id, type, loaders, game_versions, download url), clearly distinguishing it from siblings like modrinth_get_project (project metadata) and modrinth_search_projects.
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 tool's purpose is self-evident from its name and description—use it to list versions of a known project. It doesn't explicitly state when not to use it (e.g., for modifications use modrinth_modify_version), but the context of sibling tools provides enough clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit metadata of an EXISTING published version (name, changelog, version_type, loaders, game_versions, featured). Does not upload files.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| loaders | No | ||
| featured | No | ||
| changelog | No | ||
| version_id | Yes | The version id to modify. | |
| version_type | No | ||
| game_versions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only but non-destructive operation. The description adds useful context that the target must be an existing published version and that files are not uploaded. However, it does not clarify partial-update semantics: when omitting optional fields, those fields remain unchanged, are reset, or some other behavior. This gap could lead the agent to invoke the tool incorrectly.
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, focused sentence that front-loads the essential action and ends with an important boundary. Every element earns its place and there is no filler or repetition.
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 description is enough to know what the tool does and where it applies, but it is still a mutation tool with 7 parameters and no output or side-effect details. It doesn't mention partial update semantics, what happens when omitted fields are used, or return value expectations, which matters because there is no output schema.
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 schema has very low individual property description coverage (14%), but the description lists all editable metadata fields. This provides grouping context, yet it does not explain meanings or constraints beyond the few schema types. The description partially compensates for the schema gap, but doesn't fully describe values like 'loaders' or 'game_versions' beyond their names.
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 uses a specific verb ('Edit'), identifies the exact resource ('metadata of an EXISTING published version'), and enumerates the fields affected. It also explicitly distinguishes itself from file-upload operations, making the tool's function unmistakable and differentiating it from siblings like modrinth_create_version.
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 clearly implies this is for modifying existing versions rather than creating or uploading, and the phrase 'Does not upload files' provides a useful exclusion. It does not explicitly name alternatives, but the target use case is evident from the wording and sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public Modrinth projects. Returns a compact list of hits (slug, title, project_type, downloads, description).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max hits. | |
| query | Yes | Search text, e.g. 'sodium' or 'anvil'. | |
| facets | No | Optional raw Modrinth facets JSON, e.g. '[["project_type:mod"],["categories:fabric"]]'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful context beyond annotations: it constrains the scope to public projects, promises a compact hit list, and enumerates returned fields (slug, title, project_type, downloads, description). This is useful given no output schema exists.
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, front-loaded sentence that states the verb and resource first, then summarizes the return shape. Every word contributes value, with no filler or repetition.
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 read-only search tool with good annotations and full schema coverage, the description is mostly complete: it identifies scope, result compactness, and fields. It doesn't mention default limits or facet behavior in detail, but those are already addressed by parameter descriptions, so the gap is minor.
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 each parameter (query, limit, facets) has a meaningful description. The tool description adds no extra parameter semantics beyond what the schema already provides, so the 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?
Description uses a specific verb ('Search') and clearly identifies the resource ('public Modrinth projects'), which distinguishes it from sibling tools like get_project or list_project_versions. It also states the result shape, making the tool's function immediately clear.
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 implies when to use the tool by naming 'Search,' but it does not explicitly contrast it with alternatives or state when not to use it. For example, it doesn't mention that get_project would be preferable for retrieving a known project's full details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the configured Modrinth token and return the authenticated user (username, id, email, role). Use this first to confirm auth works.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which covers the safety profile. The description adds that it verifies the token and returns auth details, which is a modest extension beyond annotations. It doesn't mention potential side effects (there are none) or rate limits, but for a verification call, this is acceptable.
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, both essential. The first sentence states the action and return values, the second provides usage guidance. Zero waste, front-loaded purpose.
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 parameters and no output schema, the description provides the necessary information: what it does, what it returns, and when to use it. Annotations cover safety. It lacks details like error cases or rate limits, but for a simple auth check, the description is sufficiently 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?
The tool takes zero parameters, and schema coverage is effectively complete (empty schema). The description adds meaning by explaining the output (username, id, email, role), which is valuable for the agent even though it's not required for parameter semantics. With no parameters, a baseline of 4 is appropriate since the description compensates for the lack of parameter documentation.
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 uses a specific verb ('Verify') and resource ('configured Modrinth token'), clearly stating it returns the authenticated user's details (username, id, email, role). This is unambiguous and distinct from sibling tools, which focus on projects or versions.
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 says 'Use this first to confirm auth works', providing clear context for when to invoke this tool. However, it doesn't explicitly mention alternatives or when not to use it, though the purpose is so specific that the usage is clear.
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.0modrinth_create_projectmodrinth_create_versionmodrinth_get_projectmodrinth_list_project_versionsmodrinth_modify_versionmodrinth_search_projectsmodrinth_whoamiScored across 7 tools
Each tool targets a distinct action and resource: authentication (whoami), search, fetch, list versions, create project, create version, and modify version. No two tools appear to perform the same operation; even search and get are clearly differentiated by result granularity.
All tools follow the consistent modrinth_<verb>_<object> pattern (e.g., modrinth_search_projects, modrinth_create_version). The naming is predictable and grammatically uniform, making it easy for an agent to infer the action and target.
Seven tools is well within the ideal 3–15 range. Each tool serves a clear, non-redundant purpose in the domain of Modrinth project and version management, covering authentication, discovery, publishing, and editing without bloat.
The toolset covers core workflows: authenticate, search, inspect, publish, and update. It lacks project-level updates (e.g., changing project metadata) or deletion, but those are less critical for the common publish-and-iterate cycle. The missing operations are non-blocking for most agent tasks.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Search a curated directory of 300+ verified AI agents, MCP servers, and agentic tools.
