InfraNest

File an incident in the team's issue tracker

create_incident_ticket

Idempotent

Opens an issue for an incident in the tracker the organization connected (Jira, Linear or GitHub), with the incident's title and a link back to it, and returns its key and url. Leave connection_id and target out to use the organization's Issues for incidents defaults; when there is no single choice, the answer lists the trackers or the teams, projects or repositories to pick from: ask the person which. An incident that already has a ticket gets no second one: the answer is that ticket, with outcome "existing". When no tracker is connected the answer says what to connect. Ask the person before calling it, naming the incident and the tracker, and afterwards link the ticket's url.

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": {
      "incident_id": "<incident_id>"
    },
    "name": "create_incident_ticket"
  }
}

Input Schema

Name	Required	Description
`target`	No	Optional. The Linear team, Jira project key or GitHub repository (owner/name) to file into. Default: the one the connection files incidents into, or its only one.
`incident_id`	Yes	The incident id, from status_overview or list_incidents.
`connection_id`	No	Optional. The tracker connection to file into, from a previous answer that listed them. Default: the one whose Issues for incidents switch is on, or the only one.
`organization_id`	No	The organization. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: deduplication ('an incident that already has a ticket gets no second one', outcome "existing"), the listing response when no single default exists, and the missing-connection response. It doesn't cover auth preconditions or rate limits, but the annotations already declare openWorldHint/destructiveHint=false. Note: the description says it always returns the key, while the deduplication path returns the existing ticket, but that is an ambiguity, not a contradiction of the annotations.

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?

It is front-loaded with the core action and return values, then layered with defaults, ambiguity handling, and confirmation instructions. The sentences are dense and use semicolons, but most carry operational information; it is slightly long, though not padded.

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

Completeness5/5

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

With no output schema, the description supplies the return shape (key, url, outcome "existing"), the ambiguity and no-connection outcomes, and the human-confirmation requirement. An agent has everything it needs to call this correctly.

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. The description adds meaning beyond the schema by explaining the fallback behavior: when there is no single connection/target default, the answer lists the trackers or teams/projects/repositories to choose from, which tells the agent how to resolve the optional parameters.

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 — opens an issue for an incident in the connected tracker (Jira, Linear or GitHub) — and names the return payload (key and url). This clearly separates it from siblings like add_incident_note or acknowledge_incident.

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 says to ask the person before calling, what to do when defaults are ambiguous (ask which tracker/team/project), and what happens when no tracker is connected. It also instructs the follow-up action of linking the ticket url afterwards.

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

All InfraNest tools Inspect

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.