Skip to main content
Glama
competlab

competlab-mcp-server

by competlab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

create_ticket

Open a ticket on a project board by setting its title and status column, with optional labels, assignee, due date, effort, and impact. Requires a read_write API key.

Instructions

Open a ticket on a project's board. title and status are both required — status names the column it lands in and has no default, because where a ticket belongs depends on who opened it. A new ticket lands at the top of its column. A board holds at most 5,000 tickets, and a create past that is refused. What the columns mean: triage — nobody has decided yet; todo — decided and not started; in_progress — being worked on; done — finished; dismissed — the team decided not to do it. The set is fixed and a project cannot add to it. labelIds names labels from the project's own list (list_ticket_labels); a label that is not on that list is refused. Labels are created in the CompetLab app or through the customer API — not from here. The ticket is recorded as opened by an API key rather than by a person, which is how the board tells an automation's tickets from someone's own. Needs a read_write API key; a read key is refused and can only list and read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesThe ticket's title
effortNoHow much work the ticket is
impactNoHow much the ticket matters, from 1 to 4 (1 Minor · 2 Moderate · 3 Significant · 4 Critical; 4 matters most)
statusYesThe column the ticket opens in
dueDateNoThe day the ticket is due, as YYYY-MM-DD — a calendar day, with no clock and no time zone
labelIdsNoLabel IDs from the project's list (from list_ticket_labels)
projectIdYesProject ID (from list_projects)
descriptionNoThe ticket's description, in Markdown
assigneeUserIdNoThe user ID of a current member of the organization (from list_ticket_assignees)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.0.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries the real behavioral load and delivers: the 5,000-ticket cap and refusal past it, new tickets landing at the top of the column, labels being refused if not on the project list, labels not creatable from here, the fixed column set, and the API-key attribution that marks automation-created tickets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded and dense with operational facts; every clause (cap, ordering, refusal conditions, auth) informs correct invocation. Minor redundancy in restating the column set and the label creation caveat, but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters, no output schema, and thin annotations, the definition supplies enough to call it correctly, including the auth requirement and refusal conditions. It does not describe the returned ticket shape, but that is a modest omission given the breadth already covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it explains why status has no default, what each column value means, and that labelIds must come from the project's own list (list_ticket_labels) or the call is refused.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Starts with a specific verb and resource: 'Open a ticket on a project's board.' This is clearly distinguishable from sibling tools like update_ticket, move_ticket, and add_ticket_comment, which each imply a different operation on an existing ticket.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the preconditions for calling it: title and status are both required, status has no default, and a read_write API key is needed (a read key is refused). It does not explicitly contrast with update_ticket or move_ticket, but the create-versus-modify boundary is implied by the opening sentence.

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

Deploy Server

Other Tools