Name based project fields#2760
Draft
veralizeth wants to merge 3 commits into
Draft
Conversation
…eld values by name through the GitHub MCP server
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Let agents address Project v2 fields, single-select options, and item field values by name through the GitHub MCP server — both read and write, instead of pre-resolving node/database IDs. Resolution happens in the wrapper; the underlying GraphQL/REST mutation stays strongly ID-typed.
Why
No linked issue yet.
Today
update_project_itemaccepts owner login, project number, and issue number, but the write still demands the field ID and item ID and does no option-name resolution. Reads are equally ID-bound:list_project_itemsreturns only Title, so reading a field value requires alist_project_fieldspreflight to resolve the field ID first. This forces a multi-step list-and-filter dance, burns context, and invites mis-bound IDs.This is a surfacing gap, not a platform gap — the GraphQL API already resolves names. We move resolution into the wrapper and keep the mutation ID-typed so a blind name pass-through fails loudly rather than corrupting data.
What changed
update_project_item): accept a field byupdated_field.name, resolve the single-select option by name, and resolve the item byitem_owner+item_repo+issue_numberwhenitem_idis omitted — then call the existing ID-typed mutation.{id}and{name}are mutually exclusive; passing both, or neither, fails with a clear error.get_project_item,list_project_items): new optionalfield_namesparam resolved server-side to field IDs, so nolist_project_fieldspreflight is needed.pkg/errors): newStructuredResolutionError(JSON body witherror,name,candidates,hint) forfield_not_found,field_ambiguous,option_not_found,option_ambiguous,item_not_in_project,wrong_field_type.projects_resolver.gowith name→ID resolution helpers +projects_resolver_test.go.databaseIdbefore the REST/GraphQL call.MCP impact
Prompts tested (tool changes only)
Security / limits
Tool renaming
deprecated_tool_aliases.goNote: if you're renaming tools, you must add the tool aliases. For more information on how to do so, please refer to the official docs.
Lint & tests
./script/lint./script/testDocs