The server exposes 17 work item management tools with complete JSON Schema input definitions and brief descriptions. However, descriptions are universally under the 50 - 200 character LLM-optimized range (most are 40 - 90 chars), limiting agent reasoning. No parameter-level enum constraints are defined for categorical fields (status, type, risk categories). Output schemas are not documented, LLMs cannot infer what fields are returned or how to chain tools. Error handling is absent from tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear WRITE vs READ_ONLY risk distinctions. Tool naming is strong (verb_noun convention), but parameter naming lacks type suffixes (user_id vs assigned_to; sprint_id is correct, but status lacks context). The server is a solid data-binding layer but lacks LLM-optimization for agent reasoning.
Tools (17)
add_work_item_commentwriteauth50/100
Adds a comment to a work item in DevOps Velocity
add_work_item_to_sprintwriteauth50/100
Adds a work item to a sprint in DevOps Velocity
create_work_itemwriteauth50/100
Creates a new work item in DevOps Velocity
get_project_detailsread onlyauth50/100
Retrieves detailed information about a specific project by ID
get_projectsread onlyauth50/100
Retrieves a list of projects in DevOps Velocity, optionally filtered by team
get_sprint_detailsread onlyauth50/100
Retrieves detailed information about a specific sprint by ID
No output schemas documented for any tool. LLMs cannot infer what fields are returned or plan chained calls. This forces agents to make discovery calls or guess field names.
All tool descriptions are 40 - 100 characters, below the LLM-optimized 50 - 200 character range. Descriptions are too terse to guide agent decision-making on when to call each tool vs similar alternatives (e.g., get_work_items vs get_sprint_work_items, get_teams vs get_team_details).
Expand all tool descriptions to 50 - 200 characters. Add context on WHEN to use each tool and WHAT the likely next action is. Example: 'get_work_items retrieves a filtered list of work items. Use this to search by status or assignee, then call get_work_item_details for full metadata. Pagination: use limit (1 - 100, default 20) and offset (default 0).' This guides agent reasoning and prevents duplicate tools.
Document output schemas for all tools. At minimum, specify what fields are returned for each. Example for get_work_item_details: Returns {work_item_id (string), title (string), description (string), status (string), type (string), created_by (string), assigned_to (string), team_id (string), sprint_id (string), created_at (ISO 8601), updated_at (ISO 8601)}. This enables agents to chain tools and extract needed fields.
Add enum constraints to categorical parameters. Define valid values in the input schema: status: enum [open, in_progress, resolved, closed] (or match your actual statuses), type: enum [Bug, Feature, Task], risk: enum [READ_ONLY, WRITE] (for filtering). This prevents LLM hallucination and lets clients offer dropdowns.
Add tool annotations via the MCP SDK. Tag READ_ONLY tools with readOnlyHint=true (get_work_items, list_users, etc.). Tag WRITE tools with destructiveHint=true (create_work_item, update_work_item, add_work_item_comment, add_work_item_to_sprint). Tag idempotent operations with idempotentHint=true (or mark non-idempotent operations so agents know to avoid retries without confirmation).
Score history
Overall score trend
↑ 49 points across a rubric change (v1 → v2)
49/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
49
2026-07-28+
v2
2026-03-09
F
0
-
v1
50/100
Retrieves a list of sprints in DevOps Velocity, optionally filtered by project
get_team_detailsread onlyauth50/100
Retrieves detailed information about a specific team by ID
get_teamsread onlyauth50/100
Retrieves a list of teams in the DevOps Velocity system
get_user_detailsread onlyauth50/100
Retrieves detailed information about a specific user by ID or email
get_work_item_commentsread onlyauth50/100
Retrieves all comments for a specific work item
get_work_item_detailsread onlyauth50/100
Retrieves detailed information about a specific work item by ID
get_work_itemsread onlyauth50/100
Retrieves work items from DevOps Velocity filtered by optional status, type, and assigned user
list_usersread onlyauth50/100
Retrieves a list of users in the DevOps Velocity system
remove_work_item_from_sprintwriteauth50/100
Removes a work item from a sprint in DevOps Velocity
No pagination parameters (limit, offset, cursor, total_count) on list/get tools. Large result sets will blow context windows. get_work_items, list_users, get_teams, get_projects, get_sprints, get_work_item_comments all need pagination support.
Parameter naming inconsistency. 'assigned_to' (in get_work_items, create_work_item, update_work_item) is used instead of 'assigned_user_id' or 'user_id'. This ambiguity forces LLMs to guess whether to pass a user ID, email, or username. Compare to the consistent 'sprint_id', 'project_id', 'team_id' used elsewhere.
get_user_details accepts user_id OR email as optional, but does not enforce that at least one is provided. LLMs may call the tool with neither parameter and get an error, or pass both and create ambiguity about which takes precedence.
No error handling or recovery guidance in tool definitions. Tools provide no guidance on what to do if a work_item_id is invalid, a user is not found, or a sprint is full. Error responses will be raw API responses, not actionable for LLM recovery.
No confirmation/dry-run pattern for destructive operations. create_work_item, update_work_item, add_work_item_to_sprint are WRITE operations but lack idempotency hints or confirmation steps. Agents may accidentally create duplicate items or re-add items to sprints.
Add pagination to list/get tools. For each tool returning lists (get_work_items, list_users, get_teams, get_projects, get_sprints, get_work_item_comments), add parameters: limit (int, 1 - 100, default 20), offset (int, default 0). Return a total_count field so agents know if more results exist. This caps context usage and improves efficiency.
Standardize parameter naming. Change 'assigned_to' to 'assigned_user_id' or 'user_id' in get_work_items, create_work_item, update_work_item. Consistent naming lets LLMs reuse values across tools without mapping overhead.
Document mutually exclusive parameters. For get_user_details, state: 'Exactly one of user_id or email must be provided.' This prevents ambiguous calls and guides LLMs to pass the right parameter.
Add error handling and recovery guidance. For tools that accept IDs, document: 'If work_item_id is invalid, returns {error: 'work_item not found', suggestion: 'Call get_work_items() to find valid work_item_id'}. ' This enables agents to self-correct without human intervention.
Add confirmation for WRITE operations. Offer a dry_run parameter (boolean, default false) for create_work_item and update_work_item. When true, return what would be created/updated without persisting. This prevents accidental duplication and lets agents review before committing.
Clarify idempotency semantics. Document whether add_work_item_comment is idempotent (retrying with same input should not duplicate) or non-idempotent (each call adds a new comment). If non-idempotent, agents need confirmation before retry.