Scribase

Create a branch

branches.create

Fork a branch from production (or from) for one task, agent or pull request: a copy-on-write database with its own URL and keys. Expires after ttl_hours. Returns its URL and publishable key once live. Scope: branches:write.

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": "branches.create"
  }
}

Input Schema

Name	Required	Description
`data`	No	What to copy from the parent (default snapshot: schema and data, copy-on-write)
`from`	No	Parent branch, default production
`name`	No	Branch id, e.g. `add-comments`. Optional: generated.
`from_time`	No	Optional RFC 3339 time, e.g. 2026-09-28T10:15:00Z: the branch holds its parent as it was then (inside the project's history window, shown on the Branches page)
`ttl_hours`	No	Hours until it expires (default 24)
`project_id`	No	Project id. Optional: defaults to the project created or used last in this session, or the only one.
`wait_seconds`	No	Seconds to wait until it is live (default 60, 0 returns immediately)
`organization_id`	No	Organization id. Optional: defaults to the token's organization, or the only one you belong to.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations (not read-only, non-idempotent, not destructive), the description adds the lifespan rule (expires after ttl_hours) and the return contents (URL and publishable key once live), and it declares the required scope branches:write. It does not say what happens on repeated calls with the same name, whether branches are capped per project, or how to poll when the call returns before the branch is live.

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?

Three short sentences with no filler: purpose and parent default first, lifetime second, return value and scope last. Nothing is repeated and no sentence could be dropped without losing information.

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

Completeness4/5

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

For an eight-parameter mutation with no output schema, the description covers the essentials: what is created, what it contains, how long it lives, what comes back and what authorization is needed. It leaves the asynchronous path (wait_seconds=0 and subsequent polling) and any branch quotas unaddressed, which is a modest but real 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 every parameter already carries its own explanation including the `from` default and the data/snapshot/schema_only/sanitized enum. The description restates the production default and the ttl expiry but adds no syntax, format or interaction detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ("Fork a branch") plus the resulting artifact: a copy-on-write database with its own URL and keys. The parent default (production or `from`) and the intended unit of work (one task, agent or pull request) make it easily distinguishable from siblings like branches.list, branches.delete and environment.create.

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

Usage Guidelines4/5

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

Gives clear usage context: create one branch per task, agent or pull request, and fork from production unless `from` is supplied. It does not name alternatives (e.g. environment.create) or state when not to create a branch, nor does it mention the natural companion step of tearing the branch down later, so it stops short of full when/when-not guidance.

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

All Scribase tools Inspect

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

Need Help?