Skip to main content
Modelence apps follow framework conventions that a general-purpose coding agent doesn’t know by default: Stores instead of raw MongoDB drivers, configSchema instead of process.env, and typed queries and mutations instead of fetch('/api/...') calls. Without guidance, an agent writes code that looks reasonable but works against the framework. This page shows how to give your local agent the same rules and documentation access that the Modelence App Builder uses in the cloud.

Claude Code plugin

The modelence plugin gives Claude Code:
  • Framework rules, always in context — database, configuration, authentication, and UI conventions.
  • Skills, loaded on demand — complete reference implementations of Modules, Stores, queries, mutations, and cron jobs, plus Expo Router rules for React Native apps.
  • Live documentation access through the Modelence docs MCP server, so the agent looks up APIs instead of writing them from memory.
  • Database access to your Modelence environments, after a one-time sign-in — see Inspecting your environment.
It works everywhere Claude Code runs: the terminal CLI, the desktop app, and the VS Code and JetBrains extensions.

Installing

npx modelence@latest setup installs the plugin for you. After connecting the project it offers to install the plugin through the Claude Code CLI, which works the same whether you use Claude Code in the terminal, in VS Code or JetBrains, or in the Claude desktop app. Say yes and you’re done. To install it yourself — or to reinstall it after it was removed — run these two commands in a terminal:
If a Claude Code session is already open, run /reload-plugins in it or start a new session. To confirm, run /plugin: modelence should appear under installed plugins.
The plugin requires Claude Code v2.1.195 or later, and the claude command on your PATH. The desktop app and the IDE extensions ship a private copy that isn’t on your PATH, so npx modelence setup can’t use it — if claude isn’t found, install the standalone CLI from code.claude.com first.

Sign in to Modelence

The plugin’s modelence MCP server — the one that reads your environments — needs a one-time sign-in with your Modelence account. In Claude Code, run /mcp, choose modelence, then Authenticate. Your browser opens — sign in and choose the organization your app belongs to. Claude Code stores the sign-in per server, so it covers every Modelence project on your machine. Until you sign in, Claude Code lists the server as needing authentication and its tools are unavailable; the rest of the plugin works regardless. See Inspecting your environment for what the sign-in grants.

Sharing it with your team

Setup also writes a .claude/settings.json to the project, which tells Claude Code where the plugin comes from. Commit it: teammates who open the project are prompted to install the plugin, and running npx modelence@latest setup on their clone installs it for them. This is what the file contains:
.claude/settings.json
The setting is project-scoped — it doesn’t affect your other projects.

The local workflow

A few conventions are worth knowing about, since they shape how sessions behave:
  • The agent runs the dev server. If nothing is already serving your app, it starts npm run dev in the background (port 3000 by default, restarting on file changes) and reads the output, so it catches runtime errors and not just type errors. You don’t need to run any commands yourself.
  • It won’t fight a server you started. If you’re already running npm run dev in your own terminal, the agent uses that one instead of starting a second. In that case the logs belong to your terminal and the agent can’t read them — paste any errors you want it to fix.
  • Type checking is part of finishing. The agent runs npx tsc --noEmit and fixes all errors before reporting work as done.
  • Your local files are the source of truth. Everything happens in your working copy, not in a cloud sandbox.
  • .modelence.env is left alone. It connects your project to its Modelence Cloud environment, including the MongoDB database — see Setup.
  • Some things need the dashboard. Config values, authentication providers, email providers, user roles, database connections, and file storage are set up in Modelence Cloud. The agent makes the code-side change and points you to the right dashboard page for the rest.

Docs access for any agent

The Modelence documentation is available as a hosted MCP server that requires no authentication. The Claude Code plugin registers it for you; add it manually for other tools.
It exposes search_modelence for searching the documentation, query_docs_filesystem_modelence for reading specific pages, and submit_feedback for reporting gaps in the docs. For agents without MCP support, the documentation is also published in plain text:

Other agents

Cursor, Codex, and most other agents read an AGENTS.md file from the project root. Apps generated by the App Builder already include one covering the framework conventions. For projects created with the CLI, add your own AGENTS.md describing the conventions your project relies on, and point the agent at llms.txt for the rest. Then register the docs MCP server through your tool’s own MCP configuration, using the JSON above.

Deploying any Node.js app

Modelence Cloud also hosts projects that don’t use the framework — an Express API, a Vite site, a Next.js app. How such a project is built and run is described in a modelence.config.json file at its root, and your agent is the right one to write it, since it knows the codebase. Give it the Deploy Setup page — it is written for agents and covers the file’s reference, worked examples, and how to verify the result locally — then run npx modelence@latest deploy:

Inspecting your environment

Your project is connected to a Modelence environment, and the agent can query its database directly — the same MongoDB your local app reads and writes. That makes it useful for diagnosis: confirming what a mutation actually stored, checking a migration’s result, or inspecting a document’s real shape. This needs the one-time sign-in described above. The sign-in grants access to all apps in the organization you chose — the agent reads MODELENCE_ENVIRONMENT_ID from .modelence.env to work against the environment this project is connected to, and can look at your other environments and apps when you ask it to, which is handy for comparing against production or borrowing context from a related app.
If you switch environments by re-running modelence setup, start a new agent session so it picks up the new environment id. There’s nothing to reconnect — the sign-in stays valid.

From other clients

The same server is available at https://cloud.modelence.com/mcp for tools that aren’t running inside your project — claude.ai on web or mobile, Cursor, Codex, or a Claude Code session outside a project directory. The browser sign-in is the same, and grants access to every app in your organization, including status and logs for App Builder sandboxes:
You don’t need this inside a Modelence project — the plugin already registers the server.

Next steps

Project Structure

How a Modelence project is laid out

Modules

The building block agents work with most