feat(github-mcp): read and write GitHub issue types and issue fields

[Martin Bens (SpiGAndromeda)]

Adds three tools for GitHub's issue types and issue fields: one read tool to discover what an organization offers, and two write tools to set them on an issue. issue_view gains the read that pairs with the writes.

The tools

Tool	Server	Purpose
issue_schema	read	An organization's issue types and issue fields in one call, with each single-select field's options
issue_view	read	with_field_values returns one issue's own type and field values, keyed by field name
issue_type_set	write	Set an issue's type by name, or clear it with null
issue_field_set	write	Replace an issue's field values

issue_schema {"org":"shopware","type":"Bug","jq_filter":"{types:[.types[].name],fields:[.fields[].name]}"}
→ {"types":["Bug"],"fields":["Priority","Start date","Target date","Effort"]}

issue_view {"number":19952,"with_field_values":true}
→ {"type":"Bug","field_values":{"Priority":"Low","Effort":"Low"}}

Backed by orgs/{org}/issue-types, orgs/{org}/issue-fields, GET|PATCH repos/{owner}/{repo}/issues/{n}, and PUT repos/{owner}/{repo}/issues/{n}/issue-field-values. No GraphQL.

Two write tools rather than three

PUT on the field-values endpoint is replace-all, so clearing one field means leaving it out and {} clears them all. That makes a separate clear tool redundant, and both tools are idempotent: sending the same call twice leaves the issue in the same state.

The cost is that changing one field is a read-then-write — a caller who passes only Priority on an issue that also had Effort clears Effort. issue_view with with_field_values is that read: gh issue view exposes neither the field values nor, by default, the type, so the read had to be built alongside the writes rather than assumed. Its field_values object is issue_field_set's values parameter, so a caller reads it, changes an entry, and passes the whole object back. A merge mode that folds a change into the current values would drop the read step entirely and stays idempotent; left out deliberately, easy to add later.

Names, not IDs

Reads return a single-select option's id ("value": 12296) while writes take its name ("value": "High"), so feeding a read straight back into a write fails. Both tools take names on both sides and resolve them against the organization's schema before the request, so a wrong name fails locally with the valid ones listed:

issue_field_set {"Prioriti":"High"}  → issue field Prioriti not found. Available fields: Priority, Start date, Target date, Effort
issue_field_set {"Priority":"Urgent"} → option Urgent not found for issue field Priority. Available options: Critical, High, Low
issue_type_set  {"type":"Bogus"}      → issue type 'Bogus' not found in 'shopware'. Available types: Task, Bug, Improvement, Story, Epic

That matters most for fields: GitHub reports an unknown field id as "option with name x does not exist", blaming the value rather than the field. Values are checked against their field's data type as well, and every rejected entry is reported in one message rather than one round trip each.

issue_view reads the option names off the response's option objects rather than passing the raw ids through, and issue_field_set echoes the resulting values in the same keyed-by-name shape, so every point of a read-edit-write agrees. A response holding two values for one field is an error rather than a merge: keying by name is what makes the result writable, and keeping only the last would return a subset that clears the rest on the next write.

Types and fields are not nested

An organization can pin fields to a type, but that pinning only drives the web UI — an unpinned field can still be set on an issue of any type, confirmed against the API. So issue_schema reports the two lists side by side; nesting fields under types would imply a constraint the API does not enforce.

Issue types and issue fields apply to issues only. A pull request reads back type: null and an empty field list, matching GitHub's own statement.

Schema constraints

The last commit declares pattern on the repository and organization parameters, matching what the tool functions already validate. With the vendored SDK the schema is the first gate and the tool function the second:

max_lines: "PATH[$(id)0]"          → Invalid type(s): max_lines expected integer, got string
org: "../../repos/victim/private"  → does not match pattern ^[A-Za-z0-9][A-Za-z0-9-]*$
repo: "widgets"                    → does not match pattern ^[a-zA-Z0-9_.-]+/[a-zA-Z0-9_.-]+$
values: null                       → expected object, got null

issue_schema.repo is deliberately left unconstrained: it also accepts a bare repository name alongside owner, and a pattern requiring a slash would reject that split form. issue_view builds its REST path by concatenation rather than handing a repository to gh, so it validates the resolved owner/repo before the call: letting a malformed one through would turn an input error into a fallback success.