Project Name
MCP Tools
Project Description
The MCPTools project is a community-governed set of projects whose common goal is to make MCP development and data integration easier, more secure and trustable, more innovative, and more productive for both individual and teams of developers.
The project currently has an organization and multiple repos at OpenMCPTools. Several of the existing repos exemplify where the organization is headed:
Experimental MCP Protocol Enhancements
-
Hierarchical ToolGroups for MCP Server Tools. Toolgroups provide a way for MCP server and gateway builders to structure, secure, persist, and organize model/client access to the MCP tools. The same functionality is already implemented in Typescript and Java, allowing interoperability between MCP clients and servers implemented in different languages. The toolgroups project is led by Scott Lewis, a 20-year maintainer of the Eclipse IDE and ECF project lead.
-
Jref serialization. Currently, json serialization libraries (e.g. Zod, Pydantic, Jackson) do not use or support json pointers. This means that protocols like MCP (which is based upon json serialization/jsonrpc 2.0) can be very inefficient when serializing object graphs, since each object reference results in a full object copy when serialized. With toolgroups, for example, one group could contain references to many tools, meaning that the meta-data of the group would be duplicated on the client<->server stream. Such duplication can result in very inefficient communication of object graphs. With jref serialization, only the first reference serialized, and all other group references use json pointers effectively reducing the data exchanged betwee MCP clients and servers. The jref projects (currently Typescript and Python) are led by Jason Derosiers, a participant in json schema standaridzation.
-
MCP Protocol Extension for Dynamic Tool Update. The MCP protocol does not currently support incremental updates of tool meta-data. This protocol extension allows dynamic server-initiated tool updates without introducing new MCP protocol (built on existing jsonrpc notifications).
-
Open APIs and Frameworks - A popular way for developers to create MCP tool definitions is to use annotations. Currently, the MCP Java SDK uses annotations types that are from the Spring AI project. These annotations are not open for general use by the developer community. This OpenMCPTools project provides these annotations for any tools or frameworks builders. This project, and this project also provide open source APIs that are not bound to any framework or tool provider, but rather provide framework (and model, and language) agnostic support for tool builders and general agentic development.
Additional Tools and Integrations
There are other projects started to
-
Provide IDE integration for Agentic tools.
-
Provide MCP Server-Side frameworks like Vurb.ts. The author of this framework, Renato Marinho is already a contributor to the OpenMCPTools organization, and could be interested in contributing much of this work and other projects to AAIF projects.
The overall approach for all OpenMCPTools projects is that they are for ultimate consumption by human developers. The ultimate destination of the project (e.g. open standard/spec, part of some framework or service infrastructure, or an ongoing/maintained open source project) is up to the collective desires of the development community.
Alignment with AAIF Mission
The overall purpose of all OpenMCPTools projects is to have developer-driven and collaborative creation of innovative open source MCP protocol enhancements, frameworks, and tools. Scott has been a project lead with the Eclipse Foundation and the OSGi Alliance for 20+ years, and so is very experienced in transparent, high-quality, community-driven open source API, framework, and tools development. He is also familiar with dealing with continuous developer-community input and producing plans and releases that are continuously responsive to developer's actual needs.
Such open, community-driven, developer led innovation and framework+tools generation seems well-aligned with the AAIF mission.
Relation to Existing AAIF Projects
Many of the existing efforts at OpenMCPTools were informed directly by MCP dev community input. For toolgroups, for example, see here and here.
The Jref work at OpenMCPTools is focused on efficient serialization for MCP by leveraging the json pointer specification with json-schema defined protocols (e.g. MCP).
This project could easily grow beyond MCP-specific work, however. e.g. higher-level tool integration, and dev-community-driven tools innovation. One area high potential for innovation, for example, is developer team coordination and collaboration that includes agents and multiple distributed human team members.
Example Use Cases and Evidence of Adoption
Use cases for toolgroups was publicly discussed with developers as referenced above and here
Technical Committee Sponsor (if identified)
No response
GitHub Repository URL
https://github.com/OpenMCPTools
License
Apache 2.0
Governance Model
Autonomous, community-driven, collaborating open source projects. Open/public project plans, public communication, flat project and governance structure.
My personal project governance ideal is represented by the original Eclipse Development Process. I was a committer Board member at the Eclipse Foundation when this was written.
CI/CD & Release Workflow
The projects at OpenMCPTools are very new, and we are setting up automated testing and deciding upon release schedules.
I (Scott) have personally managed the ECF project CI/CD system for > 15 years, with an average release schedule of ~4 times per year. The ECF project has been a member of the Eclipse Simultaneous Release for ~18 years now, without a single missed or delayed release. Our most recent release (3.16.7) was today 4/7/2026.
Public-Facing Contribution Process for Specifications
All specification-relevant efforts (e.g. toolgroups support -> MCP, jref -> json schema serialization) would be contributed via the org-appropriate process...e.g. via contribution to the MCP SDKs, or contribution via SEP/standardization would be accommodated appropriately. The decision for distribution of work (whether specs, or code, or both) would be left up to the developer consumer community.
Publicly Accessible Issue Tracker
Each repo at https://github.com/OpenMCPTools has it's public issue tracker.
External Project Dependencies
There are dependencies in the OpenMCPTools projects on the MCP typescript, python, and java sdks, but otherwise there are currently no other dependencies. Part of the intention of OpenMCPTools is to make available to developers tools, frameworks, extensions, etc that have no/as few as possible external dependencies. I've learned the importance of few dependencies in my years and ECF project lead.
Maintainers & Contributors
Renato Marinho
Scott Lewis
Jason Derosiers
The organization is very new (3 months) and so doesn't yet have 10 contributors. I continuously recruited ECF community contributors...a total of ~50 over 20 years, and will do so with OpenMCPTools and/or an AAIF project.
Leadership Team & Decision Process
Current Leadership Team
Renato Marinho
Scott Lewis
Jason Derosiers
The decision processes...for example adding new maintainers, will be done by existing committer/maintainer vote. This approach...from the Eclipse Development Process linked to above...has worked successfully for the ECF project (and all Eclipse projects) for a very long time. All project-level decisions will be publicly discussed and public commitments (e.g. on-time releases) followed through.
Roadmap
I don't have a 12-month roadmap yet.
Security
The ECF project has been successfully and securely providing releases as part of the Eclipse Simultaneous Release for 18+ years. We've followed all the community and Foundation-level best practices.
Website URL
https://github.com/OpenMCPTools
Documented Governance Practices (if any)
Eclipse Development Process is the closest thing at this point. Project-level autonomy, continuous innovation, release on time with high quality, listen to the community.
Links to Social Media Accounts
https://www.linkedin.com/in/scottlewis4/
Details of Existing Financial Sponsorship
None so far. Part of the idea of OpenMCPTools is not to be bound to existing infrastructure, frameworks, or tools businesses, but rather be focused on the developer community.
Infrastructure Needs or Requests
Although build/test/CI/CD systems....and AI model usage/evaluation costs...are helpful and would be appreciated, direct support for maintainers and contributors time is more necessary.
Additional Information
Scott has publicly clashed with the MCP lead core maintainer over the current BDFL governance model and it's lack of democratic principles for decision making around technical priorities. BDFM...along with no democratic conflict resolution process...does not lead to welcoming contributions from the developer community, but rather to stifling of community innovation and contribution.
Project Name
MCP Tools
Project Description
The MCPTools project is a community-governed set of projects whose common goal is to make MCP development and data integration easier, more secure and trustable, more innovative, and more productive for both individual and teams of developers.
The project currently has an organization and multiple repos at OpenMCPTools. Several of the existing repos exemplify where the organization is headed:
Experimental MCP Protocol Enhancements
Hierarchical ToolGroups for MCP Server Tools. Toolgroups provide a way for MCP server and gateway builders to structure, secure, persist, and organize model/client access to the MCP tools. The same functionality is already implemented in Typescript and Java, allowing interoperability between MCP clients and servers implemented in different languages. The toolgroups project is led by Scott Lewis, a 20-year maintainer of the Eclipse IDE and ECF project lead.
Jref serialization. Currently, json serialization libraries (e.g. Zod, Pydantic, Jackson) do not use or support json pointers. This means that protocols like MCP (which is based upon json serialization/jsonrpc 2.0) can be very inefficient when serializing object graphs, since each object reference results in a full object copy when serialized. With toolgroups, for example, one group could contain references to many tools, meaning that the meta-data of the group would be duplicated on the client<->server stream. Such duplication can result in very inefficient communication of object graphs. With jref serialization, only the first reference serialized, and all other group references use json pointers effectively reducing the data exchanged betwee MCP clients and servers. The jref projects (currently Typescript and Python) are led by Jason Derosiers, a participant in json schema standaridzation.
MCP Protocol Extension for Dynamic Tool Update. The MCP protocol does not currently support incremental updates of tool meta-data. This protocol extension allows dynamic server-initiated tool updates without introducing new MCP protocol (built on existing jsonrpc notifications).
Open APIs and Frameworks - A popular way for developers to create MCP tool definitions is to use annotations. Currently, the MCP Java SDK uses annotations types that are from the Spring AI project. These annotations are not open for general use by the developer community. This OpenMCPTools project provides these annotations for any tools or frameworks builders. This project, and this project also provide open source APIs that are not bound to any framework or tool provider, but rather provide framework (and model, and language) agnostic support for tool builders and general agentic development.
Additional Tools and Integrations
There are other projects started to
Provide IDE integration for Agentic tools.
Provide MCP Server-Side frameworks like Vurb.ts. The author of this framework, Renato Marinho is already a contributor to the OpenMCPTools organization, and could be interested in contributing much of this work and other projects to AAIF projects.
The overall approach for all OpenMCPTools projects is that they are for ultimate consumption by human developers. The ultimate destination of the project (e.g. open standard/spec, part of some framework or service infrastructure, or an ongoing/maintained open source project) is up to the collective desires of the development community.
Alignment with AAIF Mission
The overall purpose of all OpenMCPTools projects is to have developer-driven and collaborative creation of innovative open source MCP protocol enhancements, frameworks, and tools. Scott has been a project lead with the Eclipse Foundation and the OSGi Alliance for 20+ years, and so is very experienced in transparent, high-quality, community-driven open source API, framework, and tools development. He is also familiar with dealing with continuous developer-community input and producing plans and releases that are continuously responsive to developer's actual needs.
Such open, community-driven, developer led innovation and framework+tools generation seems well-aligned with the AAIF mission.
Relation to Existing AAIF Projects
Many of the existing efforts at OpenMCPTools were informed directly by MCP dev community input. For toolgroups, for example, see here and here.
The Jref work at OpenMCPTools is focused on efficient serialization for MCP by leveraging the json pointer specification with json-schema defined protocols (e.g. MCP).
This project could easily grow beyond MCP-specific work, however. e.g. higher-level tool integration, and dev-community-driven tools innovation. One area high potential for innovation, for example, is developer team coordination and collaboration that includes agents and multiple distributed human team members.
Example Use Cases and Evidence of Adoption
Use cases for toolgroups was publicly discussed with developers as referenced above and here
Technical Committee Sponsor (if identified)
No response
GitHub Repository URL
https://github.com/OpenMCPTools
License
Apache 2.0
Governance Model
Autonomous, community-driven, collaborating open source projects. Open/public project plans, public communication, flat project and governance structure.
My personal project governance ideal is represented by the original Eclipse Development Process. I was a committer Board member at the Eclipse Foundation when this was written.
CI/CD & Release Workflow
The projects at OpenMCPTools are very new, and we are setting up automated testing and deciding upon release schedules.
I (Scott) have personally managed the ECF project CI/CD system for > 15 years, with an average release schedule of ~4 times per year. The ECF project has been a member of the Eclipse Simultaneous Release for ~18 years now, without a single missed or delayed release. Our most recent release (3.16.7) was today 4/7/2026.
Public-Facing Contribution Process for Specifications
All specification-relevant efforts (e.g. toolgroups support -> MCP, jref -> json schema serialization) would be contributed via the org-appropriate process...e.g. via contribution to the MCP SDKs, or contribution via SEP/standardization would be accommodated appropriately. The decision for distribution of work (whether specs, or code, or both) would be left up to the developer consumer community.
Publicly Accessible Issue Tracker
Each repo at https://github.com/OpenMCPTools has it's public issue tracker.
External Project Dependencies
There are dependencies in the OpenMCPTools projects on the MCP typescript, python, and java sdks, but otherwise there are currently no other dependencies. Part of the intention of OpenMCPTools is to make available to developers tools, frameworks, extensions, etc that have no/as few as possible external dependencies. I've learned the importance of few dependencies in my years and ECF project lead.
Maintainers & Contributors
Renato Marinho
Scott Lewis
Jason Derosiers
The organization is very new (3 months) and so doesn't yet have 10 contributors. I continuously recruited ECF community contributors...a total of ~50 over 20 years, and will do so with OpenMCPTools and/or an AAIF project.
Leadership Team & Decision Process
Current Leadership Team
Renato Marinho
Scott Lewis
Jason Derosiers
The decision processes...for example adding new maintainers, will be done by existing committer/maintainer vote. This approach...from the Eclipse Development Process linked to above...has worked successfully for the ECF project (and all Eclipse projects) for a very long time. All project-level decisions will be publicly discussed and public commitments (e.g. on-time releases) followed through.
Roadmap
I don't have a 12-month roadmap yet.
Security
The ECF project has been successfully and securely providing releases as part of the Eclipse Simultaneous Release for 18+ years. We've followed all the community and Foundation-level best practices.
Website URL
https://github.com/OpenMCPTools
Documented Governance Practices (if any)
Eclipse Development Process is the closest thing at this point. Project-level autonomy, continuous innovation, release on time with high quality, listen to the community.
Links to Social Media Accounts
https://www.linkedin.com/in/scottlewis4/
Details of Existing Financial Sponsorship
None so far. Part of the idea of OpenMCPTools is not to be bound to existing infrastructure, frameworks, or tools businesses, but rather be focused on the developer community.
Infrastructure Needs or Requests
Although build/test/CI/CD systems....and AI model usage/evaluation costs...are helpful and would be appreciated, direct support for maintainers and contributors time is more necessary.
Additional Information
Scott has publicly clashed with the MCP lead core maintainer over the current BDFL governance model and it's lack of democratic principles for decision making around technical priorities. BDFM...along with no democratic conflict resolution process...does not lead to welcoming contributions from the developer community, but rather to stifling of community innovation and contribution.