Skip to main content
Glama
Pit Officer

Pit Officer

Official

create_group

Define an account group with a code, optional title, realized P&L currency, and notes so member accounts inherit currency settings; the reserved '-' code is rejected.

Instructions

Create an account group with a code, an optional title, an optional realized P&L currency and optional notes. A member account without its own currency inherits the group's, then the default group's; without a currency the group tier stays unset. The code - is reserved for the default group and refused with validation. Mutates Officer control-plane config; protected and disabled by default.

Input Schema

NameRequiredDescriptionDefault
codeYesGroup code; - is reserved for the default group
notesNoFree-form operator notes; omitted leaves none
titleNoGroup title; omitted leaves the group untitled
currencyNoRealized P&L currency asset code; omitted leaves the group tier unset, so a member account without its own currency inherits the default group's

Output Schema

NameRequiredDescriptionDefault
groupYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that the tool mutates Officer control-plane config, is protected and disabled by default, rejects the reserved '-' code with validation, and explains currency inheritance behavior. It does not mention auth requirements, rate limits, or response behavior, but the output schema covers returns.

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 description is front-loaded with the core action and stays to four sentences. It is efficient, though the reserved-code sentence partially repeats the schema description and could be tightened.

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?

Given four parameters, full schema coverage, and an output schema, the description is largely complete. It covers mutation semantics, protection defaults, validation, and inheritance, though it lacks explicit guidance on choosing this tool over update_group.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: the currency inheritance chain ('inherits the group's, then the default group's') and the validation refusal for the reserved code.

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 a specific verb and resource: 'Create an account group', then enumerates the creatable fields. This clearly distinguishes it from sibling tools like update_group, delete_group, and list_groups.

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?

Usage is implied by 'Create', and the description notes the tool mutates control-plane config and is protected/disabled by default. However, it never explicitly says when to use this instead of update_group, nor does it state prerequisites or required permissions.

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