monid-ai/monid: a declarative connector layer for routing agents across paid APIs

A connector is a file, not a client library

The central claim of the project is that provider integrations do not need per-provider code. A provider declares identity, auth and how usage is counted; an endpoint declares the request and the input schema. That is the entire contract, and the README is explicit that there is no client, no adaptor and no per-provider execution path:

// connectors/tinyfish/endpoints/search/endpoint.ts
    endpoint: "/search",
    request: {
        method: "GET",
        path: "/",
        baseUrl: "https://api.search.tinyfish.ai",
    },
    timeouts: { requestMs: 15_000, runMs: 20_000 },

The consequence is that a connector is something a coding agent can write from vendor API documentation without learning a framework, which is the argument the README makes for the design. The directory layout enforces that reading. Each provider has a `provider.ts`, a shared `schema/` folder for zod fragments used by two or more endpoints, and one folder per endpoint containing the definition, its input schema, a test file and trimmed JSON fixtures:

connectors/<name>/
├── provider.ts                    # defineProvider: name, meta, auth, defaults
├── schema/                        # provider-shared zod: fragments used by 2+ endpoints
└── endpoints/<endpoint>/

The reference implementation named in the README is `connectors/exa/`, which is a useful convention for a repository whose point is that every connector should look like every other one.

Billing settles on the raw envelope, not on your results

The metering design is the part of this project worth stealing regardless of whether you use it. Every connector declares its own usage model: a flat charge per call, a charge per returned result, or a rate per unit such as a thousand characters or a second of video. The engine settles that model on the raw response envelope, before any output mapping happens, so what gets billed is what actually came back over the wire.

That choice has a specific consequence the README spells out, and it is generous to the caller rather than to the platform. A vendor error, a company record that did not match, a person who could not be resolved: each of those completes as data and settles at zero. Most aggregator APIs bill per call regardless of whether the call produced anything useful, which is exactly the failure mode that makes agents expensive to point at enrichment vendors. A company lookup that returns nothing should not cost the same as one that returns a match.

There is a second billing dimension worth noting. The README says the first two verbs are free and bills only the third, and the provider example marks its usage model as free outright, with `usage: { model: { kind: UsageModelKind.FREE } }` for a search provider the summary describes as zero-cost. So the free tier is a property a provider declares about itself, not a platform subsidy. Whether a provider keeps that declaration honest is a matter of trust the design does not try to solve.

Endpoint selection at call time, with latency and health in the answer

The second structural idea is that the API is chosen when the call happens, not when the code was written. The `discover` verb ranks the entire catalog by what the job is, across every provider at once, and returns each candidate with its price, its live health, and observed p50 and p95 latency. It also returns hints naming a cheaper or better-fitting endpoint, and the README's advice to connector authors is to put that guidance in the endpoint's own description.

That last point is the sharpest instruction in the README: write `meta.description` as though it is the product, because to an agent it is. The description is the text `discover` ranks and `inspect` returns. The example endpoint does exactly what the guidance asks, ending its description by naming its own successor and telling the caller to pipe result URLs into the fetch endpoint when full text is needed. A human reading API docs skips that kind of sentence; an agent reading a ranked candidate list has nothing else to go on.

Local exploration is a first-class part of the workflow rather than an afterthought. The catalog tasks are the tool for looking at the compiled output without calling anything:

deno task catalog providers                  # what exists
deno task catalog endpoints --provider exa   # under one provider
deno task catalog endpoints --category web-search
deno task catalog inspect 'exa#search'       # one endpoint's full contract

Category-first lookup matters more than it looks. An agent that wants web search does not know or care that three vendors sell it, and the categories `web-search`, `news-search` are how that intent gets expressed in a way the ranking can use.

Deno, replay fixtures, and tests that need no vendor keys

The runtime is Deno 2.x, not Node. The tree carries `deno.json` and `deno.lock` at the root and there is no `package.json`, no `tsconfig.json` and no node_modules convention anywhere. That is a real constraint for a connector layer whose entire pitch is that an agent can write a connector easily, since the ecosystem of agent tooling is overwhelmingly Node-based. It is also a fair trade for a project that runs zero network in CI:

git clone https://github.com/monid-ai/monid.git
cd monid

Every endpoint carries an `endpoint.test.ts` and a `fixtures/` folder of recorded, trimmed responses. Tests replay from those fixtures, so CI needs no vendor keys at all, and the check-and-test pass is advertised as types plus 188 replay tests with zero network. Live tests are reserved for gated cases, and a recorded fixture can be refreshed with a dedicated task.

That fixture discipline is the strongest signal about how this project is run, more than any feature in the README. It means a connector author is forced to capture a real response and commit it, and it means the test suite cannot quietly rot into asserting against a mock that no vendor shape ever had. The README's contributor path is short and concrete: read the exa connector and the authoring guide in `DEVELOPMENT.md`, write the two files, record a fixture, keep it trimmed, get check and test green with no network, open a pull request.

Running a live endpoint locally is a separate path, and it reads credentials from the environment under a provider-prefixed variable:

export TINYFISH_CREDENTIALS_API_KEY=...
deno task engine:run 'tinyfish#search' \
  --query-params '{"query":"solid-state battery suppliers","domain_type":"news"}'

Two agent instruction conventions in one repository

The tree contains `.coderabbit.yaml`, `.opencode/`, `openspec/` and `AGENT.md`, which tells you the repository is developed primarily by and for coding agents. That raises a small inconsistency worth flagging. The README instructs agents to fetch `https://monid.ai/SKILL.md` and save it to their skill directory, which follows the newer skill-file convention. The repository itself ships `AGENT.md`, singular, rather than the `AGENTS.md` filename that several tools look for.

So a project whose main selling point is giving agents a good way to discover 2,000-plus tools keeps its own agent instructions under a filename that some of those agents will not read, while pointing at a hosted file they will. Both conventions are still in flux across the ecosystem, so this is a growing-pain observation rather than a defect. It does mean that if you want the project to follow local overrides for agent tooling, check which filename your own client actually loads before assuming none of it is being read.

The `openspec/` directory points at spec-driven development, and the open issue count is 40 against 2,172 stars, which is high enough to be worth a look if you plan to depend on the catalog. The repository is not archived and the last push was on 2026-09-30.

What the repository does not contain

The README advertises one base URL, one key, and 2,000-plus tools across 72-plus providers. Nothing in this tree lets you check that number. The catalog is compiled rather than enumerated, the platform that settles usage lives on the hosted side, and the three releases in the repository metadata are named `catalog-v0.0.2`, `catalog-v0.0.3` and `catalog-v0.0.4` with the release body `catalog publish` on each, which is the note format of an automated publish job rather than a changelog.

The release naming is itself informative. There is no versioned release of the connector layer as a library, because it is not distributed as one. The tags track the state of the published catalog, and the most recent one, `catalog-v0.0.4`, was published on 2026-09-30, the same day as the last push. If you wanted to know how often vendor definitions change underneath you, those three tags over roughly two weeks are the only signal available, and they suggest the catalog is republished frequently.

The repository topics are also thin, just `ai-agents` and `developer-tools`, which is odd for something whose description leads with a community invite. Combined with the Discord link in the repository description rather than in the README, it points to a project where the git metadata is less curated than the connector definitions. That is a reasonable trade. The README, DEVELOPMENT.md and the reference connector are where the real information is, and they are unusually well written.

Editorial conclusion

monid's repository is worth reading for one idea in particular: settle billing on the raw response envelope, before any output mapping, so a vendor error or an unmatched record costs the caller nothing. That decision is defensible and unusual. What the repository does not contain is the scale it advertises, because the connector definitions are the layer under a hosted service and the service itself, the routing engine behaviour and the 2,000-plus endpoint count all live off GitHub. If you want to add an API to the catalog, the path is clear and the test discipline is real, with 188 replay tests that need no vendor keys. If you want to understand what `discover` returns or how the free verbs are accounted, docs.monid.ai and the hosted endpoint are where you will find out.

Frequently asked questions

Official sources

1. License: MIT
2. monid-ai/monid on GitHub
3. Project website
4. README
5. Releases