Thread

M
matthew.gregor1:21 AMOpen in Slack
Any thoughts towards making a search tool type tool available in the same context of getmcpservertools? When using a 3rd party agent to assist in building an app, there's no easy way for it to find available tools for the app without calling getmcpservertools which can be massively context heavy.
Unless someone's found a better way to do it?

13 replies
X(
Xavier (archestra team)12:09 PMOpen in Slack
We do have search_tools, but you need to turn on progressive tool loading on your gateway
M
matthew.gregor12:11 PMOpen in Slack
That only searches the tools available to the gateway, not the user. I was testing out using Claude cowork or desktop to create archestra apps. There's no way for Claude desktop to see what tools are available to the user unless they use the getmcpserver_tool, or you make every tool available to the gateway being accessed via Claude
M
matthew.gregor12:14 PMOpen in Slack
If I understand correctly, apps don't require a gateway and use the users available tools from every mcp server available to them, even if they are disabled on every agent and gateway they have access to?
👀1
M
matthew.gregor12:14 PMOpen in Slack
I think you guys should look at RBAC on tools at the mcp layer rather than the gateway and agent layer, but that's another thing
IK
Innokentii Konstantinov (archestra team)12:27 PMOpen in Slack
I think you guys should look at RBAC on tools at the mcp layer rather than the gateway and agent layer, but that's another thing
Hi! Could you elaborate on that? Always happy to hear another point of view
M
matthew.gregor12:45 PMOpen in Slack
From what I can see, if a user has access to a mcp server, it has access to every tool of that server.
The auth check is done at the agent or gateway by making the tool available. There isnt a way for me to be able to restrict a users access to a limited subset of tools on an mcp server without restricting their ability to create apps, gateways and agents, and preconfiging gateways and agents for them?
An example is we use a microsoft graph mcp server, i may not want user to be able to send emails using the mcp server, but might want user b to be able to. With gateways and agents being the gate, I have to prevent user a from being able to create their own gateways and agents.
There's also that I'm pretty sure they could just create an app that accesses the send email tool on their behalf.
M
matthew.gregor12:47 PMOpen in Slack
I was sort of hoping to do it with openappa. Either being able to say this role can't use these specific tools, (was hoping to do it for agents too)
IK
Innokentii Konstantinov (archestra team)12:48 PMOpen in Slack
It's possible to create to different mcp gateways with different set of tools, e.g. gateway A has sendemail tool and gateway B has only reademail
IK
Innokentii Konstantinov (archestra team)12:50 PMOpen in Slack
But that's all very valuable feedback, cc @user
M
matthew.gregor12:52 PMOpen in Slack
Yes, we do that, but we are wanting more people to build in archestra using apps rather than Claude artifacts. We found when we started moving people that direction we lost some of our access granularity as their tool access is the entire server rather than the subset we gave through the gateway
J(
joey (archestra team)1:59 PMOpen in Slack
hi there @user 👋 nice to meet you
J(
joey (archestra team)2:03 PMOpen in Slack
I'll throw a different idea in here - wouldn't you want to manage this authz in the "source system" authorization server?
so in your example of the microsoft graph mcp server, entra (I imagine)
J(
joey (archestra team)2:04 PMOpen in Slack
are you already doing some form of authz inside entra for using these microsoft graph apis?