Allows publishing Telegram bots to Netrun, including setting bot tokens as secrets and managing new versions of the bot deployment.
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., "@netrun-mcp publish the current folder to Netrun"
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.
Publish websites and Telegram bots to Netrun straight from Cursor, Claude Code, Codex, Claude Desktop, VS Code, Windsurf — any editor or assistant that speaks MCP.
Say “publish this bot to Netrun” in the chat. The agent uploads the folder, asks you for the bot token if the code needs one, waits for the build and hands you the link. Say “I fixed the greeting — update it” and it ships the new version. No servers, Docker or configs on your side.
Sign in at netrun.io → MCP → create an access key.
Connect your editor. The MCP page gives you a ready button or command with the key already inside; the generic form is:
{
"mcpServers": {
"netrun": {
"command": "npx",
"args": ["-y", "netrun-mcp"],
"env": { "NETRUN_API_KEY": "nru_…" }
}
}
}Cursor — click Add to Cursor on the MCP page, or put the JSON above into ~/.cursor/mcp.json.
Claude Code — claude mcp add netrun -s user -e NETRUN_API_KEY=nru_… -- npx -y netrun-mcp
Codex — codex mcp add netrun --env NETRUN_API_KEY=nru_… -- npx -y netrun-mcp
Claude Desktop / VS Code / Windsurf — the JSON above in the MCP servers config.
Requires Node.js 18+.
Related MCP server: mcp-cloud-deploy
Tool | What it does |
| Upload a project folder and put it online — new project or a new version of an existing one. Detects the stack (Python, Node, Go, Rust, PHP, static HTML, Docker, docker-compose…), asks for missing secrets, waits for the build, returns the URL or the failure reason. |
| Is it running? URL, what blocks it, why the last publish failed. |
| Last lines of the app output. |
| Save tokens / API keys as environment variables (stored encrypted) and re-publish. |
| Start, stop, restart. |
| Projects of the account, plan and limits. |
What it deliberately cannot do: pay, renew or delete projects. Those stay with you in the dashboard — the agent gets a link and passes it on.
This package is a thin courier: it zips the folder (honouring .gitignore), sends it to the Netrun API with your key, and asks for status and logs. Building, running, HTTPS and addresses all happen on Netrun. Nothing here needs to be kept secret — the key lives only in your editor's config.
Environment variables: NETRUN_API_KEY (required), NETRUN_API_URL (default https://api.netrun.io/v1), NETRUN_APP_URL (default https://netrun.io).
npm install
npm test
npm run build
node dist/index.js # stdio MCP serverMIT
Start, stop or restart a project. Stopping a Free-plan bot does not pause its free running time.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful behavioral caveat ('Stopping a Free-plan bot does not pause its free running time') that goes beyond the minimal destructiveHint annotation. However, it does not disclose other side effects, idempotency, or what happens on restart, leaving the annotation to carry most of the safety profile.
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 two short sentences with zero filler. The primary action is front-loaded, and the free-plan caveat is placed as a secondary sentence, keeping structure clean and scannable.
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 two required parameters, no output schema, and minimal annotations, the description leaves important gaps: it does not state whether the project must already exist, what the tool returns, or how restart differs from stop+start. The free-plan note is helpful but not enough for confident invocation in all cases.
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?
With schema description coverage at 0%, the description needed to compensate, but it only says 'a project' and never explains what project_id refers to or how the action values map to behavior. The enum and integer constraints in the schema are present, but the description adds no semantic linkage (e.g., where to get project_id or what restart implies).
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 specific verb-action set ('Start, stop or restart') on a clear resource ('a project'), which immediately differentiates it from sibling tools like netrun_status, netrun_logs, and netrun_list_projects. No other sibling performs lifecycle control, so an agent can select this tool without opening the schema.
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 no guidance on when to use this tool versus siblings, no prerequisites, and no exclusions beyond the free-plan note, which is a behavioral fact rather than a usage criterion. An agent must infer the use case from the name and title only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All projects of the account with id, kind, status and public URL. Use it to find project_id for other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this is a safe read operation. The description adds that it lists all projects of the account and includes specific fields, which is useful but does not go deeper into behavior such as pagination or response 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?
Two concise sentences: the first states the resource and fields, the second states the tool's practical purpose. No filler or repetition of the title.
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 parameterless read-only list tool with a clear output field list, the description tells an agent everything needed to invoke it and understand the result. The annotation covers safety, and no output schema is necessary given the explicit field enumeration.
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 description carries little parameter burden. The 100% schema coverage is vacuous, and the description appropriately focuses on the output rather than inputs.
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?
States a specific verb ('List'), resource ('projects'), and the returned fields (id, kind, status, public URL). The stated purpose of finding project_id for other tools distinguishes it from the sibling tools like netrun_status or netrun_publish.
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?
Explicitly says to use it to find project_id for other tools, giving clear context for when it is needed. It does not mention exclusions, but with zero parameters and no real alternatives for listing projects, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Last lines of the application output (stdout/stderr) — the first place to look when a bot is silent or a site errors.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | How many trailing lines to return | |
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, which the description does not contradict. The description adds context about it being a diagnostic tool (stdout/stderr) but does not mention potential large output or that it's just a trailing view. With annotations covering the read-only nature, a 3 is appropriate.
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 states the purpose and usage context. Every word earns its place with zero filler.
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 read-only log retrieval tool with schema coverage on the optional parameter, the description is sufficient. It doesn't mention the return format, but since there is no output schema and the tool is straightforward, the absence is minor.
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%, with 'lines' already having a description. The description does not add meaning to the parameters beyond what the schema provides. However, it implies 'lines' is for trailing lines, which aligns, but no extra value added.
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 returns the last lines of application output, which is a specific resource. It also distinguishes itself by positioning as the first place to look when diagnosing issues, which differentiates it from siblings like status or control.
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 a clear context for when to use ('first place to look when a bot is silent or a site errors'), but does not explicitly mention when not to use it or point to alternatives. Still, the guidance is strong enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a project folder and put it online: creates a new project (pass name) or ships a new version of an existing one (pass project_id). Detects the language automatically (Python, Node, Go, Rust, PHP, static HTML, Docker, docker-compose…). Waits for the build and returns the public URL or the failure reason. If it returns needs_secrets, ask the user for the values and call again with "secrets".
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name for a NEW project (becomes part of the URL). Omit when updating an existing project. | |
| path | Yes | Absolute path to the project folder on this machine | |
| wait | No | Wait for the build to finish (up to wait_seconds). false = return right after upload. | |
| comment | No | Short note for the version history, e.g. "fix /start handler" | |
| secrets | No | Secrets as {"BOT_TOKEN": "123:abc"}. Stored encrypted; delivered to the app as environment variables via .env. Ask the user for values — never invent them. | |
| project_id | No | Existing project to update. Omit to create a new one. | |
| skip_secrets | No | Publish even though the code seems to read env variables that were not provided. Use only after the user confirmed the app does not need them. | |
| wait_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide idempotentHint and destructiveHint, neither of which reveals much about side effects. The description adds meaningful behavioral traits: waits for the build, returns public URL or failure reason, may return needs_secrets, auto-detects language, and implies 'put it online' is a state-changing publish action. It doesn't discuss deployment costs, overwrite behavior, or what happens to previous versions, but it discloses the core flow.
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?
Five sentences, front-loaded with the core action. Each sentence earns its place by explaining mode selection, language detection, wait behavior, return values, and the secrets callback. Minor redundancy with schema details, but it remains dense and readable.
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 no output schema secret, the description must explain the return contract, and it does: public URL, failure reason, or needs_secrets. It covers the main edge case (secrets) and the update workflow關鍵. It doesn't mention rate limits, cleanup, or how to use related tools like netrun_set_secrets, but for an 8-parameter publish tool with nested objects and a retry flow, it is substantially complete.
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 88%, so the schema already documents most parameters well, e.g. project_id ('Existing project to update. Omit to create a new one') and secrets ('Stored encrypted...'). The description adds cross-parameter logic (pass name OR project_id) and the meaning of the return value ('needs_secrets'), but it doesn't need to restate parameter formats since the schema handles them.
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?
Description uses specific verbs ('Upload a project folder and put it online') and clearly scopes the resource: creates a new project or ships a new version of an existing one. It distinguishes behavior from siblings like netrun_list_projects or netrun_status, and also distinguishes create vs update modes.
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?
Provides concrete guidance: 'pass name' for a new project, 'pass project_id' for an existing one, and a retry workflow when the tool returns needs_secrets ('ask the user... call again with secrets'). It doesn't explicitly contrast with sibling tools, but the include/exclude conditions for name vs project_id are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save environment variables (tokens, API keys, passwords) for a project. Values are stored encrypted and never returned. By default the project is re-published so the app picks them up. Ask the user for the values — do not invent them.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Which env file to write to; ".env" unless the project uses another | .env |
| publish | No | Re-publish right away so the running app receives the new values | |
| secrets | Yes | Secrets as {"BOT_TOKEN": "123:abc"}. Stored encrypted; delivered to the app as environment variables via .env. Ask the user for values — never invent them. | |
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal destructiveHint annotation, the description adds substantial behavioral context: values are stored encrypted, never returned, and the project is re-published by default. It also warns the agent not to fabricate values, which is critical for correct use.
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?
Three efficient sentences deliver purpose, key behavioral caveats, and an explicit user-interaction requirement. There is no fluff, and the most important constraints are 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 tool with no output schema and only a minimal annotation, the description covers the essential operational details: what it saves, security properties, the publish side effect, and the requirement to source values from the user. An agent has enough to invoke it 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 schema already documents most parameters well, and the description reinforces the secrets object and publish behavior with meaningful context such as encryption and non-return. It adds value beyond the schema, though it does not deeply elaborate every parameter.
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 saves environment variables for a project, using a specific verb and resource. However, it does not explicitly differentiate itself from the sibling netrun_publish even though it mentions re-publishing as a side effect.
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 provides clear practical guidance: ask the user for secret values and do not invent them. It also notes the default re-publish behavior, giving context for when this tool has broader effects, but it does not explicitly state when to prefer an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current state of one project: is it running, its URL, what blocks it, and — if the last publish failed — why (stage, reason, stderr tail).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, so the bar is lower. The description adds useful context beyond the annotation: it discloses that the tool surfaces potentially sensitive diagnostics (what blocks a project and a failed publish's stderr tail), which is valuable for an agent weighing the call. No contradiction with annotations.
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, front-loaded sentence: the core purpose ('Current state of one project') comes first, followed by a tight list of the four things the agent gets. Every clause earns its place; there is no filler or 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 simple one-parameter, read-only tool with no output schema, the description covers what the call returns and its scope. The main gaps are minor: no pointer to where project_id comes from and 'what blocks it' is not expanded. Overall, an agent has what it needs to call 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?
Schema description coverage is 0%, so the description must compensate. It anchors project_id to a publishable project entity via 'one project' and 'the last publish,' adding some meaning beyond the bare integer schema. However, it doesn't explain how to obtain a valid project_id (e.g., from netrun_list_projects) or clarify what 'blocks' means, so compensation is partial.
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 specific query ('Current state of one project') and enumerates exactly what the agent receives: running status, URL, blockers, and publish-failure diagnostics (stage, reason, stderr tail). The 'one project' scope clearly distinguishes it from sibling netrun_list_projects, and the status-vs-logs/content framing separates it from netrun_logs and the mutating netrun_control/netrun_publish.
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 'one project' phrasing implies the tool is for single-project status checks, which indirectly differentiates it from netrun_list_projects, but there is no explicit when-to-use guidance, no named alternatives, and no exclusions. An agent must infer when this is preferable to netrun_logs or list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who the configured key belongs to, the current plan, project limit and — on the Free plan — how much free running time bots have left. Call it first when the user asks anything about their Netrun account or limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes the safe read-only nature, so the description's job is to add context. It does this by naming the specific data returned (owner, plan, project limit, free time remaining) and advising when to call it. No contradictory or missing behavioral information is apparent for this simple no-parameter 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 only two sentences, with the core output information front-loaded and the usage directive in the second sentence. Every clause adds value with no repetition or filler.
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 no-parameter, read-only, account-info tool, the description is complete: it states what the tool reports, when to call it, and the annotation covers the safety profile. There is no missing information an agent would need to decide to invoke it.
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 takes zero parameters and the schema is empty, so there are no parameter semantics for the description to clarify. Per the baseline for 0-parameter tools, this is fully adequate.
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 lists the tool's function: it reports the configured key owner, current plan, project limit, and remaining free running time. This distinguishes it from sibling tools like netrun_list_projects and netrun_status by focusing on account-level information rather than projects or operational status.
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 'Call it first when the user asks anything about their Netrun account or limits', giving clear when-to-use guidance. It doesn't explicitly name alternatives or exclusions, but the account-focused scope makes the appropriate context unambiguous.
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.0netrun_controlnetrun_list_projectsnetrun_logsnetrun_publishnetrun_set_secretsnetrun_statusnetrun_whoamiScored across 7 tools
Each tool targets a distinct aspect: account info, project listing, per-project status, logs, publishing, secrets, and control actions. There is no overlap in purpose, and descriptions clarify when to use each.
All tool names use snake_case with a clear 'netrun_' prefix, but the pattern is mixed: some are verbs (publish, control), some nouns (status, logs), and 'whoami' is a command. Still, names are intuitive and predictable, with minor deviation from a strict verb_noun convention.
Seven tools is well-scoped for a deployment platform sever. Each tool covers a necessary function without redundancy, and the count is within the ideal range.
The tool set covers the core lifecycle: account info, project discovery, status, logs, publish/update, secrets, and start/stop/restart. A delete project operation is absent, but this is a minor gap that does not break typical workflows.
Build, deploy, and host full-stack web apps from any MCP client. DB, auth, storage, cron included.
Deploy AI-generated HTML/CSS/JS to instant public HTTPS URLs from any MCP-compatible agent.
Publish HTML, Markdown, and multi-file sites as shareable URLs instantly via MCP.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
