product: assert audience: test-developer, operator, ai-assistant authority: normative

MCP Tools — Feedback (Bug Reports & Feature Requests)

When something in Assert is not working as expected, or when you have an idea for an improvement, you are encouraged to file it directly from the AI assistant using the tools below. There is no separate issue tracker to visit — one tool call is enough.

Bug reports and feature requests are stored centrally by Orchestra (never in Trace/PLEASE) and are reviewed by the Assert development team. Filing them from an AI session means all the context (station ID, version, reproduction steps) is written down while it is fresh.

See also: tools-reference.md for the full tool index. For diagnostic steps before filing a bug, see troubleshooting.md.

Bug reports

`assert_bug_report`

Submits a bug report against the Assert station software. Use this whenever you encounter defective behaviour — a broken endpoint, an unexpected error, a regression, or anything that does not match the documented behaviour.

When to use: Something is broken. File this instead of asking the user to email the development team.

Parameter	Type	Required	Description
`title`	string	yes	Short summary of the defect, e.g. `"start_test returns 409 after abort"`
`reportedBy`	string	yes	Your name or station ID, e.g. `"daniel@esharp.se"` or `"station-42"`
`description`	string	no	Steps to reproduce, actual vs expected behaviour, relevant tool output
`severity`	string	no	`"low"`, `"medium"` (default), `"high"`, or `"critical"`

Returns: The created bug report record including its id and status ("open").

Calls: POST /api/please/bug-reports (tagged application="assert")

Severity guidance:

Severity	When to use
`low`	Cosmetic issue; workaround exists and is obvious
`medium`	Unexpected behaviour; workaround exists but is inconvenient
`high`	Significant workflow broken; no workaround
`critical`	Station unusable; production impact

`assert_bug_report_list`

Lists bug reports previously filed against Assert. Use this to check whether a known issue has already been filed before filing a duplicate, or to review the current backlog.

Parameter	Type	Required	Description
`status`	string	no	Filter by status: `"open"`, `"triaged"`, `"fixed"`, `"wontfix"`. Omit to return all.

Returns: Array of bug report records ordered by most recent first.

Calls: GET /api/please/bug-reports?application=assert

Feature requests

`assert_feature_request`

Submits a feature request for the Assert station software. Use this to propose new capabilities, workflow improvements, additional MCP tools, or quality-of-life changes.

When to use: Something works but could work better. The user has a concrete improvement idea.

Parameter	Type	Required	Description
`title`	string	yes	Short descriptive title for the improvement
`requestedBy`	string	yes	Your name or identifier
`description`	string	no	What problem this solves and how the proposed feature would work

Returns: The created feature request record including its id and status ("open").

Calls: POST /api/please/feature-requests (tagged application="assert")

`assert_feature_request_list`

Lists feature requests previously filed for Assert. Use this to check the backlog or to confirm that a request was recorded.

Parameter	Type	Required	Description
`status`	string	no	Filter by status: `"open"`, `"planned"`, `"in_progress"`, `"pending_evaluation"`, `"done"`, `"rejected"`. Omit to return all.

Returns: Array of feature request records ordered by most recent first.

Calls: GET /api/please/feature-requests?application=assert

Recommended workflow

When a user reports a problem during an MCP session:

Diagnose first — use the troubleshooting tools to confirm the root cause. Collect station info, service logs, and the failing execution log.
File the bug — call assert_bug_report with a clear title, the reproduction steps, and the relevant tool output pasted into description. Set severity appropriately.
Tell the user — share the bug report id so they can reference it in follow-up conversations.

# Example
assert_bug_report
  title       = "get_service_logs returns unavailable after update"
  reportedBy  = "daniel@esharp.se"
  description = "After running trigger_system_update, get_service_logs returns
                 {unavailable: true} for all services. Station version: 2.4.1.
                 get_system_health shows Orchestra and Redis healthy."
  severity    = "high"

Similarly, when a user asks for a capability that does not exist yet:

# Example
assert_feature_request
  title       = "Add test duration to get_test_report_summary"
  requestedBy = "daniel@esharp.se"
  description = "The summary response includes pass/fail counts but not the total
                 elapsed time. Adding durationMs would save an extra API call when
                 building run-time dashboards."