This server lets AI agents deploy HTML projects to briefroom and manage/retrieve feedback without spawning shell commands.
deploy_html: Zip and upload a local HTML/CSS/JS directory to briefroom, returning a share URL. Supports redeploying into an existing room, setting room name/slug, choosing expiry (7d/30d/never), password protection, visibility (unlisted/password_protected), private/email-invite-only rooms, toggling comments, and display mode (review vs live).
get_feedback: Fetch reviewer comments for a share URL or token as Markdown (default) or JSON; filter by status (open/resolved/all), since a timestamp, and choose locale (ja/en). Works without auth for public comments.
list_deployments: List rooms owned by the current PAT, including their latest deploy and share URL; optional limit and archived filter.
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., "@@briefroom/mcp deploy this directory"
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.
日本語版 README: README.ja.md
briefroom stdio MCP server — expose the briefroom CLI to Claude Code, Codex, Cursor, and other agents so they can deploy HTML and pull reviewer comments without spawning shells themselves.
Deploy in one call — zip a local directory, upload it, get a share URL back.
Pull reviewer feedback — grab comments from the browser as AI-agent-ready Markdown.
List your rooms — enumerate your existing deploys with their share URLs.
Keep it to yourself — deploy straight into a private room only you can open while signed in.
claude mcp add briefroom -- npx -y @briefroom/mcpSet BRIEFROOM_TOKEN in your environment (create a PAT at briefroom.net/dashboard/settings/tokens) or run npx @briefroom/cli login once to store it in the OS keychain.
Related MCP server: Terrarium
Tool | What it does |
| Zip a local directory and upload it to briefroom. Returns a share URL. |
| Fetch reviewer comments for a share URL as AI-agent-ready Markdown (default) or JSON. |
| List rooms owned by the current PAT with their latest deploy and share URL. |
Internally each tool runs @briefroom/cli as a child process (process.execPath → node <cli>/dist/index.js), so behavior stays identical to the CLI and both packages evolve together.
npm i -g @briefroom/mcp
# or use it via npx (recommended for .mcp.json)Config file location and env interpolation semantics differ per client. Pick the block that matches yours.
Put .mcp.json at your project root. Claude Code expands ${VAR} against the launching shell's environment:
{
"mcpServers": {
"briefroom": {
"command": "npx",
"args": ["-y", "@briefroom/mcp"],
"env": {
"BRIEFROOM_TOKEN": "${BRIEFROOM_TOKEN}"
}
}
}
}Or register it via the Claude Code CLI:
claude mcp add briefroom -- npx -y @briefroom/mcpCodex reads MCP server definitions from ~/.codex/config.toml (see the Codex CLI docs):
[mcp_servers.briefroom]
command = "npx"
args = ["-y", "@briefroom/mcp"]
env = { BRIEFROOM_TOKEN = "hak_your_pat_here" }Or omit the env block and let the MCP process inherit BRIEFROOM_TOKEN from the shell that launched Codex.
Cursor does not expand ${VAR} inside env blocks in its MCP config, so you have to decide up front how to supply the PAT. Options, in preference order:
Option A — user-wide config with a literal PAT (keeps PAT out of any repo):
~/.cursor/mcp.json:
{
"mcpServers": {
"briefroom": {
"command": "npx",
"args": ["-y", "@briefroom/mcp"],
"env": { "BRIEFROOM_TOKEN": "hak_your_pat_here" }
}
}
}The file lives in your home directory, so there's no path for it to end up in a project's git history.
Option B — inherit from the parent shell (no PAT in any config file):
Either ~/.cursor/mcp.json or the project's .cursor/mcp.json, with no env block:
{
"mcpServers": {
"briefroom": {
"command": "npx",
"args": ["-y", "@briefroom/mcp"]
}
}
}With env omitted, the MCP process inherits your shell's environment. If you've run npx @briefroom/cli login, the CLI reads the PAT from the OS keychain. Alternatively, launch Cursor from a shell that has BRIEFROOM_TOKEN=hak_... exported.
Not recommended — project .cursor/mcp.json with a literal PAT:
If you must put a literal PAT in the project's
.cursor/mcp.json, add that file to.gitignoreand never commit it. Leaked PATs in public repos are a well-known incident class — prefer options A or B above. Rotate the PAT at briefroom.net/dashboard/settings/tokens if you commit one by accident.
The stanza above works verbatim, but consult your client's docs for ${VAR} interpolation semantics and PAT-in-file safety before adopting it — the same "user-wide file or env inheritance" preference order applies.
Two options — pick whichever fits your setup:
BRIEFROOM_TOKEN env var (recommended for .mcp.json): create a PAT at briefroom.net/dashboard/settings/tokens and pass it through the env block above.
OS keychain (recommended for local dev): run npx @briefroom/cli login once. The MCP server picks up the same credential automatically.
BRIEFROOM_TOKEN takes precedence over the keychain when both are set.
get_feedback also works without any credentials — comments on a share URL are public API. Auth only unlocks owner-only fields.
Env var | Purpose | Default |
| Personal Access Token. Skips the keychain lookup. | (unset) |
| Point the CLI at a different backend (dev / staging). |
|
deploy_html{
"path": "./mockups", // required — directory to deploy
"room": "demo-a", // optional — room slug: ascii identifier of the room to redeploy into
"name": "企画書 v2", // optional — room display name, 1-100 chars, any language
"expires": "7d", // optional — "24h" | "7d" | "30d" | "90d" | "never" (Free: 24h / 7d only, private rooms exempt; also updates the existing link on redeploy)
"new": false, // optional — start a brand new room
"password": "s3cret", // optional — password-protect the link (Pro+ plans; passed to the CLI via env, never argv)
"visibility": "unlisted", // optional — "unlisted" | "password_protected" | "email_invite_only"; "unlisted" clears an existing password
"private": false, // optional — true is shorthand for visibility "email_invite_only": only you, signed in, can open the room
"allow_comments": true, // optional — false hides the comment sidebar (viewers see the page + header only); every plan
"display_mode": "review" // optional — "review" (header + comment sidebar) | "live" (chrome-less full-screen page); every plan
}Returns the raw CLI JSON (share_url, room_id, version_number, visibility, allow_comments,
display_mode, …).
On a redeploy, expires / password / visibility / allow_comments / display_mode are
applied to the existing share link (same URL) only when you pass them explicitly. Omit a field
to leave that setting unchanged.
Three identifiers that are easy to confuse:
Field | What it is |
| Display name shown on the dashboard and in the viewer. Any language. Set it on the first deploy; on a redeploy it updates the room name only when passed explicitly (omit it to keep the current name). |
| Room slug — an ascii kebab-case identifier used only to find the existing room to redeploy into. Never part of the share URL. |
share URL | Always auto-issued with a random token ( |
get_feedback{
"share": "https://briefroom.net/s/aB3xQ2mK9pNvR4", // URL or bare token
"status": "all", // optional — "open" | "resolved" | "all"
"since": "2026-07-01T00:00Z",// optional ISO 8601 for delta pulls
"format": "prompt", // optional — "prompt" (Markdown) | "json"
"locale": "ja" // optional — "ja" | "en"
}Returns Markdown by default, formatted so an agent can paste it straight back into context.
list_deployments{
"limit": 20, // optional — 1-100, default 20
"archived": false
}Returns the raw /api/v1/rooms JSON.
Log lines are written to stderr only — stdout is reserved for JSON-RPC. To see what the server does:
BRIEFROOM_TOKEN=$YOUR_PAT npx @modelcontextprotocol/inspector \
npx -y @briefroom/mcpPoint the inspector at a running backend with BRIEFROOM_API_URL=http://localhost:3000 when developing against a local dev server.
resolve_comment — pending backend PAT support on the comment PATCH endpoint.
Streamable HTTP transport for hosted usage.
Issues and pull requests are welcome at github.com/briefroom/mcp. The public repo mirrors the internal source of truth in the briefroom monorepo; changes land upstream first, then are exported here.
Local dev inside this repo:
npm install
npm run build
npm testMIT © Talent Cloud, Inc.
Zip a local directory of HTML/CSS/JS and upload it to briefroom, returning a share URL. Supports a share-link expiry (also applied to the existing link on redeploy) and password protection (Pro+ plans). Uses BRIEFROOM_TOKEN (or the briefroom CLI login) for authentication. Non-interactive.
| Name | Required | Description | Default |
|---|---|---|---|
| new | No | Ignore briefroom.json and create a brand new room with a unique slug. | |
| path | Yes | Path to the directory containing HTML to deploy (required). | |
| room | No | Room slug to deploy into. Overrides briefroom.json / directory name. | |
| expires | No | Share link expiry. Defaults to 7d on the server. When set on a redeploy, it also updates the existing link. | |
| password | No | Protect the share link with a password (Pro+ plans only). Passed to the CLI via an environment variable, never as an argv flag, so it is not exposed in the process list. | |
| visibility | No | Share link visibility. 'unlisted' removes an existing password; 'password_protected' requires the password field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: zipping, uploading, returning a share URL, support for expiry and password, redeploy behavior (updates existing link), and secure password handling (env var not argv). It is comprehensive and honest.
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 (three sentences), front-loaded with the main action, and each sentence adds value. 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?
The description covers overall process, authentication, non-interactive mode, and key features. With no output schema, it would benefit from describing the return value format (e.g., a URL string). Otherwise, it is adequate for a deployment tool.
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 minimal parameter-level detail beyond the schema, but provides useful context on authentication and password security. It does not elaborate on individual parameter semantics.
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 (zip and upload a local directory), the resource (HTML/CSS/JS files), and the outcome (returning a share URL). It is specific and distinct from siblings, which are unrelated feedback and listing 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?
The description provides context on when to use the tool (deploying a local directory to briefroom) and mentions authentication method (BRIEFROOM_TOKEN or CLI) and non-interactive mode. It does not explicitly exclude alternatives, but siblings are unrelated, so no conflict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch reviewer comments for a briefroom share URL (or raw token) as an AI-agent-optimized Markdown prompt by default, or JSON. Public API — works without auth, but auth returns owner-only fields.
| Name | Required | Description | Default |
|---|---|---|---|
| share | Yes | Share URL (https://.../s/<token>) or raw base32 token (17 or 32 chars). | |
| since | No | ISO 8601 timestamp. Return only comments updated after this instant. | |
| format | No | prompt = Markdown for AI agents (default). json = machine-readable. | |
| locale | No | Language of the returned Markdown. Defaults to OS locale. | |
| status | No | Filter comments by status. Defaults to all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses public access, default output format, and auth-dependent fields. No destructive behavior implied; adequate for a fetch operation.
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 front-loading primary action and key traits. Every sentence adds value 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?
All 5 parameters are documented in schema; description covers output format and auth behavior. No output schema needed for this simple fetch. Complete for the tool's complexity.
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. Description adds context for format (AI-agent-optimized Markdown) and locale (OS default), but most parameter details are in 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?
Description clearly states verb 'Fetch', resource 'reviewer comments for a briefroom share URL or raw token', and output format options (Markdown prompt by default or JSON). Distinct from siblings deploy_html and list_deployments.
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?
Indicates public API with optional auth for owner-only fields, giving context on authentication. Does not explicitly contrast with alternatives, but siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List briefroom rooms owned by the current PAT, with their latest deploy and share URL. Requires BRIEFROOM_TOKEN or a prior briefroom login.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rooms to list (1-100). Defaults to 20. | |
| archived | No | List archived rooms instead of active ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the return includes 'latest deploy and share URL' and the auth requirement, but does not disclose ordering, pagination behavior, rate limits, or side effects.
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 sentences, each adding essential information. No redundancy or fluff. Front-loaded with the main purpose.
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 and no annotations, the description covers the core functionality: listing rooms with latest deploy and share URL, plus auth requirement. It could mention output format or pagination, but it is fairly complete for a simple list tool.
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 noting the default value of 20 for the 'limit' parameter, which is not in the schema. For 'archived', it adds no extra info beyond the schema description.
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 lists briefroom rooms owned by the current PAT, with the latest deploy and share URL. This specific verb+resource+outcome clearly distinguishes it from siblings like deploy_html and get_feedback.
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 a clear prerequisite (BRIEFROOM_TOKEN or prior login), offering context for when the tool can be used. However, it does not explicitly state when to use this tool versus alternative tools like deploy_html or get_feedback.
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.2.0deploy_htmlget_feedbacklist_deploymentsScored across 3 tools
Each tool serves a distinct purpose: deploy_html uploads a project, get_feedback retrieves comments, list_deployments lists owned rooms. There is no overlap in functionality.
All tool names follow a consistent verb_noun pattern with snake_case (deploy_html, get_feedback, list_deployments), making the set predictable.
Three tools is appropriate for a focused service like briefroom. Each tool earns its place and the scope is well-constrained.
The tools cover core operations (deploy, list, get feedback), but there is no explicit tool for deleting a deployment or managing sharing options beyond the deploy tool's parameters. This is a minor gap.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Deploy the small apps your agent builds: one tool call returns a live, private shareable HTTPS link.
Deploy static sites from AI agents: deploy_site publishes files and returns a live URL in seconds.
Deploy AI-generated HTML/CSS/JS to instant public HTTPS URLs from any MCP-compatible agent.
