ACI.dev – Open Source Tool-Calling Platform
The open-source tool-calling platform that connects 600+ tools to any agentic IDE or custom AI agent via unified MCP or direct function calls.
- Source repo
- aipotheosis-labs/aci
- Stars
- ★ 4.9k
- Last updated
- 4mo ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 40/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformChatGPT · Codex · Claude Code (Partial support)
- Cost
- Free tier plus a paid hosted plan
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Developers using agentic IDEs like Cursor can add the unified MCP server to let AI manage Vercel and Supabase deployments via natural language.
- Not a fit if
- Teams wanting a zero-deploy, ready-to-use product
- Users who need fully offline operation without third-party OAuth
- Individuals unwilling to configure multi-tenant auth and permissions
- Source review
- 40/100 · Major gaps
What does this agent do, and when should you use it?
ACI.dev is an open-source tool-calling platform that provides AI agents with access to 600+ pre-built integrations (e.g., Google Calendar, Slack, Vercel, Supabase) through a secure, multi-tenant authentication system. The repository contains the backend server (backend/) and a developer portal (frontend/) that manage OAuth flows, permissions, and tool discovery. Tools are exposed either via a unified MCP server (aci-mcp) or a lightweight Python SDK (aci-python-sdk), making it compatible with any LLM framework. The platform pioneers 'VibeOps', enabling AI to automate deployment and configuration tasks. Released under Apache 2.0, it offers full transparency and self-hosting capability.
ACI.dev manages the lifecycle of tool integrations: authentication (OAuth2), authorization (permissions), and tool discovery. The backend server (backend/) handles API requests, validates permissions, and proxies calls to third-party services. The frontend portal (frontend/) allows administrators to configure integrations, manage users, and view tool-call logs. For AI agents, it provides two interfaces: a unified MCP server that can be added to agentic IDEs (like Cursor) and a Python SDK for direct function calls. It does not execute the agent itself; instead, it acts as a middleware layer between the agent and external tools.
- Developers using agentic IDEs like Cursor can add the unified MCP server to let AI manage Vercel and Supabase deployments via natural language.
- DevOps engineers adopt VibeOps to automate infrastructure provisioning and monitoring, reducing manual effort.
- Startups building internal AI assistants can let employees query company SaaS tools through a chat interface.
- Solo developers use the Python SDK to create custom automation for personal productivity apps.
- Sales teams deploy outbound AI agents to generate leads, send emails, and update CRM records automatically.
- Customer support teams integrate AI agents that resolve tickets from the helpdesk and perform actions like refunds.
How do you install or deploy this agent?
To install ACI.dev locally: 1. Clone the repo: git clone https://github.com/aipotheosis-labs/aci.git. 2. Follow the setup instructions in backend/README.md and frontend/README.md for backend and frontend components. This requires Python and Node.js environments. You'll need to configure OAuth credentials for the services you intend to integrate.
How do you use this agent?
Typical usage involves: 1. Set up the backend server and connect integrations (e.g., Vercel, Slack) via the frontend portal. 2. Define user permissions and generate API keys. 3. For agent integration, add the ACI MCP server to your agentic IDE (e.g., Cursor) using the MCP endpoint. Alternatively, use the Python SDK: pip install aci-sdk and call tools programmatically. The platform provides real-time tool-call logging for observability.
What are this agent's strengths and limitations?
- 600+ pre-built integrations, saving hours of API client development.
- Multi-tenant OAuth flows and secrets management streamline authentication.
- Dynamic tool discovery and natural-language permission boundaries improve agent reliability.
- Flexible access via MCP server or Python SDK, compatible with any LLM framework.
- Requires self-hosting the backend and frontend, adding deployment and maintenance overhead.
- Learning curve for configuring permissions and integrations.
- Dependent on third-party service APIs and OAuth providers; rate limits may apply.
- Documentation for local setup is split across component READMEs, not centralized.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| ACI.dev – Open Source Tool-Calling Platform This agent | 40 · Major gaps | Self-hosted serviceFreemium | ★ 4.9k | 4mo ago | Python | — |
| Corsair Integration Platform | 53 · Major gaps | Library / SDKFreemium | ★ 15k | today | TypeScript | — |
| Klavis AI - MCP Integration Platform | 12 · Major gaps | Hosted serviceFreemium | ★ 5.8k | 4mo ago | Python | — |
| Dexto | 51 · Major gaps | CLIFree + model costs | ★ 652 | 2d ago | TypeScript | Claude Code · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows permission controls (e.g., natural language permission boundaries), user confirmation (e.g., dry-run mode), data flow transparency (e.g., tool-use logging), sensitive data handling (e.g., secrets management), dependency security (e.g., CodeQL), external effects (e.g., tool calls), rollback (e.g., dry-run), source attribution (e.g., Apache-2.0). But mostly assertions, lacking implementation details, so each gets 1.
Self-consistency: README and code structure align, but not deeply verified. Dependency availability: CI config exists, but not verified if dependencies are obtainable. Failure messages: assertions in tests, but no user-friendly error messages. So each gets 1.
Audience and scenarios: README lists multiple use cases, gets 2. Capability boundaries: permission boundaries declared, but not detailed, gets 1. Trigger precision: dynamic tool discovery, but trigger conditions not explicit, gets 1. Environment fit: supports multiple IDEs and frameworks, but no specific config, gets 1.
Information architecture: README, SECURITY.md etc., clear structure, gets 2. Install notes: local dev guidance, but no detailed install steps, gets 1. Naming stability: version numbers, but no naming rules, gets 1. Examples and FAQ: examples exist, no FAQ, gets 1. Known limitations: not mentioned, gets 1. License: Apache-2.0, gets 2. Versioning and changelog: version numbers, no changelog, gets 1. Maintenance responsibility: SECURITY.md, but maintainers not explicit, gets 1.
Output usability: SDK and MCP exist, but output format not verified, gets 1. Marginal value: 600+ integrations, high value, gets 2. Cost-benefit: open source, but no cost analysis, gets 1.
Claim traceability: README has links, but no concrete evidence, gets 1. Cross-source corroboration: multiple repos, but not cross-verified, gets 1. Fact-inference separation: not clearly separated, gets 1.
- Static review, no code execution, all scores based on file contents, low confidence.
- Publisher identity unverified, do not infer reliability based on brand.
- Security claims (e.g., permission controls, secrets management) lack implementation details, need further code review.
- Dependency security only evidenced by CodeQL config, actual dependency vulnerabilities not verified.
- Rollback mechanism only evidenced by dry-run, actual rollback capability not verified.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v0.0.1-beta.3 Pre-release
Release notes excerpt
Remove TrustedHostMiddleware for aws ALB health check to work.View on GitHub ↗