---
title: "Report Issue"
method: POST
path: "/mcp/tools/report_issue"
tags: ["mcp"]
---

# Report Issue

`POST /mcp/tools/report_issue`

## Request

- Base URL: `https://api.iridiumhqmcp.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.iridiumhqmcp.com/mcp/tools/report_issue`
- Auth: HTTP bearer

Send the Iridium team an anonymous note about something that broke while you were working.

Returns {"received": true}. Nothing is sent to LinkedIn and nothing about the account is
changed. This is NOT a support ticket: the report carries nothing that identifies the user,
nobody will reply, and there is no way to follow it up. It exists so the team can see which
workflows break most and which ones users cannot work without.

USE THIS when an Iridium tool failed, returned something wrong, or made a workflow the user
cares about impossible to finish — especially if you have hit it more than once.

DO NOT USE when the user just needs to be told something (a cap was reached, LinkedIn is
disconnected, a draft was skipped) — tell them, that is not a break. Do not use it to ask a
question, request a feature, or chase a previous report. Call list_solved_issues first; if
the problem is already fixed there, tell the user instead of reporting it again.

Args:
    what_broke: One line on what failed. Max 200 characters.
    how_it_happened: One line on the steps that led to it. Max 200 characters.
    frequency: One of first_time, sometimes, every_time.
    importance: One of nice_to_have, important, blocking — how much the user needs this
                workflow to work.

NEVER include personal or identifying information in either text field: no names, company
names, job titles, message or post text, email addresses, phone numbers, URLs, @handles, or
Iridium handles (draft_, chat_, prof_). Describe the shape of the failure, not the data it
happened to. "Approving a connection note fails when the note ends in a question mark" is a
report; anything naming a person is not. Text containing an identifier is rejected with 422 —
restate it without one rather than working around the check.

## Request body

- ReportIssueRequest
  - `what_broke` string, required: What failed, in one line. No names, companies, message text, emails, URLs, or Iridium handles — the field is rejected if it contains any.
  - `how_it_happened` string, required: The steps that led to it, in one line. Same rule: describe the shape of the failure, never the data it happened to.
  - `frequency` 'first_time' | 'sometimes' | 'every_time', required: How often you have seen this failure.
  - `importance` 'nice_to_have' | 'important' | 'blocking', required: How much the broken workflow matters to the user you are serving.

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/iridiumhqmcp/apis/iridium-linkedin-for-ai-agents.md) · [All operations](https://skmtc.dev/iridiumhqmcp/apis/iridium-linkedin-for-ai-agents/llms.txt) · [OpenAPI document](https://skmtc.dev/iridiumhqmcp/apis/iridium-linkedin-for-ai-agents/revisions/b9f5e020543c?raw)