OTP

Raise an issue

add_issue

Raise an issue on this organization's own issues list, where it lands on the issues board and on the Issues section of that team's Delta Meeting. Use this when someone wants something on the agenda: a problem to work through, a decision to make, a topic to raise. Pass team_id to put it in front of a specific team's meeting -- get it from list_meetings, which returns each meeting's teamId; omit it and the issue is org-wide and unassigned, which is a real state, not a failure. This is the org's OWN issue list. To report a bug or request a feature FROM the OTP vendor, use submit_ticket instead -- the two look similar and go to completely different places.

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>"
    },
    "name": "add_issue"
  }
}

Input Schema

Name	Required	Description
`title`	Yes	The issue as the person said it, e.g. 'Feedback for customers wanting to cancel'
`horizon`	No	'short' (default) is worked day to day; 'long' parks it for the quarterly.
`team_id`	No	Team whose meeting should show this issue, from list_meetings' teamId. Omit or pass null for an org-wide issue on no team.
`category`	No	Default 'other', which is what an agenda item usually is
`priority`	No	Default medium
`owner_name`	No
`description`	No	Detail, if the person gave any. Do NOT invent one: leave it out and the issue records where it came from instead.
`owner_entity_type`	No
`owner_external_id`	No	Seat that owns the issue, e.g. 'HUM_DAVIDSTEEL' or 'AGT_RADAR'

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-destructive and closed-world, so the safety bar is lower. The description still adds real behavioral context: omitting team_id yields an org-wide unassigned issue that is "a real state, not a failure," and the description-field guidance warns against inventing content. It does not describe the response shape, but no output schema exists and this is a creation call with a predictable result.

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-loads the verb and destination, then layers usage, the team_id rule, and the sibling disambiguation in a logical order. Mild redundancy between the opening mention of "this organization's own issues list" and the later "This is the org's OWN issue list," but that repetition serves the disambiguation.

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?

For a 9-parameter creation tool with only one required field and no output schema, the description covers the traps an agent would actually hit: routing vs submit_ticket, and optional team scoping. The owner_entity_type/owner_external_id combination and horizon choice are left to the schema, a minor gap but not a blocker.

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 78%, so most parameters are documented structurally. The description adds meaning beyond that for team_id (source it from list_meetings' teamId, and null is valid rather than an error) and reinforces the origin-recording behavior tied to the description field. It says nothing about horizon, priority or the owner_* fields, which the schema carries.

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 ("Raise an issue on this organization's own issues list") and explains where the record surfaces (issues board, team's Delta Meeting). It explicitly distinguishes itself from the look-alike sibling submit_ticket, so an agent can route without opening either schema.

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?

Gives an explicit trigger ("when someone wants something on the agenda: a problem to work through, a decision to make, a topic to raise") and names the alternative with its condition ("To report a bug or request a feature FROM the OTP vendor, use submit_ticket instead"). The team_id inclusion rule is spelled out too.

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

All OTP 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.

Resources

Need Help?