cporter202/agentic-ai-apis: A Curated Directory of 2,531 Agent, Model and MCP APIs

What Problem a 2,531-Entry Directory Actually Solves

The stated problem is discovery time. The README frames the repository as a launchpad rather than a junk drawer, and the Start Here section reduces the workflow to three steps: pick one of the three layers, open that category README, then click through to the provider page for implementation details, pricing and docs. That is a shortlisting tool, not an integration layer. Nothing in the material suggests the repository ships client code, SDKs or adapters you would import.

The audience is narrow by design. The README's Built For table names autonomous assistants, AI copilots, MCP toolchains, internal automation, research agents, workflow engines, tool-using LLM apps and production AI features. The Scope Guarantee states that anything outside Agents, AI Models and MCP Servers has been removed from the tracked structure. So the value is not breadth across all of software; it is a deliberately bounded slice of the agent stack. If you are choosing between three vector database vendors, this repository will not help you. If you need to find an orchestration layer or an MCP server for a specific system, that is the case it was built for.

How the Catalog Is Generated and Kept Current

The repository is JavaScript, and the README's Maintenance Notes describe the pipeline plainly. A GitHub Actions workflow syncs the Apify catalog daily and commits only when upstream data actually changes. The generation scripts live in a settings directory and are configured to rebuild only the three tracked categories. The README layout is part of the default presentation rather than a one-off pass.

That gives you a data flow worth understanding before you trust any single row. Upstream source (Apify catalog) feeds a scheduled workflow, which feeds generation scripts, which write the three category directories that the README links to. The repository is therefore a rendering of someone else's dataset, filtered through a scope rule. Two consequences follow. First, an entry's presence says nothing about whether the provider is still operating, still priced the same way, or still accepting new customers, because the only verification step described is a data-change check upstream. Second, the classification into Agents, AI Models or MCP Servers is the output of those scripts, and the README does not document the rules they apply. If you disagree with where something landed, the fix is in the settings directory, not in the list itself.

The Numbers in the README Do Not Agree

The repository description supplied with this listing says 2,036 production-ready APIs. The README's At A Glance table says 2,531 total APIs, split into 726 Agents, 1,385 AI Models and 420 MCP Servers. Those three category figures add up to 2,531, so the table is internally consistent, but it contradicts the description by roughly 500 entries. The material gives no explanation, no changelog and no release notes to reconcile the two. There are no retrieved releases at all.

That discrepancy matters more than it looks. A generated catalog is only as trustworthy as its last successful sync, and when two published counts disagree, you cannot tell which one reflects the current state of the tracked directories without opening them and counting. For a directory whose entire pitch is saving you hours, an unlabeled count mismatch is the kind of thing that costs you the first ten minutes. Treat both numbers as approximate. If an exact inventory matters to you, the category READMEs under agents-apis, ai-models-apis and mcp-servers-apis are the authoritative artifact, not the summary table.

Getting It Running: Clone, Then Read the Category Folders

There is nothing to install. The material shows no package manifest, no install command and no runtime entry point, so the practical setup is a clone followed by reading Markdown. The README's own navigation is the interface: the category links point at ./agents-apis/, ./ai-models-apis/ and ./mcp-servers-apis/, and each of those directories has its own README to scan.

The configuration surface is the settings directory, which the Maintenance Notes describe as holding the generation scripts configured to rebuild only the three tracked categories. If you fork the repository to add a category or change the scope, that is where the change belongs. The other moving part is the GitHub Actions workflow that performs the daily Apify sync; the README does not name the workflow file or the secrets it needs, so anyone forking for their own catalog should expect to inspect .github/workflows/ directly. Beyond that, the only runtime dependency visible in the material is the upstream Apify data source itself.

Affiliate Tracking in the Outbound Links

The Maintenance Notes state that API links keep the existing affiliate tracking from the upstream source data. This is disclosed, which is better than leaving it buried, but it changes how you should read the list. The ordering and inclusion of entries may reflect commercial arrangements inherited from the upstream catalog rather than an editorial ranking. The README does not claim otherwise, and it does not describe a review process, a scoring rubric or a verification step for individual providers.

There is also no licence declared for this repository in the supplied material. A collection of links and descriptions carries its own copyright questions, separate from the licences of the APIs it points to, and the absence of a licence file means the default all-rights-reserved position applies until the maintainer states otherwise. That is a factual observation about the repository state, not legal advice. If you plan to mirror the catalog inside a commercial product, resolve both questions first: what the repository's own terms are, and whether the affiliate parameters in the links are something you want to pass through to your users.

Where a Curated List Is the Wrong Tool

The failure mode is treating presence as endorsement. The README describes the entries as production-ready, but the only maintenance mechanism described is a daily data sync that commits when upstream changes. Nothing in the material describes uptime checks, deprecation tracking, pricing validation or a removal policy for dead providers. A directory that updates its rows does not necessarily remove the ones that stopped working.

A second limitation is resolution. Three categories are broad enough that Agents alone covers execution layers, orchestration, autonomous task handling and agent-style workflows, which are different problems with different evaluation criteria. The README's own Explore The Stack section lists bullet points rather than distinctions, so the directory helps you find candidates and then stops helping. If your question is which orchestration model fits a long-running workflow with human approval steps, a list of 726 names will not answer it. The README also gives no comparison data: no latency figures, no pricing tables, no capability matrices. Expect to do the evaluation yourself, one provider page at a time.

Compared With Building Your Own Shortlist

The obvious alternative is not a competing repository but the manual route: search, vendor documentation and your own notes. The difference is the scope rule. A general web search returns everything, including the categories this repository deliberately excludes, and you spend the filtering time yourself. This repository has already applied the filter and committed the result to three folders, which is the whole of its advantage. It is a pre-filtered starting set, refreshed on a schedule, with the trade-off that you inherit someone else's classification and someone else's commercial links.

A second alternative is going directly to the MCP ecosystem's own registries and the model providers' own catalogs. Those sources are authoritative for their own entries and will always be more current than a mirror, but they are separate destinations with separate formats, and none of them covers the Agents category alongside the other two. The reason to use this repository is aggregation across the three layers in one place. The reason not to use it is that aggregation is the only thing it does, and every fact it presents is second-hand.

Maintenance Cost and Who Should Adopt It

For a consumer of the list, maintenance cost is close to zero, because the daily workflow does the syncing and you only re-read when you need a new provider. For anyone who forks it, the cost sits in the settings directory scripts and the Actions workflow, both of which you own once you copy them, plus whatever the Apify source charges or requires. The README does not state the sync's cost, rate limits or failure behaviour, so a fork inherits an undocumented dependency.

Adopt it if you are at the shortlisting stage for agent, model or MCP integrations and want a bounded starting set you can scan in an afternoon. Do not adopt it if you need a maintained dependency, a compatibility guarantee or an audited vendor list; the material supports none of those. Your first three checks are concrete: count the entries in agents-apis, ai-models-apis and mcp-servers-apis to see which of the two published totals is real, look for a licence file at the repository root, and follow one link end to end to confirm the affiliate parameters and the current state of the provider behind it.

Editorial conclusion

Adopt this repository as a discovery index for agent, model and MCP APIs, and treat each entry as a lead you still have to verify against the provider's own documentation. Do not adopt it as a dependency, a quality rating or a compatibility guarantee, and do not assume the category counts are exact: the README's own At A Glance table totals 2,531 while the repository description states 2,036. Before relying on it, open the settings directory to see how the generation scripts classify an entry, check whether the repository declares a licence, and confirm whether the affiliate tracking in the outbound links is acceptable for your team.

Official sources

1. cporter202/agentic-ai-apis on GitHub
2. Issues
3. README