Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Switch brand

use_brand
Idempotent

Pin which brand this connection acts on by providing a brand id or exact name, including shared workspaces. Access is verified for your membership, and the choice persists for this API key until changed.

Instructions

Pin which brand this connection acts on (multi-brand accounts). Pass the brand id or exact name from list_brands. Works for a brand on your own account AND for a workspace another account SHARED with you — for a shared one pass its name or the profile id list_brands prints, and access is verified against your real membership before it is pinned. Persists for this API key until changed, on every surface (hosted connector included — no environment variables, no restart).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
brandYesbrand id (e.g. default / p_xxx), its exact name from list_brands, or the profile id of a workspace shared with you

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.161
    • changedInput schema / properties / brand / description
      Previous value: -"brand id (e.g. default / p_xxx) or its exact name from list_brands"New value: +"brand id (e.g. default / p_xxx), its exact name from list_brands, or the profile id of a workspace shared with you"
    • changedOutput schema / (root)
      Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": false,
-  "properties": {
-    "brand": {
-      "description": "the now-active brand ({id, name})"
-    },
-    "ok": {
-      "description": "true when the brand switch persisted",
-      "type": "boolean"
-    }
-  },
-  "type": "object"
-}New value: +null
  2. Addedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark it as non-read-only, idempotent, and non-destructive. The description adds valuable behavioral detail: the selection persists for the API key until changed, applies to every surface including the hosted connector, requires no environment variables or restart, and verifies real membership before pinning a shared workspace.

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?

The description is three dense sentences with no filler: core action, input requirements, shared-account nuance, and persistence behavior each earn their place. It is front-loaded with the primary purpose and avoids redundancy.

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 a single-parameter stateful switch, the description covers input selection, shared-workspace authorization, persistence, and surface coverage. It does not describe the return value, but no output schema exists and the result is largely inferable from the membership verification and pinning semantics.

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 100% and the schema already documents that brand can be an id, exact name, or shared-workspace profile id. The description reinforces these formats and adds the 'exact name from list_brands' rule, but it does not materially expand on the schema's parameter documentation.

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?

The description opens with 'Pin which brand this connection acts on (multi-brand accounts)', giving a specific verb, resource, and scope. It clearly distinguishes use_brand from sibling tools like list_brands, create_brand, update_brand, and delete_brand by framing it as the action of selecting/activating an existing brand for the connection.

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 description gives clear invocation context: multi-brand accounts, passing a brand id or exact name from list_brands, and handling shared workspaces. It does not explicitly name alternatives or state when not to use the tool, but the context is unambiguous and practical.

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

Deploy Server

Other Tools