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

With no annotations provided, the description carries the behavioral disclosure burden. It clarifies that only pending tasks assigned to the agent are returned, and it notes that tasks may include a skill (playbook) with workflow steps and guards. The verb 'Get' implies a read-only operation, and no destructive or state-changing behavior is suggested. It could be more explicit about side effects or return structure, but for a retrieval tool this is reasonably transparent.

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 front-loaded with the core purpose and then provides three concise, useful examples plus a note about skills. It is slightly longer than strictly necessary because the examples partly repeat schema descriptions, but each example adds a distinct usage pattern and the structure is easy to scan.

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 simple optional-parameter interface and no output schema, the description covers the main invocation modes and hints at what returned tasks may contain. It does not fully describe the task item structure or return format, but the examples and the skill note give an agent enough context to call the tool correctly.

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 input schema already documents both parameters well (100% coverage), so the baseline is 3. The description adds value by showing concrete invocation examples, marking repo_url as preferred, explaining that root_path auto-detects the repo URL, and documenting the no-argument behavior of returning all pending tasks across projects. This goes beyond the schema descriptions.

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 ('Get'), a specific resource ('pending ctlsurf_task items assigned to you'), and a clear scope. It is immediately distinguishable from sibling tools like add_ctlsurf_task_item and update_ctlsurf_task_item, which are mutations, and from get_ctlsurf_instructions, which retrieves instructions rather than tasks.

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 explicitly says to call this on session start to check for work, which gives clear timing guidance. It also provides three usage examples covering repo_url, root_path, and no-argument invocation. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough for an agent to decide.

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