projects_update_pricing_groupRename a pricing group or change its hourly rate. Rate changes affect revenue on ALL hours logged by members of that group, past and future. The rate is in the workspace currency, echoed as meta.currency in the response.
| Name | Required | Description | Default |
|---|---|---|---|
| group_name | No | ||
| hourly_rate | No | Sales price per hour, in the workspace currency (see meta.currency in the response). | |
| pricing_group_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, which only state this is not read-only and not destructive, the description discloses a non-obvious and important side effect: rate changes affect revenue on ALL hours logged by group members, past and future. It also clarifies currency handling and response echo, which is valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The main purpose is front-loaded, and every sentence adds meaningful context: what the tool does, the side effect, and the response currency hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity mutation tool with one required parameter and two optional fields, the description covers the core purpose, the significant revenue impact, and a response detail. It does not describe the full output shape or explicitly state whether both fields can be updated together, but these are minor gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with just hourly_rate documented. The description partially compensates by mapping group_name to renaming and hourly_rate to rate changes with currency context, but it does not explicitly describe pricing_group_id as the target identifier or explain whether group_name and hourly_rate may be provided together or individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with specific verbs and resources: 'Rename a pricing group or change its hourly rate.' This clearly distinguishes it from projects_create_pricing_group, projects_delete_pricing_group, and projects_assign_pricing_group despite the generic title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear use cases: renaming a pricing group or changing its hourly rate. It does not explicitly contrast with sibling pricing-group tools or state exclusions, but the operation is specific enough that an agent can confidently select this tool for those two actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools follow a clear resource+action pattern and the descriptions are unusually precise about boundaries. A few near-overlaps remain: projects_get_finance vs projects_get_financials, and notes_create vs crm_log_activity on a deal are both plausible for recording a note on a deal.
The domain_prefix_action convention is consistent across nearly all tools, e.g. crm_create_lead, projects_update_risk, timelog_approve_time. Deviations include standalone list_trash, meta tools like whoami/tool_search/tool_invoke, and the confusing projects_get_finance/projects_get_financials pair.
With 105 tools, this far exceeds the 50+ threshold defined as an extreme mismatch. Even for a full ERP/CRM suite, the fine-grained split—39 project tools alone—creates a massive tool-selection surface that is hard for an agent to navigate reliably.
The surface covers CRM, projects, tasks, time/expenses, HR, notes, notifications, contracts, and reporting with create/read/update/delete for most primary entities. Minor gaps exist: crm_log_activity has no read-back path, contracts lack delete/restore, and proposals are intentionally read-only, but agents can work around these.