Conciergr

Remove one branch

remove_branch

Destructive

Remove one branch by its id; every other branch stays. On the SGD 89 plan (get_overview billing.perBranch true) removing a branch past the first lowers the bill by SGD 20 a month from the next bill; the result's billChange gives the new monthly total.

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

Input Schema

Name	Required	Description	Default
`id`	Yes
`brand`	No	Which assistant (its slug from get_overview `brands[].slug`). Leave out when the business has one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-structured context: only the targeted branch is affected, and the billing consequence (SGD 20/month reduction past the first branch) with the result's billChange field. It stops short of saying the removal is irreversible or what happens with an invalid id.

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?

The core action and its scope lead the sentence, with the billing detail trailing as secondary context. It is compact for the amount of information conveyed, though the SGD 89 plan reference is dense enough that it could read as noise to an agent on a different plan.

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?

Two parameters, one required, no output schema; the description covers the essential effects of the call, including the billChange return value, so an agent can invoke it confidently. Missing only error/invalid-id behavior and how to source the id, which are minor for a destructive single-record delete.

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 50%: `brand` is documented in the schema, while `id` is bare. The description clarifies that `id` identifies the single branch being removed, which adds a little meaning, but it contributes nothing about `brand` or how ids are obtained. Baseline 3 fits.

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 ('Remove one branch') plus a scope qualifier ('by its id; every other branch stays') that immediately separates it from save_branch and the other branch-related siblings. An agent knows exactly what is deleted and what is not.

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

Usage Guidelines3/5

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

The billing sentence implies the context in which removal matters (per-branch pricing on the SGD 89 plan), but the description never states when to prefer this over alternatives or any precondition such as needing the branch id from get_overview `brands[].slug`. Usage is inferable rather than instructed.

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

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