This MCP server connects AI agents to ExisJS projects, letting them read local ExisJS documentation and scaffold idiomatic ExisJS code.
exis_list_local_docs: list available ExisJS documentation files.
exis_read_local_docs: read a specific doc file by relative path.
exis_generate_route: scaffold a route controller using functional or OOP paradigm.
exis_generate_gateway: scaffold a gateway.ts for applying middleware/CORS/DI to a folder route.
exis_generate_plugin: scaffold a plugin using definePlugin.
exis_generate_config: scaffold an exis.config.ts file.
The README also describes scaffolding boundaries and validation schemas, but those are not exposed in the provided server schema.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@exisjs-mcp Generate an idiomatic ExisJS gateway for user authentication"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
@exisjs/mcp is a Model Context Protocol (MCP) server that connects AI coding agents like Claude and Cursor directly to your ExisJS projects.
It provides your AI assistant with the ability to dynamically read the local ExisJS framework documentation and flawlessly scaffold idiomatic ExisJS boilerplate code (routes, plugins, boundaries, configurations).
Related MCP server: contextium-mcp-server
Install for all your coding agents with add-mcp:
npx add-mcp @exisjs/mcp@latestAdd -y to skip the prompt and install to all detected agents. Add -g to install globally across all projects.
Or add the config to your MCP client manually:
{
"mcpServers": {
"exisjs-mcp": {
"command": "npx",
"args": ["-y", "@exisjs/mcp@latest"]
}
}
}@exisjs/mcp@latest keeps your client on the latest version.
claude mcp add exisjs-mcp npx @exisjs/mcp@latestOr edit your MCP settings file with the config above.
Go to Cursor Settings → MCP → New MCP Server and use the config above.
Add to .gemini/antigravity/mcp_config.json:
{
"mcpServers": {
"exisjs-mcp": {
"command": "npx",
"args": ["-y", "@exisjs/mcp@latest"]
}
}
}code --add-mcp '{"name":"exisjs-mcp","command":"npx","args":["-y","@exisjs/mcp@latest"]}'Tool | What it does |
| Recursively scans and lists all ExisJS Markdown documentation from |
| Reads a specific documentation page so the AI can understand ExisJS best practices. |
| Scaffolds an idiomatic ExisJS route controller module (functional or OOP style). |
| Scaffolds an ExisJS boundary ( |
| Scaffolds an ExisJS validation schema using the native |
| Scaffolds a hybrid ExisJS plugin module. |
| Scaffolds the |
ExisJS ships its official documentation right inside its npm package. exis_list_local_docs searches node_modules/exisjs/dist/docs/ (or your repository docs folder) to list the topics, and exis_read_local_docs passes that exact file back to the AI. This prevents AI hallucination and ensures it writes perfect framework code based on your exact installed version.
The generation tools (route, boundary, schema, plugin, config) ensure that when you ask your AI to build something, it strictly adheres to ExisJS's controller / defineBoundary / tex design paradigms instead of guessing Express or NestJS syntaxes.
git clone https://github.com/v25group/exisjs-mcp.git
cd exisjs-mcp
npm install
npm run buildPoint your MCP client at the local build:
{
"mcpServers": {
"exisjs-mcp": {
"command": "node",
"args": ["/absolute/path/to/exisjs-mcp/dist/index.js"]
}
}
}MIT
Scaffolds an idiomatic ExisJS Boundary (boundary.ts) for applying middleware/CORS/DI to a folder route.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | No | The path to the boundary file to create (e.g., src/http/admin/boundary.ts). | |
| paradigm | No | The ExisJS routing paradigm to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full disclosure burden. It only says “scaffolds,” but does not disclose whether existing files are overwritten, whether a route must already exist, whether side effects occur, or what is returned. For a file-generating tool, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One focused sentence, front-loaded with the action and object, and no redundant repetition of the tool name or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple generator with fully documented parameters, the description is mostly sufficientUTE. It lacks information about defaults, behavior when the target file exists, and whether any prerequisites are required, leaving some ambiguity for a safe call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a little context around the purpose of the generated file, but it does not expand on the meaning of filePath or paradigm beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific action ('Scaffolds'), the exact artifact ('boundary.ts'), and its purpose ('applying middleware/CORS/DI to a folder route'). This cleanly distinguishes it from the other generate-* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool: creating a boundary.ts for middleware/CORS/DI on a folder route. It does not mention alternatives or exclusions, but the use-case is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffolds a standard exis.config.ts file in the root of the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says it 'scaffolds a standard exis.config.ts file', which implies a write operation, but it does not mention whether it overwrites existing files, what permissions are needed, or any side effects. This is a significant gap in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and the target, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero parameters, but the description lacks details about behavior such as overwrite behavior, idempotency, or what the 'standard' config file contains. Given there is no output schema, the description should have disclosed more to be fully complete, but it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the input schema is empty. The description adds the context that the generated file is 'standard', which implies a fixed template. Since there are no parameters to describe, the baseline of 4 is appropriate and the description adds slight semantics beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Scaffolds' and names the exact resource 'exis.config.ts' plus its location 'in the root of the project'. This clearly distinguishes it from sibling generation tools like exis_generate_route or exis_generate_plugin, which target different file types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no guidance on when to use it versus the sibling generate tools. There is no mention of alternatives or exclusions, leaving the agent without explicit context for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffolds an idiomatic ExisJS Plugin using definePlugin.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of the plugin (e.g., MyPlugin). | |
| filePath | No | The path to the plugin file to create (e.g., src/plugins/my.plugin.ts). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. 'Scaffolds' implies file creation, but the description does not disclose side effects, overwrite behavior, prerequisites, or what definePlugin actually does. The schema's filePath mention of 'create' is the only implicit hint, which is insufficient for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and target without any wasted words. It is appropriately minimal and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and no output schema, the description covers the essential purpose but lacks behavioral caveats and does not differentiate from sibling generate_* tools. The absence of annotations and usage guidance creates notable clarity gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (name and filePath) are fully described in the schema with examples, so the description adds no further semantic value. This meets the baseline for 100% schema coverage; the description is not required to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scaffolds') and the specific resource ('ExisJS Plugin') while adding implementation detail ('using definePlugin'). It inherently distinguishes the tool from sibling generate_* tools by naming the plugin resource, though it does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the sibling tools (e.g., generate_route, generate_gateway). There are no preconditions, alternatives, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffolds an idiomatic ExisJS route file.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | No | The absolute or relative path to the route file to create (e.g., src/http/users/route.ts). | |
| paradigm | No | The ExisJS routing paradigm to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'scaffolds' but does not disclose side effects such as file creation, overwriting behavior, or whether existing files are affected. This lack of behavioral detail is significant for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant content. Every word contributes to the core purpose, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is too minimal to be complete. It fails to explain the file-system impact of scaffolding, any prerequisites, or when to choose this tool over the sibling generation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description coverage is 100% with clear descriptions for both 'filePath' and 'paradigm', so the description itself need not add more. It does not, however, add any extra semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'scaffolds' and a specific resource 'idiomatic ExisJS route file', clearly distinguishing it from sibling tools that generate gateways, plugins, or configs. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling generators (e.g., exis_generate_gateway, exis_generate_plugin). The description simply states the action without contextual or alternative selections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffolds an idiomatic ExisJS schema file (schema.ts) using the native tex validator and ResolveSchema.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| filePath | No | The path to the schema file to create (e.g., src/http/users/schema.ts). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'scaffolds' without detailing side effects such as file creation location, overwrite behavior, error handling, or the resulting structure. This is insufficient for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the primary action ('Scaffolds') and mentions the output file. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter generator tool with no output schema, the description is too sparse. It lacks usage context, side effects, and does not explain what a successful scaffold produces. An agent cannot fully understand the tool's behavior or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only filePath has a description). The description adds no explanation for the 'name' parameter, leaving its role ambiguous. It does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scaffolds an ExisJS schema file (schema.ts) and mentions the specific validators used. It distinguishes from siblings by specifying the resource type (schema), so an agent can tell it apart from generate_boundary, generate_config, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling generate_* tools. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available ExisJS documentation files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'lists' without any extra context such as return format, ordering, filtering, or confirmations that this is non-destructive. For a list operation, more transparency about what 'available' means or what is returned would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and easily parsed by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description is adequate to invoke it correctly. It could optionally mention what the result contains (e.g., filenames or paths), but for a basic list operation this is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides full coverage by having no properties. The baseline for 0 params is 4; the description adds no parameter details because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'lists' with a clear resource 'available ExisJS documentation files'. It distinguishes from sibling tools like exis_read_local_docs (reading) and exis_generate_* (generating) by focusing on enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and sibling context: use this to discover available docs, then read them with exis_read_local_docs. However, the description provides no explicit instruction on when to choose this over alternatives, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads an ExisJS documentation file by its relative path.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | No | The relative path to the documentation file (e.g., content/routing.mdx). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the basic read action but does not disclose return format, error behavior, or how the relative path is resolved. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that directly states the tool's function with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one documented parameter and no output schema, the description is nearly complete. It misses only an explicit statement about the return value (e.g., that it returns the file contents), but this is strongly implied by the verb 'Reads'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents filePath with a description and example, so the description adds no additional parameter meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Reads') and resource ('ExisJS documentation file by its relative path'), clearly distinguishing it from sibling tools that list or generate documentation files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or references to alternatives, but the purpose is narrow and the intended use case (reading a specific doc by path) is implied. It does not explicitly contrast with exis_list_local_docs or the generate tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1exis_generate_boundaryexis_generate_gatewayexis_generate_schemav0.1.0exis_generate_configexis_generate_gatewayexis_generate_pluginexis_generate_routeexis_list_local_docsexis_read_local_docsScored across 7 tools
Each tool targets a distinct file type or action: boundary, schema, config, plugin, route, and docs listing/reading. No overlapping purposes, so an agent can easily select the correct tool.
All tools follow the consistent pattern exis_<verb>_<object>, with verbs generate, list, and read. This predictable naming makes the tool surface easy to navigate.
Seven tools is well within the ideal range and matches the server's scope of scaffolding ExisJS project files and providing documentation. Each tool earns its place without redundancy.
The set covers the main generation needs for ExisJS (boundary, schema, config, plugin, route) and provides documentation access. No obvious missing operations for the stated purpose.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
An MCP server that gives your AI access to the source code and docs of all public github repos
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
