Skip to main content
Glama
Sign In
op-product-design-mcp

op-product-design-mcp

by ChinaCarlos
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

打开预览服务

start_preview

Launch a local hot-reload HTTP server for a Spark OP prototype by slug, returning the URL to open in Codex's built-in browser; omit the slug to get the list page.

Instructions

启动 127.0.0.1 热更新 HTTP 服务，返回给 Codex 内置浏览器打开的 URL。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "start_preview"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNo指定原型；省略则返回列表页

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

B3.3/5.0
Behavior3/5

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 does disclose the key traits: localhost binding, hot-reload behavior, and that it returns a URL for the built-in browser. It omits server lifecycle details such as port persistence, blocking behavior, idempotency, or how the service is stopped.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence that front-loads the action ('启动...服务') and ends with the return value. No filler or redundant clauses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a side-effecting server-start tool with no annotations and no output schema, the description covers the essentials of what happens and what is returned. It remains silent on the operational details an agent would want (prerequisites, port conflicts, lifecycle), leaving a meaningful gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the optional slug parameter and its fallback behavior. The prose adds nothing beyond what the schema states, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource: it starts a hot-reload HTTP server on 127.0.0.1 and returns a URL for the built-in browser. This is clearly distinguishable from siblings liked list_prototypes or export_prototype. However, it does not explicitly state what it is not, so it earns a 4 rather than a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites (e.g. must a prototype exist first?), and no mention of alternatives or when not to call it. The agent must infer its place in the workflow purely from the name and the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools