Create Task

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains that tasks are reminders appearing on task lists and daily agenda emails, and that tasks are date-only. However, it does not disclose return behavior, permissions, or side effects, which are relevant for a create operation.

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 five sentences and front-loads the core purpose. Every sentence contributes useful context—task behavior, differences from events, required/optional parameters, and lookup tool references. It is concise but not terse, and no filler words are present.

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 6 parameters, no annotations, and no output schema, the description provides solid context: it explains what tasks are, when to use them, required vs optional fields, and how to find correct IDs. It omits return value details and error conditions, but for a simple create operation with a well-specified schema, it is sufficiently complete.

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 100%, so the baseline is 3. The description adds limited extra meaning by clarifying that contact_id links to a contact and that assigned_to defaults to the caller (the latter also appears in the schema). It doesn't substantially enrich the parameter semantics beyond what the schema already provides.

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 'Create a new task in Less Annoying CRM,' using a specific verb and resource. It distinguishes tasks from events ('Unlike events, tasks are date-only') and implicitly from notes and other entity types, making it clearly differentiated from 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?

The description states the required parameter ('Required: name') and key optional parameters, and explicitly directs users to get_users and get_calendars for valid IDs. It also contrasts tasks with events to guide tool selection, though it doesn't explicitly name create_event as the alternative.

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