Create a new configurable agent workspace by providing a name and primary table. Use it to set up a ServiceNow workspace with optional icon and description.
Create a new configurable agent workspace. [Write]
| Name | Required | Description | Default |
|---|---|---|---|
| icon | No | Workspace icon name | |
| name | Yes | Workspace name | |
| table | Yes | Primary table (e.g. incident) | |
| description | No |
Changes observed during successful MCP inspections.
v1.0.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, so the write nature is covered. The description adds 'configurable' as a trait but does not elaborate on side effects, permissions, or what happens on repeated calls. Minimal additional behavioral context beyond 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 a single, front-loaded sentence with no wasted words. It immediately states the action and resource, and the '[Write]' tag is a brief, useful addition. Exemplary conciseness.
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's simplicity (4 parameters, no nested objects, no output schema), the description is adequate but not rich. It does not mention return values, prerequisites, or idempotency caveats, which could be relevant for a create operation. It provides the minimum needed to understand the tool's purpose.
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 description coverage is 75%, meaning most parameters are documented in the schema itself. The description does not add meaningful parameter semantics beyond the schema. The 'configurable' hint is too vague to compensate for the undocumented 'description' parameter, but the schema handles most of the burden.
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 states a specific verb 'Create' with a clear resource 'agent workspace' and qualifier 'configurable', distinguishing it from sibling tools like list_workspaces or get_workspace. It explicitly indicates the action and object in a concise manner.
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 verb 'Create' implies usage for new workspace creation, but the description does not provide explicit context on when to use this tool versus alternatives such as configure_workspace_list or update-related tools. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.