What can you do with this server?

This MCP server enables AI assistants to discover and explore 4,000+ public APIs from the ls-apis dataset using three tools: * Search APIs (search-apis): Search by keyword (matching API names and descriptions), filter by category (e.g., weather, finance, animals), filter by authentication type (apiKey, OAuth, or no), and limit the number of results returned. * List Categories (list-categories): Retrieve all API categories along with the count of APIs in each, sorted by popularity. * List Providers (list-providers): Retrieve all data providers that contribute APIs to the dataset, along with their contribution count, sorted by popularity.

ls-apis-mcp

by koalyptus

Overview Schema Related Servers Score Discussions

TypeScript

Local

ls-apis

Public APIs Discovery for Humans & Agents

A curated collection of 5,000+ public APIs with a powerful CLI search tool. Discover, filter, and explore APIs by category, authentication type.

Features

Comprehensive Dataset - 5,000+ APIs aggregated from multiple sources
Smart Search - Filter by query, category, authentication type
Colored Output - Syntax-highlighted results (use --no-color to disable)
Multiple Output Formats - Text or JSON output
MCP Server - AI-friendly API search via Model Context Protocol
Extensible Architecture - Pluggable fetchers for adding new API sources
TypeScript - Fully typed for better developer experience

Related MCP server: MCP Public APIs

Installation

git clone https://github.com/koalyptus/ls-apis.git
cd ls-apis
npm install
npm build

Quick Start

npm install -g @ls-apis/cli
npm build
ls-apis -q weather

Via npm link (local development)

npm run build
npm link --workspace=@ls-apis/cli
ls-apis -q weather

Usage

CLI Search

# Search by keyword
npm run ls-apis -- -q weather

# Filter by category
npm run ls-apis -- -c weather

# Filter by authentication type
npm run ls-apis -- -a apiKey

# Combine filters
npm run ls-apis -- -q weather -c data -a oauth

# Limit results
npm run ls-apis -- -q weather -l 10

# Output as JSON
npm run ls-apis -- -q weather -o json

# Sort by name
npm run ls-apis -- -q weather -s name

# List all categories
npm run ls-apis -- categories

# List categories sorted by count
npm run ls-apis -- categories --sort count

# List categories as JSON
npm run ls-apis -- categories --output json

Commands

Command	Description
`categories`	List all API categories with counts
`providers`	List all data providers
`config`	Show config settings and file path
`qa`	Run QA checks (terminal summary)

# Run QA via CLI
npm run ls-apis -- qa

# Save QA report to custom path
npm run ls-apis -- qa -f ./my-report.json

QA Options

Flag	Alias	Description
`--sort`	`-s`	Sort by: name (default), count
`--output`	`-o`	Output format: text (default), json

Providers Options

Flag	Alias	Description
`--sort`	`-s`	Sort by: name (default), count
`--output`	`-o`	Output format: text (default), json

Options

Flag	Alias	Description
`--query`	`-q`	Search query (filters name, description)
`--category`	`-c`	Filter by category
`--auth`	`-a`	Filter by auth type (apiKey, OAuth, no)
`--limit`	`-l`	Max results to show (default: 20)
`--output`	`-o`	Output format: text or json (default: text)
`--sort`	`-s`	Sort results: name, category, auth
`--no-color`		Disable colors in output
`--help`	`-h`	Show help
`--version`	`-V`	Show version

Note: Colors are enabled by default. Use --no-color or set NO_COLOR=1 environment variable to disable.

Configuration File

A config file is automatically created at ~/.ls-apis on first run. You can edit it to set personal defaults. CLI flags always override config values.

Location: ~/.ls-apis (your home directory)

{
  "limit": 10,
  "descriptionMaxLength": 150,
  "colors": true
}

Key	Default	Description
`limit`	20	Default max results
`descriptionMaxLength`	250	Max chars before truncation
`colors`	true	Enable terminal colors

The config file is plain JSON. Edit it manually to customize defaults, or delete it to regenerate with built-in values.

Example Output

Found 2 APIs:
  Weather API
    Description: Get real-time weather data for any location...
    Link: https://api.weather.example.com
    Auth: apiKey
    Categories: weather, data
    Sources: apis-guru

  Weather2 API
    Description: Comprehensive weather forecasting service...
    Link: https://api.weather2.example.com
    Auth: OAuth
    Categories: weather, forecast
    Sources: publicapis-dev

MCP Server

ls-apis includes an MCP server for AI assistants to search and discover public APIs via natural language.

Tools

Tool	Description
`search-apis`	Search public APIs by query, category, auth type, and limit
`list-categories`	List all API categories with API counts
`list-providers`	List all data providers with API counts

Resources

URI	Description
`apis://data`	Full aggregated API dataset (JSON)
`apis://categories`	All API categories with counts (JSON)
`apis://providers`	All data providers with counts (JSON)
`apis://stats`	Dataset summary statistics (JSON)

Setup

npm install

Configuration

VS Code / GitHub Copilot

Create .vscode/mcp.json in your project root:

VS Code will ask for permission on first run — this is standard for project-local MCP servers. Approve once and it won't prompt again.

{
  "servers": {
    "ls-apis": {
      "command": "npx",
      "args": ["tsx", "packages/mcp-server/src/index.ts"],
      "cwd": "/path/to/ls-apis"
    }
  }
}

Switch Copilot Chat to Agent mode to use MCP tools.

Claude Desktop

Edit claude_desktop_config.json (%APPDATA%\Claude\ on Windows, ~/Library/Application Support/Claude/ on macOS):

{
  "mcpServers": {
    "ls-apis": {
      "command": "npx",
      "args": ["tsx", "packages/mcp-server/src/index.ts"],
      "cwd": "/path/to/ls-apis"
    }
  }
}

Cursor

Create .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "ls-apis": {
      "command": "npx",
      "args": ["tsx", "packages/mcp-server/src/index.ts"],
      "cwd": "/path/to/ls-apis"
    }
  }
}

Verification

After configuring, the client should discover the tools and resources listed above. You can also test via CLI:

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npm run mcp

Project Structure

See AGENTS.md for the full project layout. The repo is a monorepo with four packages under packages/:

aggregator — fetches, normalizes, deduplicates API data from upstream sources
cli — command-line search tool published as ls-apis
shared — types, config, search logic, paths consumed by all packages
mcp-server — MCP server for AI-friendly API queries (stdio transport)

Scripts

# Install dependencies
npm install

# Run all tests with coverage
npm test

# Run specific package tests
npm run test:aggregator
npm run test:cli
npm run test:shared
npm run test:mcp

# Typecheck all workspaces
npm run typecheck

# Lint & format
npm run lint
npm run format

# Run aggregator (generates data/apis.json in CLI package)
npm run aggregate

# Run QA checks on aggregated data
npm run qa

# Run CLI directly
npm run ls-apis -- -q <query>

# Run MCP server (stdio transport for AI clients)
npm run mcp

# Build all packages (shared → CLI). Note: excludes mcp-server (build separately below).
npm run build

# Build MCP server separately (not part of the root build)
npm run build:mcp

CLI Build and Publish Notes

The published CLI entrypoint is packages/cli/dist/index.js.
packages/cli/src/ contains TypeScript sources.
packages/cli build script runs:
- tsc to compile TS into dist/
- tsc-esm-fix --target dist to add .js extensions required by Node ESM runtime
prepack in the CLI package runs the build before packaging, so npm publish includes ready-to-run JavaScript.

Data Schema

The packages/cli/data/apis.json file contains metadata and aggregated API data with the following structure:

interface DataFile {
  timestamp: string; // ISO 8601 UTC timestamp of processing
  providers: Provider[]; // Data source providers
  apis: ApiEntry[]; // Aggregated API entries
}

interface Provider {
  name: string; // Provider identifier (e.g., 'apis-guru')
  url: string; // Data source URL
}

interface ApiEntry {
  name: string;
  description?: string;
  link: string;
  auth?: string; // apiKey, OAuth, etc.
  cors?: string;
  categories: string[];
  openapiSpec?: string; // OpenAPI spec URL if available
  sources: string[]; // Which fetchers found this API
}

Adding a New API Source

Create a new fetcher in packages/aggregator/src/sources/:

touch packages/aggregator/src/sources/mysource.fetcher.ts

Implement the SourceFetcher interface:

import type { SourceFetcher, ApiEntry } from '../types';

export const mysourceFetcher: SourceFetcher = {
  name: 'mysource',
  fetchApis: async (): Promise<ApiEntry[]> => {
    // Fetch and normalize APIs from your source
    return [
      /* ApiEntry items */
    ];
  },
};

Run the aggregator to fetch and update:
```
npm run aggregate
```

Fetchers are auto-loaded via loadAllFetchers() in sources/index.ts.

Testing

Tests use Vitest with v8 coverage:

# Run all tests
npm test

# Run specific package tests
npm run test:aggregator
npm run test:cli
npm run test:shared
npm run test:mcp

# Watch mode
cd packages/cli && npm run test:watch

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

3 tools

list-categoriesA

List all API categories with the count of APIs in each, sorted by popularity.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the burden. It states the behavior (list with counts, sorted), but omits traits like read-only nature or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words, perfectly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with no parameters or output schema; description covers key aspects but could mention read-only behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; description adds meaning by specifying output includes count and sort order, earning baseline 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists all API categories with counts and sorted by popularity, distinguishing it from siblings like list-providers and search-apis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving categories but does not specify when to use this tool versus alternatives like list-providers or search-apis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-providersA

List all data providers with the count of APIs contributed by each, sorted by popularity.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses sorting behavior and count inclusion, but omits authentication, rate limits, or side effects; no annotations to supplement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence efficiently conveys purpose and behavior with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers essential functionality for a parameterless tool, but could mention potential pagination or error conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters mean schema coverage is 100%; description adds nothing but baseline is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists data providers with API count and sorts by popularity, distinguishing it from siblings like list-categories and search-apis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool over alternatives; lacks context on scenarios or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search-apisA

Search public APIs from the ls-apis dataset. Filter by query, category, auth type, and limit results.

ParametersJSON Schema

Name	Required	Description
`auth`	No	Filter by authentication type: apiKey, OAuth, or no
`limit`	No	Maximum number of results to return (default: 20)
`query`	No	Search term to match against API names and descriptions
`category`	No	Filter by category (e.g., weather, finance, animals)

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the transparency burden. It describes a straightforward search and filter operation, but does not mention outcomes like empty results, pagination, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core purpose. Every word adds value, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 optional parameters with 100% schema coverage and no output schema, the description is functional but misses details like default limit (20) or match behavior. It could be more complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter's description is already in the schema. The tool description merely restates 'filter by query, category, auth type, and limit' without adding new semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'search public APIs' and lists filtering criteria. It differentiates from sibling tools list-categories and list-providers which focus on listing entities rather than searching.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for searching and filtering APIs, contrasting with siblings that list categories/providers. However, it lacks explicit when-to-use or 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0Jun 4, 2026
- First observedlist-categories
- First observedlist-providers
- First observedsearch-apis

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing categories, listing providers, and searching APIs. There is no ambiguity or overlap between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (list-categories, list-providers, search-apis). The naming is predictable and uniform.

Tool Count5/5

With 3 tools, the server is well-scoped for its purpose of exploring an API dataset. Each tool serves a distinct function without unnecessary bloat.

Completeness4/5

The tool set covers the core operations for browsing and searching the dataset: listing categories, providers, and filtering APIs. A minor gap might be a tool to get details on a specific API, but the search tool can retrieve relevant results.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

apis-io B
io.apis
Read-only MCP server over the APIs.io catalog — discover APIs, providers, tags & artifacts.
Search Developer Tools Documentation Access
1332
Zyla API Hub A
com.zylalabs
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
Developer Tools
82
Apis Guru A
io.github.pipeworx-io
APIs.guru MCP — keyless directory of 2,500+ public APIs and their OpenAPI specs.
Developer Tools Documentation Access
352
MCP Registry Server A
ai.com.mcp
Publish and discover MCP servers via the official MCP Registry. Powered by HAPI MCP server.
Developer Tools Search
336,314

Related MCP Servers

Semantic API
Search API Testing Documentation Access
peter-j-thompson
A
license
B
quality
D
maintenance
Natural language API discovery MCP server. Search 700+ API capabilities across 163 current providers, get, exact endpoints, auth setup, and code snippets. Supports auto-discovery of new APIs.
Updated 7 months ago (2026-02-20 22:55 UTC)
3
1
MIT
MCP Public APIs
Search Developer Tools API Testing
Attilio81
F
license
A
quality
D
maintenance
An MCP server that indexes the public-apis catalogue, allowing LLMs to search and filter over 1,400 public APIs by category, authentication type, and technical requirements. It facilitates precise API discovery for developers by providing tools to query specific features like HTTPS support and CORS compatibility.
Updated 6 months ago (2026-03-19 14:31 UTC)
3
-
mcp-public-apis
Search API Testing Open Data
josephsenior
A
license
A
quality
D
maintenance
An MCP server that gives AI coding agents real-time access to the public-apis dataset, enabling search, live probing, and code snippet generation for 1,500+ free public APIs.
Updated 6 months ago (2026-03-10 21:40 UTC)
7
66
5
MIT
ClawQL
API Testing Developer Tools Search
danielsmithdevelopment
A
license
Not graded
quality
C
maintenance
An MCP server for API discovery and execution with a token-efficient search -> execute workflow over OpenAPI, Google Discovery, and optional native GraphQL and gRPC sources.
Updated 2 days ago (2026-09-03 21:46 UTC)
44
12
Apache 2.0

Appeared in Searches

Remote MCP servers without authentication

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/koalyptus/ls-apis'

If you have feedback or need assistance with the MCP directory API, please join our Discord server