Replit turns natural-language prompts into full-stack web and mobile applications, complete with databases, authentication, and custom domains. Create new apps, update existing projects, import designs from URLs, ask questions about your codebase, and preview live deployments as you build.
DeepSeek Harness (DSH) is DeepSeek's agent harness. Each MCP server is one plugin entry in your project config.
This guide connects Replit MCP to DeepSeek Harness through MewCP, so DeepSeek Harness can use Replit MCP's 10 tools, like ask_question, create_app_from_prompt and publish_app, without your Replit MCP credentials ever reaching the app.
Replit MCP signs in through managed OAuth. MewCP stores the token encrypted, refreshes it before it expires and injects it only at call time. Your agent never holds it, so it can never leak it.
More apps
Manage repositories, pull requests, issues, branches and development workflows on GitHub. Automate software delivery and collaborate across engineering projects.
Connect to external APIs, webhooks and internet services through standard HTTP requests. Build integrations with virtually any platform that exposes a web-based interface.
Give AI coding agents access to a curated library of real-world website designs, screenshots, design systems, and reusable UI components. Search visual references, find similar designs, analyze layouts, extract colors and typography, compare websites, and retrieve copy-ready JSX components for building better interfaces
HotAPI provides a unified API for AI-powered image, video, and audio generation, image editing, and conversational AI. Developers can access multiple models through a single API key, track asynchronous generation tasks, and retrieve results with polling or webhooks.
Other clients
Replit MCP works the same way in every client below. Pick yours for its own guide.
Free to start.
Scope access to the exact Replit MCP tools and accounts you allow, work and personal side by side. Anything outside that scope is refused at call time, even when the model asks for it.
Each call is logged: what ran, on which account, and whether it worked. Failures come back structured, so the agent knows whether to retry instead of guessing.
Every app sits behind one secure MCP URL, and there is no server for you to deploy or keep running. Add an integration in the dashboard and it is live on the next call, with no config to change and no new credentials to wire up. Tools load only when a task needs them, so your agent stays fast and focused however many apps you connect.
In your DSH project, or the patch file you mount plugins from.
One plugin instance is one MCP server. Add this to your plugin list.
Tools register as mcp__mewcp__<tool_name>. Sign in when the browser window opens.
Start a new chat and ask: "List the tools you can use from MewCP." You should see your connected apps.
Ask the Replit Agent a question in natural language about the user's Replit App's codebase or behavior without modifying it. Use this when the user wants explanation, debugging help, or inspection (for example, understanding how routing works, why a request is failing, or where a bug might be), and NOT when they are clearly asking you to change how their Replit App behaves — in that case, prefer update_app_using_prompt. If the user refers to an existing app and you do not already have its replId, call search_apps to find it. Do not guess a replId. The question should be written in the user's language and tone, as if you were the user, and it will be visible if they open their Replit App in Replit. The response you get back is natural language from the Replit Agent; summarize or quote it for the user as appropriate, still without showing raw code, file paths, or terminal commands in this chat. From the user's perspective, combined with create_app_from_prompt, search_apps, and update_app_using_prompt, this tool is what lets them simply chat ("create or find → inspect/ask → update → repeat") without needing to know about the underlying tools.
Create a brand-new Replit App for the user. Use this the first time the user asks you to build a Replit App in this chat, including when they want the new app to start as a copy of one of their existing apps (pass sourceReplId); do not use it to modify or open existing Replit Apps the user already has in Replit. Replit will receive your request, start working on it in the background, BUT immediately respond to the tool call. Important: a response does not mean the app was created, only that creation started at the returned URL. These details are meant for you, the assistant. The user may not know what tool calls are. Explain in a user friendly way, and provide the URL so they can navigate to the Repl, since without the URL, there would be no way to visually see what Replit built.
Publish the user's Replit App so its latest changes go live at its public URL. If the app has been published before, this republishes it, reusing the existing deployment's settings. If it has never been published, this publishes it with default settings: Autoscale hosting, private visibility when the app belongs to a workspace (organization), public visibility otherwise. Some apps cannot be published from chat the first time; when that applies, this tool returns an error explaining what the user should do on the Replit website instead. Use it when the user asks to publish, deploy, redeploy, ship, or otherwise put their latest changes live; do not use it to change how the app behaves (use update_app_using_prompt for that). This tool returns as soon as the publish is scheduled, but publishing takes a few minutes and some failures only surface while it runs. After starting one, if you are able to wait and poll, call get_publish_status every 30 seconds until the status settles; otherwise tell the user the publish has started and that they should check back later.
Check the publish status of the user's Replit App: whether it has ever been published, the current status of its most recent publish, and the public URL it serves. found=false means the app has never been published; call publish_app to publish it for the first time. When found, 'success' means it is live at the returned url, 'failed' means the last publish did not go through, 'suspended' means the published app is paused and not serving, and anything else means a publish or lifecycle operation is still in progress. Use this to poll every 30 seconds after calling publish_app, or whenever the user asks whether their app is published or what its live URL is. Takes the same replId as publish_app.
List Replit Apps the user can edit, most recently updated first; `query` optionally filters by matching app titles, surfacing the best matches for the query first. Use this when the user wants to browse or pick from their apps, or when you need a replId but resolve_app_by_name returned found=false because the user gave an approximate name — present the returned titles and let the user choose, then pass the chosen replId to update_app_using_prompt or ask_question. This is a search/list, not the exact resolver: prefer resolve_app_by_name when the user already gave an exact app name. Results can include apps owned by or shared with the user.
Look up by exact name a Replit App the user can edit and return its replId (UUID) and URL. Use this when the user refers to an app by name (e.g. "update my Todo App", "what does my Recipe Tracker do?") and you don't already have a replId from create_app_from_prompt earlier in this conversation. Pass the result's replId into update_app_using_prompt or ask_question to act on the app. Matching is case-insensitive but exact: this is a name resolver, not a search. If the user gives you an approximate or partial name and this tool returns found=false, call list_apps (optionally with the partial name as the query) and let the user pick from the results rather than guessing. Results can include apps owned by or shared with the user.
Search Replit Apps the user can edit (owned or shared with them). query is a BM25-style keyword search over app titles, best matches first; updatedAfter/updatedBefore bound the last-updated time; these combine. Prefer the default recency ordering: only set updatedAfter/updatedBefore when the user explicitly asks to filter by time, since date bounds exclude apps that would otherwise be listed. url resolves a Replit App URL directly to that app and ignores the other filters. With no filters, this returns the user's most recently updated apps. Pass a result's replId to update_app_using_prompt or ask_question to act on that app. <important>This tool is EXPERIMENTAL: prefer it for finding the user's apps, but if it errors or its results do not match what the user described, fall back to resolve_app_by_name (exact name) and list_apps (recent apps).</important>
Update the user's Replit App. Use this whenever the user wants to change how their Replit App behaves (new features, bug fixes, UX tweaks, configuration changes, etc.). Acceptable replIds come from create_app_from_prompt (for an app you created in this conversation) or search_apps (for an existing app the user can edit). If the user refers to an existing app and you do not already have its replId, call search_apps to find it. Do not guess a replId. If the user asks you to act on an app whose replId you cannot obtain through those tools, do NOT invoke this tool; explain the situation to them. Replit will receive your request, start working on it in the background, BUT immediately respond to the tool call. Important: a response does not mean the app has finished updating, only that updating has started at the returned URL. These details are meant for you, the assistant. The user may not know what tool calls are. Explain in a user friendly way, and provide the URL so they can navigate to the Repl, since without the URL, there would be no way to visually see what Replit built.
List one directory of one of the user's Replit Apps, like the `ls` command. Pass the app's replId, and optionally a directory path; omit the path to list the app's root. Call it again on a subdirectory to explore deeper; a file's full path is the directory names you descended joined with "/" (for example src/pages/Home.tsx), which is what read_app_file takes. Listings show the app's files as they are right now, and may briefly start the app's machine if it was asleep. Dependency and build folders (like node_modules) are left out. If a directory holds more entries than fit in the token limit, the last line says so.
Read one text file from one of the user's Replit Apps. Pass the app's replId and the file's path relative to the app root: the directory names you descended with list_app_files joined with "/", plus the file name (for example src/pages/Home.tsx). This returns the file as it is right now (the same content the user sees in their workspace) and may briefly start the app's machine if it was asleep. Only text files up to about 100 KB can be read; larger files cannot be read with this tool.
