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., "@mcp-public-apis Find free weather APIs with no auth"
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.
Give your AI coding agent the ability to find, test, and integrate any of 1,500+ free public APIs — instantly.
Data sourced from the community-maintained public-apis list · synced daily
An MCP (Model Context Protocol) server that gives AI coding agents real-time access to the public-apis dataset. Instead of copy-pasting API documentation, your agent can search, probe, and generate working code — all in one conversation.
You: "Find me a free weather API with no auth that supports HTTPS"
Agent: [calls search_apis] → returns top matches with auth/HTTPS/CORS details
You: "Test the first one — show me what the response looks like"
Agent: [calls probe_api] → live GET request, returns status + response shape
You: "Generate an axios snippet for it"
Agent: [calls generate_snippet] → ready-to-paste curl, fetch, and axios codeRelated MCP server: mcpify
Pick the config for your client and paste it in. No build step required — npx handles everything.
File: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
File: %APPDATA%\Claude\claude_desktop_config.json (Windows)
{
"mcpServers": {
"public-apis": {
"command": "npx",
"args": ["mcp-public-apis"]
}
}
}File: .cursor/mcp.json in your project root (or ~/.cursor/mcp.json globally)
{
"mcpServers": {
"public-apis": {
"command": "npx",
"args": ["mcp-public-apis"]
}
}
}File: ~/.codeium/windsurf/mcp_config.json
{
"mcpServers": {
"public-apis": {
"command": "npx",
"args": ["mcp-public-apis"]
}
}
}Open VS Code → Cline sidebar → MCP Servers tab → Add Server → paste:
{
"public-apis": {
"command": "npx",
"args": ["mcp-public-apis"]
}
}git clone https://github.com/josephsenior/pblic-apis-mcp-server
cd pblic-apis-mcp-server
npm install
npm run build
node dist/index.jsTool | What it does | Key parameters |
| Fuzzy-search 1,500+ APIs by keyword, category, auth type, and HTTPS |
|
| List every category with its API count | — |
| Full record for one API by name |
|
| Live HTTP GET to any endpoint — returns status, latency, and response preview |
|
| Side-by-side view of all APIs in a category |
|
| Only APIs that need zero authentication |
|
| Paste-ready |
|
search_apis parametersParameter | Type | Default | Description |
| string | — | Fuzzy-match against API name and description |
| string | — | Exact category name (use |
|
| — | Filter by auth requirement |
| boolean |
| Exclude non-HTTPS APIs |
| number |
| Max results (1–20) |
MCP Client (Claude / Cursor / etc.)
│ JSON-RPC over stdio
▼
mcp-public-apis server
│
├─ In-memory cache (24 h TTL)
│
└─ GitHub raw · public-apis/public-apis README.mdOn first use the server fetches the public-apis README from GitHub, parses every Markdown table row into structured PublicAPI objects, and stores them in a 24-hour in-memory cache.
All search and filter operations run locally against that cache — no external call per query.
probe_api is the only tool that makes a request to a third-party endpoint (the one you explicitly pass in).
All API records come from public-apis/public-apis — a community-maintained list of 1,500+ free APIs across 60+ categories. The data is fetched fresh every 24 hours.
Compare all APIs within a category side by side, with a summary of auth and HTTPS support.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category name to compare | |
| limit | No | Max APIs to compare (2-10, default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it compares APIs and summarizes auth/HTTPS, but does not disclose any behavioral traits such as pagination, ordering, or error handling. The description is straightforward but lacks depth for a fully transparent behavior.
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 of 14 words, very concise and front-loaded with the main action. However, it could include a bit more detail on output or usage without becoming verbose.
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 two well-documented parameters and no output schema, the description adequately conveys the core functionality. However, it leaves ambiguity about the output format (e.g., table, JSON), which could be important for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add extra meaning beyond 'category' and 'limit' already explained in the input schema, so it meets the baseline but provides no additional enrichment.
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 compares all APIs within a category side by side, specifying it provides a summary of auth and HTTPS support. This distinguishes it from siblings like get_api_detail (single API) and search_apis (generic search), giving a specific verb and resource.
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 when needing a side-by-side comparison of APIs in a category, but it does not explicitly state when to use this tool over alternatives like get_api_detail or search_apis. No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns APIs that require zero authentication, optionally filtered by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter | |
| httpsOnly | No | Only return HTTPS APIs (default: true) | |
| limit | No | Max results (1-20, default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It lacks details on response format, pagination, prerequisites, or side effects, beyond what the schema implies.
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 zero waste, front-loaded with core action and optional filter.
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?
Lacks return format description (no output schema) and fails to contextualize among siblings, leaving the agent with gaps despite tool 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 coverage is 100% with descriptions for all parameters; the description adds no new meaning beyond restating the category filter, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool returns APIs requiring zero authentication, with optional category filtering, distinguishing it from siblings like search_apis (likely all APIs) and get_categories (categories only).
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 using this tool for no-auth APIs but does not explicitly contrast with alternatives (e.g., search_apis if auth needed) or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates ready-to-use curl, fetch, and axios code snippets for calling a given API endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The API endpoint URL | |
| apiKey | No | Optional API key to include | |
| apiKeyParam | No | Query parameter name for the API key (default: "api_key") | |
| headers | No | Additional headers as key-value pairs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states the generation action without disclosing any side effects, error behavior, or constraints (e.g., rate limits, authentication needs, or idempotency).
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, no filler, directly communicates the tool's output. Every word 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?
Given no output schema and 4 parameters including a nested object, the description is minimal but covers the core function. Lacks context about return format, error handling, or usage hints needed for an API client 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?
Parameter descriptions in the schema cover 100% of the 4 parameters, so baseline is 3. The description adds no extra meaning beyond 'for calling a given API endpoint' which is already implied by the parameter 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 clearly states the tool generates ready-to-use code snippets in three specific formats (curl, fetch, axios) for a given API endpoint, making the purpose unambiguous and distinct from sibling tools like compare_apis or search_apis.
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_api_detail or probe_api, nor does it specify conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details about a specific API by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | API name to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden, but it only says 'Get full details' without disclosing side effects, auth needs, rate limits, or what exactly is returned.
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?
One sentence, no redundant information, perfectly concise.
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 1 parameter, no output schema, and no annotations, the description is minimal but adequate for a simple lookup; however, it fails to explain what 'full details' entails, leaving some ambiguity.
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 single parameter 'name' is described in the schema as 'API name to look up'; the description adds 'by name' but adds no new semantics. Baseline 3 applies due to 100% schema 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 'Get full details' and the resource 'specific API by name', distinguishing it from sibling tools like search_apis or compare_apis.
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 (needing full details of a specific API) but provides no explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all available API categories with the number of APIs in each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value (categories and counts), which is the main behavioral aspect. No side effects are implied, and although no annotations exist, the description is adequate for a read-only list.
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 with no redundancy, efficiently conveying the tool's function.
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 parameterless tool with no output schema, the description is mostly complete. It could be slightly more specific about the return structure, but it 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?
There are no parameters, so schema coverage is 100% trivially. The description does not need to add parameter info, but the 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?
The description clearly states it returns 'all available API categories with the number of APIs in each,' which is specific and distinct from sibling tools like search_apis or get_api_detail.
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 implicitly indicates use when needing a list of categories and counts, but lacks explicit guidance on when not to use or alternatives. However, the tool is simple and 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.
Makes a safe live HTTP GET request to a given API endpoint and returns the response status, shape, and latency.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The API endpoint URL to probe | |
| apiKey | No | Optional API key to include | |
| apiKeyParam | No | Query parameter name for the API key (default: "api_key") | |
| timeoutMs | No | Request timeout in ms (default: 5000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. While it mentions 'safe' and outputs, it lacks details on error handling, redirects, authentication handling, or rate limits. 'Safe' is vague without elaboration.
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, 12 words, front-loaded with key verb and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about return values, error cases, and behavior. It only hints at output with 'status, shape, latency' but lacks detail.
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?
All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds no extra meaning beyond what the schema already provides.
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 performs a safe live HTTP GET request to an API endpoint and returns status, shape, and latency, distinguishing it from sibling tools like compare_apis or search_apis.
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. It does not mention exclusions, prerequisites, or scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public-apis list by keyword, category, auth type, and HTTPS support.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Fuzzy search keyword | |
| category | No | Filter by category name | |
| auth | No | Filter by auth type | |
| httpsOnly | No | Only return HTTPS APIs (default: true) | |
| limit | No | Max results to return (1-20, default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the search action. It does not disclose pagination, default behavior (e.g., when query is empty), or any side effects. The description adds minimal value beyond the name and schema.
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 of 12 words efficiently conveys the tool's purpose with no unnecessary information. It is front-loaded and every word 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?
No output schema is provided, and the description does not explain what is returned (e.g., list of APIs, fields). For a search tool with 5 parameters, the description should specify result format or pagination to aid correct use.
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 baseline is 3. The description lists the filter dimensions but adds no additional meaning or context beyond what the schema already provides (e.g., fuzzy search is already noted in 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 action ('Search') and the resource ('public-apis list'), listing specific filters (keyword, category, auth type, HTTPS support). It distinguishes this tool from siblings like compare_apis and find_no_auth_apis by focusing on general search.
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 for general searching but provides no explicit guidance on when to use this tool versus alternatives like compare_apis or find_no_auth_apis. No exclusions or prerequisites are mentioned.
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. Dates show when Glama detected each change.
v1.0.0compare_apisfind_no_auth_apisgenerate_snippetget_api_detailget_categoriesprobe_apisearch_apisEach tool has a clear, distinct purpose: comparing APIs, finding auth-free ones, generating code snippets, getting details, listing categories, probing endpoints, and searching. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., compare_apis, find_no_auth_apis, generate_snippet), making them predictable and easy to understand.
With 7 tools, the set is well-scoped for browsing and testing public APIs. Each tool adds distinct value without redundancy or over-engineering.
The tool set covers the full workflow: discovery (search, categories, detail), analysis (compare, no-auth filter), testing (probe), and code generation (snippet). No obvious gaps for a read-only API directory.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for live public-data APIs and Skills for AI agents.
An MCP server that gives your AI access to the source code and docs of all public github repos
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
One AI endpoint to search and call 22k+ MCP servers; 50+ hosted tools work instantly, no key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/josephsenior/public-apis-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
