Create OmniChannel Routing Configuration

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral context about how capacity, priority, unitType, and pushTimeout affect routing. It does not contradict annotations, but it does not fully disclose edge cases like duplicate names. The added detail is valuable beyond the annotations.

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?

The description is organized with a clear opening sentence followed by bullet-point explanations of key parameters. It is somewhat long but every sentence provides useful information. The structure is easy to scan, though the inaccuracies in parameter descriptions slightly mar the overall clarity.

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?

Given the tool has 10 parameters and no output schema, the description covers the most important parameters and provides a follow-up sibling tool reference. It is largely complete for an AI agent to invoke the tool, but the schema-description contradictions mean the agent could be misled on valid values, and some parameters (label, configName, description) are not explained in the description.

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?

The description explains several parameters (routingModel, capacity, priority, unitType, pushTimeout) with concrete meanings, adding value beyond the schema. However, it contains inaccuracies: it states unitType options are 'Percentage or Throughput' while the schema enum is ['Percentage', 'Items']; it says capacity range 1–100 but schema allows 0–100; priority range 1–10 is not in the schema. These contradictions undermine the reliability of the parameter guidance.

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 clearly states the tool 'Creates a Routing Configuration that defines how work items are assigned to agents.' It uses a specific verb ('creates') and resource ('Routing Configuration'), and distinguishes itself from the sibling tool sf_create_queue_routing_config by explicitly noting the post-create linking step.

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 provides explicit guidance on when to use this tool and what to do next: 'After creating, link it to a queue with sf_create_queue_routing_config.' It also explains the semantics of routingModel options (LeastActive, MostAvailable, ExternalRouting) with clear definitions, helping the agent choose the correct configuration.

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