configure_workspace_list

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the '[Write]' tag is largely redundant. The description does add useful behavior beyond annotations: the workspace must pre-exist and existing lists are not updated. It does not explain duplicate handling, permissions, or what the response contains.

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?

Four compact clauses: what it creates, the query mapping, the exclusions, the write marker. Front-loaded with the core action and no filler, though the trailing '[Write]' tag adds little the annotations don't already say.

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?

Five parameters with full schema descriptions and rich annotations mean the description only needs to cover intent and edge cases, which it mostly does. The one gap is return behavior for a create operation (e.g., whether a sys_id comes back), which matters for chaining.

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 100%, so baseline is 3, but the description adds real semantic value by clarifying that 'query' maps to the condition column rather than being a free-form search string. Other parameters (table, title, columns, workspace_sys_id) are left to the schema.

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?

States a specific verb+resource ('Create a legacy sys_aw_list configuration') and scopes it to an existing Agent Workspace, which is far more precise than the tool name alone. It also distinguishes itself from UX list configuration and from updating existing lists, though it does so conceptually rather than by naming sibling tools.

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?

Gives a clear prerequisite ('under an existing Agent Workspace') and explicit exclusions ('Does not update existing lists or configure UX lists'), which lets an agent rule out this tool for edit and UX-list cases. It stops short of naming the alternative tool an agent should use instead for those cases.

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