Skip to main content
Glama
Sign In
idea-base-mcp-server

idea-base-mcp-server

Official
by IDEAManagement
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

report_bug

File a bug report against IDEA Base through the existing Help Desk intake so support staff can track platform issues and resolve them.

Instructions

File a bug report against IDEA Base itself as a support ticket, through the existing Help Desk intake (POST /api/tickets, category "bug") — not a second intake path. Use this when something in IDEA Base is broken, not for a customer project's own bugs. Staff see it in the Help Desk queue.

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": {
      "subject": "<subject>"
    },
    "name": "report_bug"
  }
}

Input Schema

NameRequiredDescriptionDefault
subjectYesShort summary of the bug (the ticket subject)
priorityNoDefaults to normal
project_idNoOptional: the IDEA Base project this bug relates to
descriptionNoWhat happened, steps to reproduce, and expected vs. actual behavior

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.9.1

TDQS

A3.9/5.0
Behavior3/5

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

No annotations exist, so the description carries the whole burden. It does disclose the meaningful side effect (a ticket is created in the Help Desk queue and staff see it) and that it reuses the existing intake rather than a parallel path. It omits what the call returns (ticket id?), whether duplicates are detected, and any permission requirements.

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?

Purpose and endpoint are front-loaded in the first sentence, with scope and consequence following. Slight redundancy in 'through the existing Help Desk intake ... not a second intake path', but each clause still carries usable meaning.

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 simple 4-parameter creation tool with no output schema, the key selection question (is this an IDEA Base bug or a project bug?) is answered. Missing details are the return value and duplicate/permission behavior, which are secondary for invocation.

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 description coverage is 100%, so baseline is 3. The description adds only the fixed category ("bug") context; it does not clarify when to set project_id versus leaving it blank, or how priority interacts with staff triage, beyond what the schema's own descriptions already say.

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 ('File a bug report against IDEA Base itself as a support ticket') and pins the mechanism (POST /api/tickets, category "bug"). It also explicitly distinguishes scope from sibling work: 'not for a customer project's own bugs.' An agent can tell exactly what this does without opening the schema.

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?

Provides a clear when-to-use ('something in IDEA Base is broken') and an explicit when-not-to-use ('not for a customer project's own bugs'). It stops short of naming where projects' bugs should go instead, but no sibling tool in the list covers that case, so there is little to route to.

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