Skip to main content
Glama
Sign In

Everframe

by dev.everframe
OverviewDiscussionsAdmin

Create ticket

create_ticket
Idempotent

Create a ticket with the same fields and behavior as the dashboard. Use get_ticket_options for boards, columns, assignees and repositories. Requires tickets:write. Supply a new UUID requestId for each intended creation; reuse it with identical arguments when retrying. Assignment can notify the assignee or start an assigned agent. File uploads are not supported. To attach files, use the everframe CLI: everframe ticket attach <files…>.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>",
      "projectId": "<projectId>",
      "requestId": "<requestId>"
    },
    "name": "create_ticket"
  }
}

Input Schema

NameRequiredDescriptionDefault
dueAtNo
titleYes
boardIdNo
columnIdNo
priorityNo
startsAtNo
projectIdYes
requestIdYes
descriptionNo
assigneeUserIdNo
agentRepositoryIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (which already cover readOnly=false, idempotent=true, destructive=false), it discloses the permission requirement, the idempotency protocol (new UUID per intended creation, reuse only with identical arguments on retry), and side effects: assignee notification or starting an assigned agent. That is exactly the extra context annotations cannot express.

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?

Front-loaded with purpose, then lookup pointer, then auth, then idempotency, then caveats; every sentence carries information. Slightly dense with five distinct ideas packed in one paragraph, 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?

Given a mutation tool with 11 parameters, no schema descriptions and no output schema, the description covers the highest-risk gaps: permissions, idempotency, side effects and the unsupported upload path. It does not say what is returned (e.g., the created ticket/id) or whether assigneeUserId and agentRepositoryId are mutually exclusive, which an agent needs to interpret a result.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It adds crucial meaning for requestId and implies the assigneeUserId/agentRepositoryId roles, but leaves title, projectId, dueAt, startsAt, description, priority, boardId and columnId semantics entirely to the schema, including the unresolved relationship between assignee and agent assignment.

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?

States a specific verb and resource ('Create a ticket') and immediately scopes it ('same fields and behavior as the dashboard'), which distinguishes it from update_ticket and the comment/attachment siblings in the list.

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

Usage Guidelines5/5

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

Explicitly routes the agent to get_ticket_options for boards, columns, assignees and repositories, states the required scope tickets:write, and names the exclusion plus the alternative ('File uploads are not supported. To attach files, use the everframe CLI...').

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

All Everframe toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources