# API layer & connectors: comparison > Platforms that give agents and apps authenticated access to hundreds of third-party APIs. Canonical page: https://llms-technical-reviews.com/compare/connectors/ ## How is third-party authentication implemented? [ACI](/p/aci/) has a full credential system. Each end user's account is a `LinkedAccount` keyed by your own `linked_account_owner_id`. The secret fields (API key, access and refresh tokens, client secret) are encrypted field by field with AWS KMS envelope encryption. Platform API keys are found by an HMAC-SHA256 lookup. OAuth2 runs through Authlib with PKCE. An expired token is refreshed when a function runs, and a rotated refresh token is saved. One weak point: the PKCE verifier travels in a signed but unencrypted `state` JWT that has no expiry. [Klavis](/p/klavis/) has no credential store in the open code. Each MCP server reads a token from the `AUTH_DATA` env var or from a base64 `x-auth-data` header. The `-oauth` Docker images get that token from the hosted `api.klavis.ai`, so they need a Klavis API key. The Strata router can do standard MCP OAuth by itself, with a localhost:3030 callback, but it keeps the tokens as plaintext JSON in `.tokens/` and serves a single user. Choose ACI if you need many end users with stored, refreshed credentials on your own infrastructure. Choose Klavis if one developer or one workload passes in tokens it already has, or if you are happy to let the Klavis cloud run OAuth. More projects in this category are being researched. Per-project answers: https://llms-technical-reviews.com/connectors/q/auth/index.md ## How is an integration / connector defined? The two projects define an integration in opposite ways. In [ACI](/p/aci/), an integration is data. Each of the 98 apps is an `app.json` (metadata and security schemes, with secrets as Jinja placeholders) plus a `functions.json`. That file describes each REST endpoint (method, path, server URL) and its parameters as JSON Schema split into header, path, query and body, with a `visible` list that decides what the LLM sees. The CLI commands `upsert-app` and `upsert-functions` validate the definitions, embed them and load them into Postgres. Of the 987 functions, 971 are pure config. The other 16 are routed by name to Python connector classes. Every definition is written by hand; there is no OpenAPI import. In [Klavis](/p/klavis/), an integration is code. Each of the roughly 100 `mcp_servers/` directories is a separate MCP server in Python, TypeScript or Go, with its own Dockerfile. Tools are declared in `list_tools()` and dispatched by hand in `call_tool()`. There is no shared manifest. Fern generates SDKs, but only for the hosted API. Choose ACI's model when you want to add many REST endpoints cheaply and the same way each time. Choose Klavis when you want a normal MCP server per service, which you can run alone and which may contain any custom logic. More projects in this category are being researched. Per-project answers: https://llms-technical-reviews.com/connectors/q/definition/index.md ## How are integrations exposed to LLM agents? Both projects solve the problem of too many tools with discovery meta-tools, but they search in different ways. [ACI](/p/aci/) exposes a REST API. `GET /v1/functions/search` embeds a natural-language intent with OpenAI, ranks the functions by pgvector cosine distance, and returns OpenAI, OpenAI-Responses, Anthropic or basic schemas, optionally limited to the agent's allowed apps. `ACI_SEARCH_FUNCTIONS`, `ACI_GET_FUNCTION_DEFINITION` and `ACI_EXECUTE_FUNCTION` let an agent run search, inspect and execute by itself. The MCP server and the Python SDK are in separate repos. [Klavis](/p/klavis/) is MCP-native. Its Strata router connects to any number of MCP servers but shows the agent only five tools: `discover_server_actions`, `get_action_details`, `execute_action`, `search_documentation` and `handle_auth_failure`. Search is local BM25 over tool names and descriptions, so it needs no embeddings API. `strata tool add` adds the router to Cursor, VS Code, Claude Code or Gemini CLI. Choose ACI if your agent calls functions directly and you want semantic search over a central catalog. Choose Klavis if your client speaks MCP and you want one endpoint in front of servers you already run. More projects in this category are being researched. Per-project answers: https://llms-technical-reviews.com/connectors/q/agent-exposure/index.md ## How is a tool call executed? [ACI](/p/aci/) runs every call through a central proxy. `execute_function` checks the app configuration, the agent's allowed apps, the enabled functions and the linked account. It resolves and refreshes credentials and can ask an LLM to check the call against custom instructions. Then the matching executor runs. A REST executor validates the input against the visible schema, adds the hidden defaults and auth, and sends one `httpx` request (10 s connect, 30 s read). Errors become `success: false` results. There is a per-IP in-memory rate limit and per-project quotas, but no retries, no pagination helpers and no sandbox. The HTTP call also blocks inside an async route. In [Klavis](/p/klavis/), the Strata router is a pass-through. `execute_action` merges the JSON-string path, query and body params and calls `session.call_tool` on the downstream MCP server. If the server reports an error, the router returns it as text. The router has no retries, rate limits or call timeout; isolation comes only from running each server as its own process or container. Each server handles pagination and error mapping in its own way. Choose ACI if you need central policy, auditing and uniform error results. Choose Klavis if you want a thin router and accept that behaviour differs from server to server. More projects in this category are being researched. Per-project answers: https://llms-technical-reviews.com/connectors/q/execution/index.md ## How are data sync, webhooks and triggers implemented? Neither published project has data sync or event triggers. For [ACI](/p/aci/), the answer is not_applicable. Every call is request-driven. The only webhook routes are platform-internal: PropelAuth user sign-up (checked with Svix) and Stripe billing. There is no scheduler, no incremental cursor and no ingestion of third-party events. For [Klavis](/p/klavis/), the research found too little evidence. The MCP servers are stateless request/response services. The only inbound event handling is the Slack bot's `/slack/events` route in `mcp-clients`, and it routes chat messages, not data. There are no scheduled syncs and no generic webhook-to-agent triggers. The hosted Klavis product may have more, but the repo does not show it. If your agent must react to events (a new email, a GitHub push) or keep a local copy of third-party data, neither project covers that. You need a separate sync or trigger layer in front of either one. More projects in this category are being researched. Per-project answers: https://llms-technical-reviews.com/connectors/q/sync-triggers/index.md ## How is it self-hosted and what is open vs proprietary? Both projects use the Apache-2.0 licence, but they depend on hosted services in different places. [ACI](/p/aci/) puts the whole platform in the repo: the FastAPI server, 98 integrations, the CLI, Alembic migrations and the Next.js portal. Its Docker Compose stack runs pgvector Postgres, LocalStack KMS, a PropelAuth mock and the server. A production deployment needs a real KMS key, PropelAuth for portal login, an OpenAI key (search, app upsert and custom-instruction checks all use it), and optionally Stripe, Logfire and Sentry. The MCP server and the SDK are separate repos, but they only call this API. [Klavis](/p/klavis/) has no central service to host. You run individual MCP server images, plus the Strata router (`pip install strata-mcp`) if you want it. Neither needs a database. Two features depend on Klavis's cloud: the `-oauth` images get tokens from `api.klavis.ai`, and the bots' production database module is missing from the repo. Without the cloud, you supply tokens yourself or use Strata's local OAuth. Choose ACI if you want to host a whole multi-tenant platform yourself. Choose Klavis if you want to self-host a few integrations without running a platform. More projects in this category are being researched. Per-project answers: https://llms-technical-reviews.com/connectors/q/self-host/index.md ## Projects - [Klavis-AI/klavis](https://llms-technical-reviews.com/p/klavis/index.md) — Apache-2.0 monorepo of ~100 self-hostable MCP servers plus Strata, an MCP router that hides them behind five meta-tools. - [aipotheosis-labs/aci](https://llms-technical-reviews.com/p/aci/index.md) — Self-hostable FastAPI + pgvector tool-calling backend: 98 JSON-defined apps, multi-tenant OAuth/API-key accounts, KMS-encrypted secrets.