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

MCP Tools — Feedback (Bug Reports & Feature Requests)

When something in Maestro 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 in the PLEASE brain database and are reviewed by the Maestro 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

`maestro_bug_report`

Submits a bug report against the Maestro 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="maestro")

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

`maestro_bug_report_list`

Lists bug reports previously filed against Maestro. 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=maestro

Feature requests

`maestro_feature_request`

Submits a feature request for the Maestro 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="maestro")

`maestro_feature_request_list`

Lists feature requests previously filed for Maestro. 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=maestro

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 maestro_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
maestro_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 database and Redis healthy."
  severity    = "high"

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

# Example
maestro_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."