MCP server for ticket management and agent session orchestration. Supports architect sessions (full ticket/session management), ticket sessions (work on specific tickets), and collab sessions (ticketless collaborative work).
Cortex MCP server has 19 tools with basic descriptions and some parameter documentation, but significant gaps in schema completeness and consistency. Tool names follow verb_noun convention (listTickets, readTicket, createWorkTicket, etc.), which is good. However, input schemas are not visible in the provided source code, only tool names and descriptions are shown. Parameter types and constraints are inferred from descriptions rather than formally declared. Descriptions range from adequate (194 chars avg baseline) to overly detailed with implementation notes. No output schemas documented. Error handling guidance is absent. Duplicate tool registrations (readTicket, concludeSession, createFollowUpTicket appear 2-3 times) suggest inconsistent tool organization across architect and collab contexts.
Conclude the collab session and create a conclusion record. Include the outcome, files changed, and follow-up work or blockers. commits is optional.
Conclude the architect session and clean up. Include tickets touched, key user requests, decisions, blockers, and next steps.
Conclude the session and mark the ticket as done. commits is required (at least one SHA). If no commits were produced, set rejected=true and provide a rejection_reason.
Create a follow-up work ticket in backlog, automatically linked to the current ticket. The new ticket's references will include the current ticket ID, and the current ticket's references will be updated to include the new ticket ID.
Create a follow-up work ticket in backlog, automatically linked to the current ticket. The new ticket's references will include the current ticket ID, and the current ticket's references will be updated to include the new ticket ID.
Create a new work ticket in backlog. Requires a repo field — provide a stable repo key from cortex.yaml.
Input schemas not visible in source code. Tool definitions show names and descriptions only; parameter types, constraints, and output schemas are not declared in the provided code. This violates the pattern:tool requirement for complete schema documentation.
Duplicate tool registrations. readTicket, concludeSession, and createFollowUpTicket appear multiple times (2-3 instances each) across architect and collab contexts. This creates ambiguity about which version is canonical and violates the pattern:tool-chain principle of single responsibility.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Delete a ticket by ID
Edit part of a ticket body using oldString/newString replacement. Preferred over updateTicket for body edits because it avoids full-body JSON serialization issues.
List persistent conclusion records (metadata only, no body). Paginated, newest first. Use readConclusion to fetch full body.
List tickets by status. Status parameter is required and must be one of: backlog, progress, done.
List available agent variant names from the agents map in cortex.yaml. Use the returned names as the variant parameter in spawnSession and spawnCollabSession.
Move a ticket to a different status
Read a conclusion record by ID, including the full body.
Read full ticket details by ID
Read full ticket details by ID. Use this to get context on referenced tickets.
Search across all tickets (all statuses) and conclusions by a case-insensitive substring query. Returns tickets in readTicket shape (with conclusion nested if done) and bare ticketless conclusions. Results sorted newest-updated first.
Spawn a ticketless collab session at any valid filesystem path with a kickoff prompt. The agent starts immediately in the directory with the given prompt as context.
Spawn a new agent session for a ticket. Use listVariants to see available agent variant names, then pass the chosen name as the variant parameter.
Update mutable ticket fields. Accepts: id (required), title, body, dueDate, references. dueDate must be RFC3339 when set, and an explicit empty string clears it. Use editTicketBody for targeted body edits; keep updateTicket for full-body rewrites. Does NOT support updating type, repo, status, or any other fields.
No output schemas documented. Descriptions state what tools return (e.g., 'Read full ticket details', 'List persistent conclusion records') but do not specify the structure of returned objects, field names, or types. LLMs cannot plan downstream tool calls without knowing response structure.
Destructive operations lack confirmation or dry-run support. deleteTicket and concludeSession (which marks tickets done) have no confirmation step or recovery guidance. Agents can irreversibly delete tickets without safeguards.
No error handling guidance. Tool descriptions do not explain what errors can occur, how to recover, or what the LLM should do next. E.g., createWorkTicket requires a 'repo' field from cortex.yaml but does not explain what happens if the repo key is invalid.