Context
get_remediation_workflow returns the workspace's Incident-page remediation workflow, or the default when none is configured. Per the API schema (v1/openapi.json), the default omits id / created_at / updated_at; a configured custom workflow includes them. The only signal distinguishing custom from default is therefore the presence of id.
Problem
Consumers must infer "custom vs default" from an absent key. In a live agent session this went wrong: the agent saw a populated steps[] in a default-workflow response and labeled it a workspace-configured custom workflow, then blended in generic advice. steps is always present (the default workflow has steps too), so keying on it is a trap — but "absence of id" is easy to get wrong and impossible to assert on positively in tests.
The default payload that triggered the mislabel looked like:
{"workflow": {"account_id": <n>, "steps": [
{"title": "Get the developer involved"},
{"title": "Assess the impact"},
{"title": "Rotate & revoke the leaked secret"},
{"title": "Audit access logs"}
]}}No id, so it is the default — but the rich, plausible titles led the consumer to treat it as custom.
Ask 1 — derived boolean
Have the tool return an explicit is_custom (or has_custom_workflow) alongside the payload, derived server-side from id presence. Consumers then assert on a present field instead of inferring from an absent key; it also removes the root cause of the mislabel.
Ask 2 — docstring / payload alignment
The tool wraps the API dict as {"workflow": {…}}, so fields are at workflow.id, workflow.steps, etc. — but the docstring's field list reads as if they were top-level. Align the docstring (and any downstream docs) with the actual nesting, or flatten the payload.
Verified
v1/openapi.json — id/created_at/updated_at omitted for the default workflow.- ggmcp v0.6.6 —
tools/get_remediation_workflow.py + client.py pass the API dict through verbatim (wrapped as {"workflow": …}), no field stripping.
- Not an auth/scope/version/data-hiding issue: token
workspace_id matched the returned account_id and scopes include incidents:read; the workspace simply had no custom Incident-page workflow.
Context
get_remediation_workflowreturns the workspace's Incident-page remediation workflow, or the default when none is configured. Per the API schema (v1/openapi.json), the default omitsid/created_at/updated_at; a configured custom workflow includes them. The only signal distinguishing custom from default is therefore the presence ofid.Problem
Consumers must infer "custom vs default" from an absent key. In a live agent session this went wrong: the agent saw a populated
steps[]in a default-workflow response and labeled it a workspace-configured custom workflow, then blended in generic advice.stepsis always present (the default workflow has steps too), so keying on it is a trap — but "absence ofid" is easy to get wrong and impossible to assert on positively in tests.The default payload that triggered the mislabel looked like:
{"workflow": {"account_id": <n>, "steps": [ {"title": "Get the developer involved"}, {"title": "Assess the impact"}, {"title": "Rotate & revoke the leaked secret"}, {"title": "Audit access logs"} ]}}No
id, so it is the default — but the rich, plausible titles led the consumer to treat it as custom.Ask 1 — derived boolean
Have the tool return an explicit
is_custom(orhas_custom_workflow) alongside the payload, derived server-side fromidpresence. Consumers then assert on a present field instead of inferring from an absent key; it also removes the root cause of the mislabel.Ask 2 — docstring / payload alignment
The tool wraps the API dict as
{"workflow": {…}}, so fields are atworkflow.id,workflow.steps, etc. — but the docstring's field list reads as if they were top-level. Align the docstring (and any downstream docs) with the actual nesting, or flatten the payload.Verified
v1/openapi.json—id/created_at/updated_atomitted for the default workflow.tools/get_remediation_workflow.py+client.pypass the API dict through verbatim (wrapped as{"workflow": …}), no field stripping.workspace_idmatched the returnedaccount_idand scopes includeincidents:read; the workspace simply had no custom Incident-page workflow.