Skip to main content
Glama
Sign In

ChatCut

by io.chatcut
OverviewDiscussionsAdmin

get_editor_url

Read-onlyIdempotent

Return the targeted ChatCut project's editor URL for the host's browser/card UI.

Use this after create_project or target_project, or pass projectId from list_projects/the editor URL when continuing an existing project. If no project is known yet, call list_projects, target_project, or create_project first. Always use returned ChatCut URLs and never guess or web-search a hostname (for example chatcut.io or app.chatcut.io). The returned editorUrl is the clean direct user-facing link. Whenever browserHandoff is returned, use browserHandoff.url exactly for the MCP host or internal Browser so its launch-surface, layout, theme, and editor-boot-token parameters are preserved. Never show dockviewLayout, theme, or editor-boot-token in direct Markdown/external-browser links. Returns a liveProject card payload with reusable open modes so the host/user can choose MCP host browser or an external browser. Pass openPricing=true when the user needs billing, plan, or credit recovery; the returned editor URL opens the same project with ChatCut's pricing dialog. Do not open system Chrome/Playwright yourself. This tool does not read or mutate project data.

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": "get_editor_url"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectIdNoProject for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
timelineIdNo
openPricingNoOpen the ChatCut pricing/upgrade dialog on the returned editor URL.
editorBaseUrlNoEditor origin/base URL. Defaults to CHATCUT_EDITOR_URL or http://localhost:5173.
pricingSourceNoOptional analytics source used when openPricing=true, e.g. external_mcp_insufficient_credits.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), yet the description still adds real operational context: never guess hostnames, use browserHandoff.url exactly to preserve launch-surface/theme/boot-token params, never surface dockviewLayout/theme/boot-token in external links, and the shape of the returned liveProject card payload with its open modes.

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

Conciseness4/5

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

Purpose is front-loaded in sentence one, and the remaining sentences are operational constraints rather than filler. It runs long and has some overlap between the URL-guidance and handoff-guidance sentences, but almost nothing is redundant.

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

Completeness5/5

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

No output schema exists, so the description carries the burden of explaining return values — and it does: editorUrl, browserHandoff.url, and the liveProject card payload with reusable open modes. All five parameters are either schema-documented or contextualized, leaving nothing an agent needs before calling.

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

Parameters4/5

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

Schema coverage is 80%, so most parameters are already documented; the description still adds meaning for projectId's source (list_projects/editor URL) and the user-facing intent behind openPricing=true. editorBaseUrl and pricingSource are left to the schema, which is acceptable at this coverage level.

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

Purpose5/5

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

First sentence states a specific verb and resource — returns the targeted project's editor URL — plus the audience (host browser/card UI). It closes with an explicit scope boundary ("does not read or mutate project data"), which separates it cleanly from read_project/web_browser siblings.

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

Usage Guidelines5/5

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

Gives a full call sequence: use after create_project or target_project, or pass projectId from list_projects; if no project is known, call list_projects/target_project/create_project first. It also names when to flip openPricing (billing, plan, credit recovery) and an explicit prohibition ("Do not open system Chrome/Playwright yourself").

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

All ChatCut toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources