list_sprintsList sprints for projects in the companies the user belongs to. Filter by state (PLANNED|ACTIVE|CLOSED) and order by start/end date. Use it to find a project's active sprint. Each sprint carries app_url, a deep link straight to it in the ProWoDo web app — give it to the user instead of describing where to click.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context: the data scope (companies the user belongs to) and the presence of app_url with a direct instruction to give it to the user instead of navigation instructions. This goes beyond the annotations and helps the agent understand behavioral expectations.
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 three sentences, front-loaded with the primary purpose, followed by a usage tip and an actionable instruction about app_url. Every sentence adds value with no redundancy or filler.
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?
For a list tool with readOnly and idempotent annotations, the description covers the main purpose, filtering, and a key output field (app_url). It does not mention pagination defaults or other fields, but the lack of an output schema and the simplicity of the use case allow this level of detail to be sufficient. The scope and the deep-link behavior add completeness beyond bare listing.
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 schema already includes descriptions for page, page_size, and date formats, but the description adds meaning for the state filter (PLANNED|ACTIVE|CLOSED) and the ability to order by start/end date. The schema coverage signal is 0% for the top-level body parameter, but the inner properties have some descriptions. The description does not explain the date range suffixes (_gte, _lte) or the ordering mechanism in detail, so it partially compensates for the coverage gap.
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 exactly what the tool does: 'List sprints for projects in the companies the user belongs to.' It specifies the resource (sprints), the scope (projects in the user's companies), and supports filtering by state and ordering. This clearly distinguishes it from sibling tools like retrieve_sprints (single sprint) and list_sprint_lanes.
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 a concrete use case: 'Use it to find a project's active sprint.' It does not explicitly mention alternatives or when not to use it, but the specific use case and the context of sibling tools (e.g., retrieve_sprints for a single sprint) imply the right scenarios. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly scoped to a specific resource and action, but a few near-overlapping pairs (e.g., list_attachments vs list_taskattachments, create_tasktags vs add_tag_tasks) could cause misselection without close reading. Descriptions are detailed enough to resolve most ambiguity.
The dominant verb_noun CRUD pattern (create_, list_, retrieve_, update_, partial_update_, destroy_) is consistent and predictable. However, non-standard pluralizations (companys, resumeentrys, taskdependencys) and a handful of irregular names (task_assign_user, move_relate_to_tasks) introduce minor inconsistencies.
With 83 tools, this server is far beyond a well-scoped MCP surface, even for a feature-complete project management suite. The sheer volume will overwhelm agents and make selection inefficient, clearly falling into the extreme-mismatch range.
The toolset provides thorough lifecycle coverage across companies, projects, tasks, sprints, attachments, comments, dependencies, tags, reminders, resume entries, tickets, and users. Missing operations like company deletion or task-attachment creation appear intentional and are worked around via existing tools.