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 the environment your project is connected to, authenticated automatically — see Inspecting your environment.
It works everywhere Claude Code runs: the terminal CLI, the desktop app, and the VS Code and JetBrains extensions.

Nothing to install

New Modelence projects come with the plugin already wired up. Open the project in Claude Code, approve the one-time confirmation prompt, and the plugin loads in every session from then on. You can confirm it’s active by running /plugin and looking for modelence in the list of installed plugins.

Adding it to an existing project

Projects created before the plugin existed — or ones where the configuration was removed — need it added once. Commit a .claude/settings.json file at the repository root:
.claude/settings.json
This is the same file new projects ship with. Committing it means everyone on the team gets the plugin after a single confirmation prompt, and the setting stays project-scoped — it doesn’t affect your other projects. If you’d rather install it only for yourself, without committing anything, run these in a Claude Code session instead:
The plugin requires a recent Claude Code (v2.1.195 or later). If /plugin isn’t recognized, or the plugin’s modelence MCP server fails to connect, update by running claude update and start a new session.

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.

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. The plugin sets this up for you. It authenticates with the service token already in .modelence.env, so there’s no sign-in step and nothing to configure.
If you switch environments by re-running modelence setup, reconnect the modelence server from /mcp (or start a new session). The connection reads .modelence.env once, when it connects.

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. Signing in through the browser 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 connects you, scoped to that project’s own environment.

Next steps

Project Structure

How a Modelence project is laid out

Modules

The building block agents work with most