ProductBrain MCP Server

rename_project

Change a project's display name (owner only) while keeping its projectId unchanged for continued use.

Instructions

Change a project's display name (owner only). The id is immutable — keep using the same projectId afterwards.

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": {
      "name": "<name>"
    },
    "name": "rename_project"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`projectId`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 18, 2026

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that the operation is owner-restricted and that the id is immutable ("keep using the same projectId afterwards"), which is real behavioral value, but says nothing about reversibility, what the response returns, or failure modes for a mutation tool.

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?

Two tight sentences with zero filler; the core action and the key post-condition (immutable id) are both front-loaded.

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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description covers the essential permission and id-stability facts but leaves return behavior and error/reversal semantics unspecified.

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 coverage is 0% with two params, so the description must compensate. It clarifies that `name` is a display name and implies `projectId` identifies the target and is unchanged, but it doesn't state that `projectId` is required/optional or give format expectations. Partial compensation only.

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 ("Change a project's display name") and narrows scope by distinguishing the display name from the immutable id, so an agent won't confuse it with archive_project or create_project.

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?

The "(owner only)" parenthetical gives a clear authorization precondition for when this tool is usable. It does not name alternatives or when-not conditions, but the usage context is unambiguous for a rename operation.

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