You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Agent workflows often start from a GitHub bounty issue number or issue URL, such as #649, not from the internal MRWK bounty id. REST bounty rows expose both the internal id and GitHub issue_number, and submit_work_proof already supports issue_number with optional repo scoping.
MCP get_bounty currently accepts only the internal bounty id, and list_bounty_attempts currently accepts only internal bounty_id. That forces agents to list/search bounties first before they can inspect a known bounty or its active attempts through MCP, even when they already know the GitHub issue number.
Evidence
Live MCP call get_bounty with arguments { "issue_number": 649, "repo": "ramimbo/mergework" } returned JSON-RPC error invalid tool arguments.
Current app/mcp_tools.py handles get_bounty with session.get(Bounty, positive_int_arg("id")) only.
Current app/mcp_tools.py handles list_bounty_attempts with positive_int_arg("bounty_id") only.
submit_work_proof already supports either bounty_id or issue_number, with optional repo scoping when using issue number, and returns a clear ambiguity error if issue-number lookup matches more than one bounty.
MCP get_bounty can look up a bounty by internal id or by GitHub issue_number plus optional repo.
Supplying both id and issue_number returns a clear invalid-argument error instead of guessing.
Ambiguous issue-number lookups return a clear error instead of guessing.
Existing internal-id behavior remains unchanged.
If list_bounty_attempts is included, it supports the same selector parity while preserving existing bounty_id behavior.
Docs show when to use internal id versus issue number.
No payout, proof, treasury, wallet, claim, or bounty acceptance behavior changes.
Evidence or tests required
Add focused MCP tool tests for get_bounty by internal id and by issue number plus repo.
Add tests for invalid combinations and ambiguous issue-number lookups.
Add or update tests for list_bounty_attempts if selector parity is included there.
Run existing MCP and bounty API tests to confirm current id-based behavior remains intact.
Duplicate search
I searched for existing issues using phrases including:
MCP issue_number get_bounty
get_bounty issue_number
internal bounty id issue number
MCP bounty issue number selector
I did not find an existing proposed-work item for MCP bounty lookup selector parity. Related but distinct work is #676, #688, #693, #708, #709, and #710 as described above.
Out of scope
No change to REST endpoint paths or public bounty ids.
No automatic guessing across multiple repos when issue numbers are ambiguous.
No changes to payout execution, proof creation, treasury proposals, wallet signatures, balances, ledger mutation, exchange, bridge, cash-out, private security handling, or fabricated paid-work status.
No private contact or private payment-channel behavior.
Problem
Agent workflows often start from a GitHub bounty issue number or issue URL, such as
#649, not from the internal MRWK bounty id. REST bounty rows expose both the internalidand GitHubissue_number, andsubmit_work_proofalready supportsissue_numberwith optionalreposcoping.MCP
get_bountycurrently accepts only the internal bountyid, andlist_bounty_attemptscurrently accepts only internalbounty_id. That forces agents to list/search bounties first before they can inspect a known bounty or its active attempts through MCP, even when they already know the GitHub issue number.Evidence
get_bountywith arguments{ "issue_number": 649, "repo": "ramimbo/mergework" }returned JSON-RPC errorinvalid tool arguments.app/mcp_tools.pyhandlesget_bountywithsession.get(Bounty, positive_int_arg("id"))only.app/mcp_tools.pyhandleslist_bounty_attemptswithpositive_int_arg("bounty_id")only.submit_work_proofalready supports eitherbounty_idorissue_number, with optionalreposcoping when using issue number, and returns a clear ambiguity error if issue-number lookup matches more than one bounty.649, while its public MRWK bounty row is internal bounty id96.Proposed work
Extend MCP bounty lookup selectors so agents can use the identifier they already have.
Suggested scope:
get_bountyto accept either:id, orissue_numberwith optionalrepo.submit_work_prooffor issue-number lookups.list_bounty_attemptswith the same selector parity, so active attempts can be queried by known bounty issue number.Expected value
submit_work_proof.Relationship to related proposals
Possible acceptance criteria
get_bountycan look up a bounty by internalidor by GitHubissue_numberplus optionalrepo.idandissue_numberreturns a clear invalid-argument error instead of guessing.list_bounty_attemptsis included, it supports the same selector parity while preserving existingbounty_idbehavior.Evidence or tests required
get_bountyby internal id and by issue number plus repo.list_bounty_attemptsif selector parity is included there.Duplicate search
I searched for existing issues using phrases including:
MCP issue_number get_bountyget_bounty issue_numberinternal bounty id issue numberMCP bounty issue number selectorI did not find an existing proposed-work item for MCP bounty lookup selector parity. Related but distinct work is #676, #688, #693, #708, #709, and #710 as described above.
Out of scope