Hi Vaquar -
I've taken a look at the repo and think you have identified an interesting
scope for data services and MCP.
I would like to discuss the technical direction for this work.
At this point, it seems that the project is essentially creating an uber
MCP Server that includes a separate set of tools and resources for each
data service built directly into the project.
There are a couple challenges with this approach:
1. Scaling to keep up with any and all changes made to the service APIs
across the release trains of multiple projects.
2. Very real possibility of the data services creating their own MCP
Servers that we would need to compete with or duplicate and track, etc.
My recommendation is to concentrate on the pure governance and security
aspects of using MCP Servers in an enterprise setting with things like:
1. MCP Server Proxy - discover and integrate MCP Servers via the MCP
protocol itself as the primary target
* configuration based integration rather than code
2. Break glass alternative for creating an MCP Server for services where
one doesn't exist
* possible "mashup" MCP Servers for interesting combinations of other
MCP Servers
3. OAuth Discovery and Identity concerns for delegated agentic auth and
proper attribution to address agentic identity challenges with MCP Servers
4. Agentic Authorization - providing fine grained access at the tool and
resource level rather than the server level for federated/delegated
identities
5. MCP Server Catalog for user level discovery API and UI
Note that I have thought through some of the above but not all of the
above. :)
These are traditional gateway features that will remove the burden of
having to maintain bespoke integrations with each service independently.
They also generically add value to any MCP Server ecosystem whether in the
data platform or any other.
What are your thoughts on this take?
thanks,
--larry
On Sun, Aug 9, 2026 at 10:06 AM larry mccay <[email protected]> wrote:
> > And for anybody at the ASF who *has*
> > implemented an MCP, or *intends* to implement an MCP, to at least give
> this
> > proposal a once-over.
>
> I failed to mention that I have created a couple MCPs as well as a POC of
> Knox as an MCP Gateway. :)
>
> On Sat, Aug 8, 2026 at 10:25 PM Justin Mclean <[email protected]>
> wrote:
>
>> Hi,
>> ,
>> > I wanted to say a word on project governance. Specifically, how can we
>> > ensure that individuals who are already PPMC members across multiple
>> > projects don't monopolize leadership roles here?
>> >
>> > Are there any existing quotas, guidelines, or best practices regarding
>> the
>> > number of projects someone can be involved in as a committer or PPMC
>> > member?
>>
>> I suggest you take a look at these documents on mentors:
>> https://cwiki.apache.org/confluence/x/cQqRFw
>> https://cwiki.apache.org/confluence/x/cwqRFw
>>
>> Re (P)PMC or committers, there are no real limits or advice that I’m
>> aware of.
>> A few reasons why:
>>
>> Committer and PPMC roles are not a fixed pool of seats. Adding one person
>> doesn't prevent adding another. If several experienced contributors are
>> eager to step up, the answer is to invite all of them, not to ration roles
>> among them.
>>
>> The ASF works on merit within each project. Merit is earned per project
>> and doesn't carry over, so someone being on five other PPMCs gives them no
>> standing here beyond what they've contributed. Equally, it doesn't count
>> against them.
>>
>> People involved in many projects are usually a benefit, not a problem.
>> They bring experience of how other communities handle releases, votes and
>> governance, which is exactly what a new project needs.
>>
>> If your concern behind your question is capacity: can someone spread
>> across many projects give this one enough attention? That varies widely and
>> on a case-by-case basis.
>>
>> Kind Regards,
>> Justin
>>
>>
>>
