Observed behavior
When querying a GitLab work item via gitlab_execute_custom_query, my first attempt used the field workItem on Project, which failed with:
GraphQL error: Field 'workItem' doesn't exist on type 'Project' (Did you mean `workItems`?)
Retrying with workItems(iid: "...") on Project succeeded and returned the expected work item.
Why this is worth improving
The GitLab GraphQL schema evidently drifted (either workItem was removed/renamed, or it never existed on Project and only workItems did). The agent-side pattern is:
- First call fails with a schema error.
- Agent reads the "Did you mean" hint from the error and adjusts.
- Second call succeeds.
This works, but it wastes a round-trip on every session that touches work items, and it depends on the agent noticing the hint. A more robust experience would be one of:
- Auto-retry once when the error message contains a
Did you mean suggestion, substituting the suggested field.
- A schema-aware helper (e.g.,
gitlab_get_type_fields results cached and surfaced in the tool description) so the agent picks the right field on the first try.
- Update any built-in guidance/examples in the GitLab MCP tools to reference
workItems(iid: ...) { nodes { ... } } as the canonical way to fetch a single work item by IID on a Project.
Impact: minor per-call latency + agent context spent on the schema hint. Not blocking, but repeatable across sessions.
Metadata
| Field |
Value |
| CLI Version |
0.8.10 |
| Platform |
darwin |
| Architecture |
arm64 |
| OS Release |
25.5.0 |
| Category |
improvement |
| Working Directory |
feature-1173-parallel-ci-databases |
| Session ID |
ses_0c9a0177effeYuBnIpoLd52aQ1 |
Observed behavior
When querying a GitLab work item via
gitlab_execute_custom_query, my first attempt used the fieldworkItemonProject, which failed with:Retrying with
workItems(iid: "...")onProjectsucceeded and returned the expected work item.Why this is worth improving
The GitLab GraphQL schema evidently drifted (either
workItemwas removed/renamed, or it never existed onProjectand onlyworkItemsdid). The agent-side pattern is:This works, but it wastes a round-trip on every session that touches work items, and it depends on the agent noticing the hint. A more robust experience would be one of:
Did you meansuggestion, substituting the suggested field.gitlab_get_type_fieldsresults cached and surfaced in the tool description) so the agent picks the right field on the first try.workItems(iid: ...) { nodes { ... } }as the canonical way to fetch a single work item by IID on a Project.Impact: minor per-call latency + agent context spent on the schema hint. Not blocking, but repeatable across sessions.
Metadata