Skip to main content
Glama

Cerell MCP — Infrastructure Copilot & Developer Cashback

MCP Protocol Node.js License: MIT Website

Mission

The decision about which database, hosting, or auth service goes into a project no longer happens in a browser tab -- it happens inside an AI coding agent. Cerell is built for exactly that moment, and it solves two problems at once.

For developers: AI-assisted coding is expensive. Running agents through Cursor, Claude, or Windsurf burns real money in LLM tokens -- often $60-100/month for daily users. Cerell subsidizes that cost. When your agent suggests a partner service (a database, an email provider, a cache layer) and you accept it, the partner co-funds the tokens used in your session. You also earn cashback on your monthly cloud spend with that partner, credited back to your Cerell account. You build faster, you spend less.

For SaaS partners: Developer tools spend millions acquiring customers who sign up and never activate. Credits are handed out blind. Ads are clicked and forgotten. Cerell flips the model -- partners pay only when their product is actually wired into a developer's repository, after the developer explicitly accepted the suggestion. The conversion event is the install in the repo, not a pageview, not a form submission. That is a fundamentally different -- and cheaper -- unit of acquisition.

How it works in practice:

  1. Your AI agent asks to add a database (or auth, hosting, email, cache...).

  2. Cerell surfaces a curated partner match with live pricing and cashback rate.

  3. You review, see the alternatives, and accept or skip -- your choice, always.

  4. On accept, the upstream partner MCP provisions the resource and returns credentials directly to your environment.

  5. The partner is billed for the install. You earn cashback. The session cost is co-funded.

One action. Two problems solved.

Related MCP server: OpenAPI Doctor

Agenda

  • Close the gap between AI suggestion and real adoption. MCP registries offer discovery; Cerell adds distribution, attribution, and economics.

  • Make infrastructure decisions transparent. Every partner suggestion is labeled. Alternatives are always shown. Nothing is installed without the developer accepting.

  • Align incentives across the stack. Partners pay for activated integrations. Developers earn back a share of what they spend on cloud. The platform takes a margin only when value is delivered.

  • Stay editor-agnostic. Cursor, Claude Code, Windsurf, VS Code -- the same infra tool works everywhere, keeping the acquisition channel neutral and trustworthy for partners who do not want to depend on a single IDE vendor.

  • Grow the catalog without growing complexity. Partners are added as JSON files in data/partners/. The MCP tool surface stays constant -- one tool, every category.


Local stdio meta-tool gateway for Cursor, Claude Code, Windsurf, and VS Code.

One tool — infra(mode, request) — covers compare → provision → connect → operate/optimize/evolve → cashback, while keeping affiliate signup links in the path.


Quickstart

git clone https://github.com/Pawelec12/cerell-mcp.git
cd cerell-mcp
npm install
npm run build

Cursor (.cursor/mcp.json)

{
  "mcpServers": {
    "cerell": {
      "command": "node",
      "args": ["C:/path/to/cerell-mcp/dist/index.js"]
    }
  }
}

Claude Code

claude mcp add cerell -- node /ABSOLUTE/PATH/TO/cerell-mcp/dist/index.js

Tool: infra

Arg

Meaning

mode

compare | provision | connect | disconnect | status | optimize | evolve | cashback | portal

request

Free text / tokens. Flags: detail=1, limit=5 (use limit=0 for all), offset=N

Replies are compact JSON by default ({"ok":true,...}). Add detail=1 for full pricing, actions, docs, migration steps.

Examples

mode=compare   request="database postgres"
mode=compare   request="auth detail=1 limit=10"
mode=provision request="neon"
mode=connect   request="neon api_key=YOUR_KEY plan=Launch"
mode=provision request="neon create_database name=app region=aws-eu-central-1"
mode=status    request=""
mode=optimize  request=""
mode=evolve    request="from=neon to=supabase detail=1"
mode=cashback  request=""
mode=cashback  request="amount=25 method=revolut revtag=@you"
mode=portal    request=""

Flow after you pick a partner: signup (affiliate URL) → connect API key → provision action → cashback tracking.

Partner upstream MCPs (optional upstream in partner JSON) start lazily only when linked and an action needs them (max 3 live connections, LRU).


Partners

Configured in data/partners/*.json (Neon, Clerk, Upstash, Resend, Vercel, …). Catalog size does not grow the MCP tool list.


Publish on Smithery (local / MCPB)

Do not paste the GitHub URL into Smithery’s “MCP Server URL” field. Cerell is stdio-local.

npm run pack:mcpb
# → cerell.mcpb

npx @smithery/cli mcp publish ./cerell.mcpb -n apptent/cerell

That matches Smithery’s Local (MCPB Bundle) flow: users download the bundle and run it on their machine.

Dev

npm run build
npm test
npm run pack:mcpb
npm run inspector

License

MIT © Pawelec12 · cerell.eu

Available Tools

1 tool
infraC

Cerell infra gateway: compare/provision/connect partners, status/optimize/evolve stack, cashback/portal. Compact JSON; add detail=1 or limit=N in request for more.

NameRequiredDescriptionDefault
modeYescompare|provision|connect|disconnect|status|optimize|evolve|cashback|portal
requestYesFree text or tokens. Flags: detail=1 limit=5 offset=0. Ex: "database postgres", "neon create_database name=app", "neon api_key=sk", "amount=25 method=revolut revtag=@x"

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so the description carries the full burden. It does disclose output behavior (compact JSON by default, expandable via detail/limit), which is genuine value. However, it says nothing about the side effects, permissions, or reversibility of the mutating modes (provision, connect, disconnect, optimize, evolve) — a serious omission for a gateway that can change infrastructure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the mode inventory and ending with the response-shaping hint. It is dense but every clause is doing something, though the slash-separated verb chains read as shorthand rather than prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a 9-mode gateway funneling everything through one free-text field with no output schema, and the description never explains what shape the request should take per mode beyond brief schema examples. For a tool with this much behavioral surface, the description is under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents both mode (enum) and request (with example strings and flags). The description repeats the mode list and the detail/limit flags without adding per-mode request format guidance, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

Identifies the tool as a gateway and pairs each mode with a rough noun (partners, stack, cashback/portal), so an agent knows it is a multi-mode infra multiplexer. But the mode-to-task mapping is telegraphic slash-lists, and 'infra' plus verbs like 'evolve' don't tell the agent concretely what any single mode does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only actionable guidance is 'add detail=1 or limit=N in request for more', which governs response verbosity rather than tool/mode selection. Nothing explains when to pick compare versus status, or whether provision/connect require prerequisites; the agent must guess at mode choice. No siblings exist, so no alternative routing is needed, but mode selection guidance is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedinfra

TDQS

C2.7/5.0

Scored across 1 tool

Disambiguation4/5

With only one tool, there is no cross-tool overlap or misselection risk. However, the single tool bundles many distinct operations (partners, stack, cashback, portal), so agents must disambiguate through parameters rather than tool choice.

Naming Consistency3/5

There is only one tool name, so consistency cannot be meaningfully evaluated. The name 'infra' is broad and does not follow a verb_noun pattern, but it is readable.

Tool Count2/5

The apparent scope spans partner provisioning, stack optimization, evolution, cashback, and portal operations. Collapsing all of that into one mega-tool is too thin for the domain and forces excessive reliance on parameter conventions.

Completeness3/5

The description mentions several major capability areas, suggesting broad coverage, but the surface lacks granular operations and clear CRUD/lifecycle boundaries. Agents may work around this with the detail/limit parameters, but specific workflows are opaque.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    A template for building MCP servers with a built-in paywall gate that offers free local execution and premium server-side execution via Stripe and x402 payment lanes.
    1
    MIT
  • A
    license
    B
    quality
    A
    maintenance
    Official MCP server for accepting crypto payments through OrcaRail. It enables AI agents to create payment intents, manage subscriptions, handle product catalogs, and get exchange rates via natural language.
    26
    217 npm
    MIT