0xPlaygrounds
feat: mcp tools + bedrock
Merges https://github.com/0xPlaygrounds/rig/pull/213 and https://github.com/0xPlaygrounds/rig/pull/318 together. Refactored #318 to have a wrapper for the API
Hey, I appreciate all of the support in the issues and PRs. I understand there's a lot of excitement of getting MCP integrated with rig as it's something we are working on actively. It's very unlikely a PR this large will be able to get merged in as it touches wayy too many aspects of the code and bundles too many features for it to reasonable be reviewed in a timely manner.
However, I think there's a lot of good work and ideas here and I'll see if there's a way we can re-leverage the work put here so I'll take some time to study the efforts presented here. I'll also get a milestone / epic going that details the planned tool rework and mcp additions so that there's a clear POV presented to the wider rig community.
It's very unlikely a PR this large will be able to get merged in as it touches wayy too many aspects of the code and bundles too many features for it to reasonable be reviewed in a timely manner.
To be honest there's not that much, just code duplication because of different providers. I can establish a list of the different changes I made here. Or arrange a call to explain in detail why I think they're important.
It's a bit frustrating because I've had a PR open for multiple of these changes since December..
I think the MCP is a good idea to have an in-house tool but in the meantime, why not merge my additions? It's not invasive at all and I'm sure a lot of people need them as they're getting very popular
Closing as this PR has been superceded by #335 and #318 (and for merge hygiene purposes, it'll be better to work from a fresh branch if any new work needs to be done).
It's unfortunate that we weren't able to merge any of your PRs purely due to multiple people trying to submit the same PR at the same time. We'll be implementing a policy in future to ensure that contributors can clearly own pieces of work to avoid this from happening again (and create a re-assignment policy for when the assigned contributor is unable to work on it) - a bit late in hindsight, but better now than never :sweat_smile:
