OrionBI

Rename a dashboard

dashboard_rename

Idempotent

Rename a dashboard you own or that is shared with you to edit. Changes only what it is called: its address (/d/owner/slug) stays the same, so every link to it keeps working. Names are unique per owner, so a name the owner already uses is refused. Use this — not dashboard_publish under a new name, which makes a second dashboard. dashboard is its current name, or its /d/owner/slug path.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dashboard": "<dashboard>",
      "newName": "<newName>"
    },
    "name": "dashboard_rename"
  }
}

Input Schema

Name	Required	Description	Default
`newName`	Yes	What to call it from now on (1 to 60 characters)
`dashboard`	Yes	Current name of the dashboard, from dashboard_list, or its /d/owner/slug path

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: the URL identity is immutable so existing links keep working, names are unique per owner and duplicates are refused, and the operation is limited to the display name. That tells the agent exactly what side effects occur and what failure mode to expect, which annotations alone (idempotent, non-destructive) do not convey.

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?

Four short sentences, each carrying distinct information: capability, side-effect boundary, constraint, and the routing alternative. The key scoping fact (address unchanged) is placed early and 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?

For a two-parameter mutation with no output schema, the description supplies the permission requirement, the uniqueness failure condition, the non-obvious invariant that links survive the rename, and identifier formats. An agent has everything needed to call it correctly and interpret expectable errors.

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 both parameters are already documented. The description restates that `dashboard` may be the current name or the /d/owner/slug path, which is essentially what the schema says, and adds no format or edge-case details for `newName` beyond what the schema provides.

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 ('Rename a dashboard') plus the exact scope: only the name changes, the /d/owner/slug address does not. It explicitly separates itself from dashboard_publish, so an agent can distinguish it from at least the most confusable sibling without opening schemas.

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 an explicit use/don't-use pair ('Use this — not dashboard_publish under a new name, which makes a second dashboard') and a permission precondition (you own it or it is shared with you to edit). It does not address the other plausible modification sibling, dashboard_patch, leaving one alternative route unmentioned.

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

All OrionBI 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?