Click on "Install 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., "@warp-drive-mcp search for how to use RequestManager"
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.
MCP server that exposes WarpDrive and EmberData docs as tools. Use it from Cursor, Claude Desktop, or any MCP client so the assistant can look up real docs instead of guessing.
Docs are pulled from canary.warp-drive.io and cached for 30 minutes. All tools are read-only (no side effects).
Requirements: Node.js 18 or later.
Add the server to your MCP config. No global install if you use npx.
Using npx (recommended):
{
"mcpServers": {
"warp-drive": {
"command": "npx",
"args": ["-y", "warp-drive-mcp"]
}
}
}Using a local build: use the full path to node and to dist/index.js so the client can find them (e.g. if you use Volta/nvm and launch the app from the Dock):
{
"mcpServers": {
"warp-drive": {
"command": "/path/to/node",
"args": ["/path/to/warp-drive-mcp/dist/index.js"]
}
}
}Config file locations:
Client | Config path |
Cursor |
|
Claude Desktop |
|
Restart the client after changing config. A green dot next to the server name means it’s running.
spawn node ENOENT or spawn npx ENOENT — The client can’t find node/npx in its PATH (common when the app was launched from the Dock/Spotlight). Use the full path in command, e.g. /Users/you/.volta/bin/node or /Users/you/.volta/bin/npx. Run which node or which npx in a terminal to get your path, then put it in the config.
Red dot / server not starting — Check the client’s MCP or developer logs for the exact error. Confirm the config key is mcpServers (Cursor, Claude Desktop) and the path to dist/index.js is absolute when using a local build.
Wrong or old docs — Docs are cached for 30 minutes. Restart the server (or the client) to force a fresh fetch.
Related MCP server: Documentation Retrieval MCP Server (DOCRET)
The server exposes 5 tools. The client (Cursor, Claude, etc.) decides when to call them based on your questions.
Search the docs by keyword. Use this for API names, concepts, or “how do I use X” questions.
Parameter | Type | Default | Description |
| string | — | What to search for (e.g. |
| number | 5 | How many doc sections to return (1–10) |
When to use: Before writing WarpDrive code, or when the user asks about a specific API or concept.
Get the full doc content for one package (e.g. @warp-drive/core, @warp-drive/react).
Parameter | Type | Description |
| string | Package name, e.g. |
When to use: When you need the full picture for a single package, not just a search snippet.
Returns the high-level overview of all WarpDrive packages (what each one is for).
No parameters.
When to use: “What is WarpDrive?”, “Which package do I use for X?”, or when starting a new project and you’re not sure of the package layout.
Search guides and cookbook-style docs (tutorials, “how to” content).
Parameter | Type | Description |
| string | Topic to look up (e.g. |
When to use: “How do I set up…”, “How do I write a…”, or step-by-step / migration questions.
Check whether an API or package is deprecated and what to use instead.
Parameter | Type | Description |
| string | API, package, or class name (e.g. |
When to use: User sees deprecation warnings, or you’re touching legacy @ember-data/* code and want the modern replacement.
In a project that uses WarpDrive, you can add a Cursor rule so the assistant tends to call these tools when relevant. Create .cursor/rules (or use your existing rules file) and add something like:
When working with WarpDrive (@warp-drive/* or @ember-data/*):
- Call search_warp_drive_docs before writing WarpDrive code.
- Use get_warp_drive_guide for “how to” and setup questions.
- Use check_warp_drive_deprecations for legacy @ember-data/* APIs.
- Don’t guess APIs; look them up first.git clone https://github.com/MehulKChaudhari/warp-drive-mcp
cd warp-drive-mcp
npm install # or pnpm install
npm run build # if you used pnpm: pnpm run buildRun built server: node dist/index.js or pnpm start
Dev mode (watch): npm run dev or pnpm dev
To point your MCP config at this repo, set command to your node binary and args to the absolute path of warp-drive-mcp/dist/index.js.
The server is a stdio MCP process. The client starts it and talks over stdin/stdout with JSON-RPC. When the assistant needs docs, it calls one of the tools; the server fetches https://canary.warp-drive.io/llms-full.txt (or uses the in-memory cache if still fresh), then searches or filters that content and returns the relevant bits. All of that lives in src/index.ts.
WarpDrive — the library this server documents
Model Context Protocol — protocol overview and spec
Bug reports and PRs are welcome. Open issues and PRs in the project repository (see package.json for the URL).
MIT
Check if a WarpDrive or EmberData API is deprecated and find its replacement.
Use this when:
Working with legacy @ember-data/* code and need to know the modern equivalent
The user gets deprecation warnings
You see strikethrough symbols in docs (indicates deprecated)
Migrating from older versions of ember-data
Common deprecations to check:
@ember-data/request → @warp-drive/core
@ember-data/store → @warp-drive/core
StableRecordIdentifier → ResourceKey
StableDocumentIdentifier → RequestKey
@ember-data/tracking → @warp-drive/ember
| Name | Required | Description | Default |
|---|---|---|---|
| apiName | Yes | The API, package, or class name to check. Examples: "StableRecordIdentifier", "@ember-data/request", "findAll builder", "withBrand" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly indicates a read-only lookup operation ('Check if...') and provides additional context about common deprecations and valid input examples. It doesn't mention side effects or permissions, but the tool's nature makes these unnecessary.
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 well-structured with a clear opening sentence, a 'Use this when' section, and a 'Common deprecations' list. Every sentence serves a purpose, and the content is front-loaded with the most important information.
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 parameter and no output schema, the description covers purpose, usage context, and examples effectively. It doesn't specify the return format, but the straightforward nature of the tool makes that less critical. It also differentiates well from siblings.
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 coverage is 100%, so baseline is 3. The description adds value by providing concrete examples of valid apiName values (e.g., 'StableRecordIdentifier', '@ember-data/request') and listing common deprecations, which helps the agent understand what to pass.
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's function: 'Check if a WarpDrive or EmberData API is deprecated and find its replacement.' This is a specific verb+resource, and it distinguishes itself from siblings like search_warp_drive_docs by focusing on deprecation status rather than general documentation.
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 provides an explicit 'Use this when' list covering legacy code, deprecation warnings, strikethrough symbols, and migrations. This gives clear context for when to use the tool, though it stops short of explicitly naming alternative tools for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search WarpDrive guides, tutorials, and cookbook recipes.
Use this for "how do I..." questions like:
How do I set up authentication with WarpDrive?
How do I write a request handler?
How do I write a request builder?
How do I migrate from legacy EmberData adapters/serializers?
How do I use WarpDrive with React?
How does caching work?
How do I handle errors?
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The topic you want a guide for. Examples: "auth handler", "request builder", "caching", "React setup", "migration from adapters" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral responsibility. It uses the verb 'Search', implying a read-only operation, and the examples clarify the type of content returned. However, it does not explicitly state that it is non-mutating, how results are returned, or any limitations, leaving some transparency gaps.
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 well-structured with a clear lead sentence followed by a bulleted list of examples. It is front-loaded and reasonably concise, though the list is somewhat long (7 examples) and could be trimmed without losing meaning.
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 (one parameter, no output schema), and the description covers purpose and usage adequately. However, since there is no output schema, the description does not explain what the search returns (e.g., list of guides, titles, snippets), which is a gap for the agent to set expectations.
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 schema provides 100% coverage for the single 'topic' parameter with examples, meeting the baseline. The description adds value by showing the kinds of 'how do I' questions users might ask, which helps the agent infer appropriate topic values beyond the schema's examples.
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 'Search WarpDrive guides, tutorials, and cookbook recipes' with a specific verb and resource. It distinguishes itself from siblings like get_warp_drive_package and get_warp_drive_overview by focusing on guides/tutorials/cookbook content, making the purpose unambiguous.
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 explicitly says 'Use this for "how do I..." questions' and provides a list of concrete examples, giving clear context for when to use the tool. However, it does not name alternatives or state when not to use it, so it lacks explicit exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a high-level overview of all WarpDrive packages and what they do.
Use this when:
Starting a new WarpDrive project and not sure which packages to use
You need to understand the package structure before diving into specifics
The user asks "what is WarpDrive" or "how does WarpDrive work"
You need to know which package contains a feature
| 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 carries the full burden. The description implies a read-only informational query but does not explicitly state safety, side effects, or return format. For a simple overview tool this is adequate but not deeply transparent.
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 opens with a clear one-sentence purpose followed by a concise bullet list of use cases. Every element adds value and the structure is scannable and front-loaded.
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 zero-parameter overview tool with no output schema, the description sufficiently explains what it does and when to use it. It could mention the expected return format for full completeness, but the use case list makes the tool's behavior clear.
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 0 parameters, so the baseline per rubric is 4. The description does not need to add parameter semantics since there are none, and the empty schema already reflects this.
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 explicitly states the tool's action: 'Get a high-level overview of all WarpDrive packages and what they do.' This is a specific verb+resource combination that clearly distinguishes it from sibling tools like search_warp_drive_docs and get_warp_drive_package.
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 'Use this when' list provides explicit scenarios (e.g., starting a new project, understanding package structure, user asks 'what is WarpDrive'). However, it does not explicitly mention when not to use this tool or directly reference alternative tools, so it falls short of a 5 but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete documentation for a specific WarpDrive or EmberData package.
Use this when you need full details about a specific package like:
@warp-drive/core (Store, RequestManager, CacheHandler)
@warp-drive/json-api (JSONAPICache)
@warp-drive/react (React hooks and components)
@warp-drive/ember (Ember integration)
@warp-drive/utilities (URL builders, query params)
@warp-drive/schema-record (SchemaRecord, SchemaService)
@warp-drive/legacy (migration from legacy EmberData)
@ember-data/store, @ember-data/model, etc. (legacy packages)
| Name | Required | Description | Default |
|---|---|---|---|
| packageName | Yes | The package name. Examples: "@warp-drive/core", "@warp-drive/json-api", "@warp-drive/react", "@ember-data/store" |
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 discloses the tool's primary behavior (retrieving complete documentation) and implies a safe read-only operation. For a simple retrieval tool with no side effects, this is sufficient, though it does not elaborate on error handling or return format.
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 concise and well-structured: it opens with the core purpose, then provides a clear bulleted list of example package names. Every sentence contributes useful information, and there is no redundant or misleading content.
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 tool with a single parameter and no output schema, the description is complete. It explains what the tool does and when to use it, and the schema covers the parameter. The examples make the expected input clear, so no further context is needed for the agent to select and invoke this tool correctly.
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 already has 100% coverage of the single parameter 'packageName', including examples. The description only repeats similar examples without adding new meaning or constraints, so it adds marginal value 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 clearly states the tool's function: 'Get complete documentation for a specific WarpDrive or EmberData package.' It uses a specific verb ('Get') and resource ('complete documentation for a specific package'), and the examples and scope distinguish it from sibling tools like search or overview.
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 explicitly says 'Use this when you need full details about a specific package like:' followed by a list of examples, which provides clear context for when to use it. However, it does not explicitly mention alternative tools or provide exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search WarpDrive and EmberData documentation for any API, class, function, or concept.
Use this tool when you need to know:
How to use any @warp-drive/* or @ember-data/* package
The correct API for Store, RequestManager, JSONAPICache, SchemaRecord, etc.
How handlers, builders, or the request pipeline work
Migration paths from legacy EmberData to WarpDrive
How to use WarpDrive with React, Ember, or other frameworks
Any type definitions, interfaces, or function signatures
Always use this before writing WarpDrive code to avoid hallucinating APIs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for. Examples: "RequestManager", "Store.request", "JSONAPICache setup", "findRecord builder", "React hooks", "handler pipeline" | |
| maxResults | No | Max number of doc sections to return (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly establishes a read-only search behavior with no side effects, and covers scope and expected use. It does not detail the exact result format (snippets vs. full sections), but the schema's maxResults description partially addresses this limitation.
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 opens with a concise summary, then uses a well-structured bullet list of use cases, and closes with a practical directive. Every sentence earns its place without redundancy.
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 search tool with only two parameters and no output schema, the description is comprehensive. It covers purpose, specific use cases, and the timing rule, making it fully usable without additional context from sibling 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?
Schema coverage is 100%, with both query and maxResults having detailed descriptions and examples. The description adds little beyond the schema, so the baseline score of 3 is appropriate.
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 identifies the tool as a documentation search for WarpDrive and EmberData, listing specific packages and APIs. It is distinct from the sibling get_* tools by emphasizing targeted search over fetching a specific guide or package.
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 explicitly enumerates when to use the tool (API lookups, migration paths, package usage, framework integration) and adds a strong directive to always use it before writing code. However, it does not explicitly mention when not to use it or name alternative sibling tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: searching docs, getting package details, getting an overview, finding guides, and checking deprecations. There is no overlap in their target use cases.
All tool names follow a consistent verb_noun pattern with 'warp_drive' in the middle, making the naming style uniform and predictable.
With 5 tools, the server is well-scoped for documentation lookup. Each tool covers a necessary aspect of documentation access without redundancy or bloat.
The tool set covers searching, package details, overviews, guides, and deprecations—covering the full documentation lifecycle for WarpDrive and EmberData. There are no obvious gaps for typical documentation queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
MCP server for agentverse documentation, generated by doc2mcp.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MehulKChaudhari/warp-drive-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
