GitLab MCP: workItem query fails, workItems works

まず、GitLab MCP tools、それらに組み込まれたガイダンスまたは例、および gitlab_execute_custom_query 周辺の処理を特定し、失敗している workItem フィールドと、動作している workItems(iid: ...) クエリを比較します。完了条件は、合意した改善のいずれか1つ（標準的なガイダンス、スキーマを考慮した検索、または提案されたフィールドを使った1回の再試行）を選択して実装し、work-item クエリの動作に対するカバレッジを追加することです。

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:

1. First call fails with a schema error.
2. Agent reads the "Did you mean" hint from the error and adjusts.
3. 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