Read-only MCP server for searching and browsing the public Agent Connectors directory.
Search listings by keyword against name, slug, or description, optionally filtered by category slug and limited to max 50 results.
Fetch a single listing by its slug.
List categories with names, slugs, and listing counts.
Query it over stdio or optional streamable HTTP; it does not run, install, or test the listed servers.
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., "@Agent Connectors MCP server search the connector directory for Postgres 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.
Read-only MCP server that searches the public Agent Connectors directory of MCP servers and AI agent connectors.
The tools read https://agentconnectors.dev/api/tools.json?limit=all and follow next if the response is paged. They return directory records. They do not run, install, or test the servers in those records.
search_tools — match a query, with an optional category slug, against listing name, slug, and description.
get_tool — one listing by slug.
list_categories — category name, slug, and listing count, counted from the catalogue response.
Example query for search_tools:
{ "query": "web search", "category": "search" }Related MCP server: Mediawork MCP Server
This repository is not published to npm. Clone it, install dependencies, and point your client at the clone. Requires Node.js 22 or newer.
git clone https://github.com/JaniJegoroff/agent-connectors-mcp.git
cd agent-connectors-mcp
npm installThe server speaks MCP over stdin and stdout:
node --experimental-strip-types src/index.tsReplace /absolute/path/to/agent-connectors-mcp with the absolute path of your clone. Run npm install in that directory first.
Add this to claude_desktop_config.json:
{
"mcpServers": {
"agent-connectors": {
"command": "node",
"args": ["--experimental-strip-types", "src/index.ts"],
"cwd": "/absolute/path/to/agent-connectors-mcp"
}
}
}Project file .cursor/mcp.json, or the global Cursor MCP settings:
{
"mcpServers": {
"agent-connectors": {
"command": "node",
"args": ["--experimental-strip-types", "src/index.ts"],
"cwd": "/absolute/path/to/agent-connectors-mcp"
}
}
}Project file .vscode/mcp.json. cwd is the clone root:
{
"servers": {
"agent-connectors": {
"type": "stdio",
"command": "node",
"args": ["--experimental-strip-types", "src/index.ts"],
"cwd": "${workspaceFolder}"
}
}
}Optional streamable HTTP, bound to 127.0.0.1:8791:
node --experimental-strip-types src/index.ts --httpThe HTTP endpoint is http://127.0.0.1:8791/mcp. Set PORT to use another port. Set AGENT_CONNECTORS_API to point the catalogue fetch at another tools.json URL.
Glama builds this image and introspects the server over stdio.
docker build -t agent-connectors-mcp .
docker run -i --rm agent-connectors-mcpThe image is node:22-slim. It installs production dependencies with npm ci --omit=dev, copies src, and starts stdio mode with node --experimental-strip-types src/index.ts.
Fetch one Agent Connectors listing by slug. This does not run or test that server.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Listing slug, such as firecrawl. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the read-only nature and, crucially, the negative behavior that this does not run or test the server. It lacks disclosure of error/not-found behavior or auth requirements, so not a full 5.
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 tight sentences, zero filler, with the scoping clarification front-loaded right after the core 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?
For a simple single-param lookup with no output schema, the description is nearly complete. It could mention what happens on a miss or that auth is required, but given schema richness it is 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?
Only one parameter and schema coverage is 100% with an example ('firecrawl') in the schema. The description adds nothing beyond the schema, so 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 (Fetch) and resource (one Agent Connectors listing) with the lookup key (slug). The clause 'This does not run or test that server' sharply distinguishes it from any execution-oriented neighbor.
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?
Clearly establishes this is a read-only lookup by slug and rules out the action of running/testing the server. No explicit routing to siblings (search_tools, list_categories), but the disambiguation from execution is a strong usage cue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Agent Connectors categories and how many listings each one has.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. "List" implies a safe read, and the description usefully discloses the response contents (categories plus per-category counts), but it says nothing about permissions, pagination, or ordering. Partial disclosure only.
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?
A single sentence that front-loads the resource and appends the most decision-relevant detail (listing counts). No filler whatsoever.
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?
This is a simple, zero-parameter discovery tool with no output schema, so the description must convey the return shape — and it does, by naming categories and their listing counts. Slightly incomplete in that it doesn't hint at pagination or ordering of the returned list.
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, so there are no arguments whose semantics could be under-specified. Baseline 4 applies; the description adds nothing here because there is nothing to add.
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?
Specific verb ("List") plus a well-defined resource ("Agent Connectors categories") and it states the payload detail — listing counts per category. It doesn't explicitly contrast itself with search_tools or get_tool, but the purpose is distinct enough that confusion is unlikely.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as search_tools. The agent must infer on its own that this is a discovery step preceding a search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Agent Connectors directory. Returns matching listings from the public catalogue. This does not run or test those servers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches to return. Defaults to 20. | |
| query | Yes | Words to match against the name, slug, or description. Empty matches every listing in the category. | |
| category | No | Category slug, such as search or data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does a fair job: it establishes this is a read of a public catalogue and explicitly that it does not execute or test servers, a real behavioral boundary. It omits auth/rate-limit context and any pagination behavior, which for a public search endpoint 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, each earning its place: purpose, return content, and a negative scope guard, all front-loaded with 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?
There is no output schema, so the description's note that it returns catalogue listings appropriately fills that gap, and the three parameters are covered by the schema. Complete enough for a simple directory search, missing only result-size/paging expectations.
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 query, limit, and category are already well documented in the schema. The description adds no format or matching-syntax detail beyond that, which is acceptable at the baseline but not additive.
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 ('Search the Agent Connectors directory') and clarifies the return ('matching listings from the public catalogue'). The scope note that it 'does not run or test those servers' usefully separates it from actually executing a tool, though it never names the sibling search/get tools it complements.
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?
Usage is implied: use this to find listings. The negative clause ('does not run or test those servers') rules out an execution interpretation, but there is no guidance on when to prefer get_tool for a known tool or list_categories for browsing by category.
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.0get_toollist_categoriessearch_toolsScored across 3 tools
Each tool has a clearly distinct purpose: search_tools returns multiple catalogue matches, get_tool fetches a single listing by slug, and list_categories enumerates categories. The descriptions even explicitly clarify that search/get do not run servers, further separating read-only lookup semantics.
All three names follow a clean verb_noun snake_case pattern (search_tools, get_tool, list_categories). No mixed conventions or vague verbs.
Three tools is a reasonable, well-scoped surface for a read-only directory/lookup server, with no redundancy. It is on the thin side and could justify one more browsing tool, but nothing is gratuitous.
Search, single-slug lookup, and category enumeration cover the basic browse flow, but list_categories only returns counts with no obvious tool to fetch listings within a category (unless search supports that filter). This leaves a potential browse-by-category dead end, though agents can likely work around it via search.
Search MCP servers, MCP clients and AI agents, and retrieve listing details. Free, read-only access.
MCP server for the HubSpot Integrations Center HubDB: search and retrieve integration data.
Search and discover MCP servers and agent tools listed in the MCP Harbor directory.
Search a curated directory of agent tools, MCP servers, APIs, protocols and skills. No auth.