clirank

YC founder. Recovering finance professional. Building - API directory for AI agents.

[clirank @clirank]

Seeing agents get oddly specific about email APIs: not just "send email", but "Node.js, 5k/month, no credit card, simple setup." That is a better query shape. Agents should not pick the biggest provider first. They should ask what can pass the first headless integration test.

[clirank @clirank]

Discovery for agents probably will not look like a search page. It is more likely a callable decision step: give it the task, constraints, budget, and risk tolerance, then get back the best next API to try.

[clirank @clirank]

YC is right that agents need software built for them: APIs, MCPs, CLIs, machine-readable docs.

The next problem is discovery.

If every category gets rebuilt for agents, agents need a way to decide what to call, not just a bigger pile of tools.

[clirank @clirank]

The signals are pretty concrete: auth path, setup time, SDK quality, retry safety, rate limits, error messages, latency, pricing shape, and whether other agents have actually completed the integration.

[clirank @clirank]

The callability layer for agents is getting solved fast: APIs, MCPs, CLIs, OpenAPI specs, skill files.

The decision layer is still wide open. Agents need to know which valid option is right for the task, with evidence.

[clirank @clirank]

The useful test is simple: can an agent make a good choice before it reads five docs tabs and writes integration code? If the answer is no, the tool is callable but not really agent-ready.

[clirank @clirank]

One agent/API pattern I’m noticing: "pricing=free" is not enough. Agents need to know whether free means sandbox, trial credits, open data, or a tier that works in CI. For runtime API choice, pricing metadata has to be executable, not just a marketing label.

[clirank @clirank]

Small thing I keep seeing with coding agents: they guess routes like /api/config or /api/v1 when docs are unclear. Good agent-facing APIs need a boring starting point: /api/schema, OpenAPI, and examples tied to real tasks. Saves the agent from inventing the integration surface.

[clirank @clirank]

Today's tiny agent lesson: if an endpoint returns a dead 400, agents often just keep guessing nearby routes. A better 400 tells them the real API surface and gives copy/paste URLs. Error messages are part of agent UX now.

[clirank @clirank]

One small agent API design smell: if your docs have an OpenAPI file but the useful examples are only in prose, agents still have to guess. The next step is docs that expose tasks, auth shape, failure modes, and example calls in a format code can inspect.

[clirank @clirank]

Agent/API directories are starting to converge on the same idea: agents don’t need prettier lists, they need decision data they can call at runtime.

The useful unit is less “top 10 APIs” and more “for this task, which API can I use from a headless agent without surprises?”

[clirank @clirank]

Put CLIRank on HN today.

The basic bet: coding agents should not choose APIs from SEO pages built for humans. They need task-shaped discovery, decision data, and endpoints they can call at runtime.

Curious what agent/API people think.

https://t.co/0NbiK58zPA

[clirank @clirank]

Another agent API pattern I keep coming back to:

status is part of the API.

If an agent starts a job and cannot observe progress through webhooks, events, streaming, or a clear polling path, it is basically babysitting a black box.

That does not compose well.

[clirank @clirank]

Pattern keeps showing up: “agent-friendly API” is less about a nicer docs page and more about the shape of the calls.

Agents seem to prefer narrow, task-shaped endpoints with compact responses over one big endpoint that dumps context.

The API buyer is becoming a runtime.

[clirank @clirank]

Small thing I am seeing from CLIRank usage:

Agents search by task, not vendor.

"send email"
"headless CMS blog publishing"
"post to social media"
"stock market data API"

The next API discovery surface probably looks more like a runtime endpoint than a listicle.

[clirank @clirank]

Tiny things make APIs easier for agents:

- examples that run in a terminal
- errors an agent can branch on
- pricing and rate limits in a structured format
- auth that works without clicking around

None of this is flashy. It just makes the API usable.

[clirank @clirank]

APIs are getting judged by a new user now: coding agents.

Different bar than human DX.

The stuff that matters:
- docs an agent can read without a browser
- simple bearer token auth
- clear error codes
- examples that run headless
- pricing and limits that are structured

[clirank @clirank]

@jasonlk @joshfechter Strong framing @jasonlk. I built a complementary directory at https://t.co/fLW0uUh13h targeting agents - 416 APIs graded with a public JSON API and MCP server so agents can query at runtime, plus agents can post reviews back after integrating.

[clirank @clirank]

@hassanscalveta @jasonlk I built something similar and approached the described problem by treating the grading as cold start and then encouraging agent integration reports. The idea is that agents leave reviews and call us at runtime to decide what solutions to propose

[clirank @clirank]

Quick follow-up. Scored "agent-native fintech" properly. 10 new players added.

Circle USDC and Coinbase x402: 9.6/10. Meow: 9.2. Payman, Mercury, Orthogonal: 8+.

Brex and Ramp now sit in the bottom third of the category they used to own.

https://t.co/qKmTjuBLSZ

[clirank @clirank]

Harry Stebbings just posted that fintech moats are shifting from UI to API quality for AI agents.

He's right.

I spent 3 weeks scoring 387 APIs on exactly this. The data's brutal for the incumbents.

🧵

[clirank @clirank]

Full scorecard: https://t.co/fLW0uUh13h

The MCP server is at npx clirank-mcp-server if you want your agent to query it directly.

No pitch. Data's at https://t.co/fLW0uUh13h.
If you're building an API, reply with the name and I'll tell you its score.