This may be solved already, but I’m looking at Claude waste compute guessing it’s way around what field names will return the desired info and that reminded me that fibery.schema/query returns the whole workspace.
Can we allow query parameters so we only get a specific space or database (type)?
Plus a parameter to only return spaces + databases the user/ai agent has access to in one way or another would be nice. I think it’s related to this, but can split into a separate request if you think it’s different.
Yeah, this would help a lot for tooling.
Right now if you just need one space or one type, fibery.schema/query makes you pull the whole workspace schema and then filter client-side. That is fine once, but it gets wasteful fast for MCP/codegen flows where the model keeps re-reading schema just to resolve a couple field names.
Even a narrow filter like space, type, or a small include/exclude list would be enough. It would cut token usage, reduce round-trips, and make schema diffing a lot cleaner.
The schema is public, so this is not really possible - there’s a difference between which entities the AI (or any user) is permitted to see, and knowing what fields each of the databases has or what space they live in.
yet!
If you have a lot of spaces, but you only give editor access to one space to an AI, it wastes a lot of tokens. Hence, still stay public, but allow a parameter for “only ones I have access to” or something.
I’m not sure how this could reasonably work:
If you are suggesting that it be possible to pass a parameter to the getSchema query identifying a specific user, with the aim that the response would be limited, it would seem to imply that, behind the scenes, when Fibery receives such a query it has to dynamically query every database in every space in order to determine if this user has any access to one or more entities in the db. This would imply a massive set of subqueries, so although it would limit the size of the schema info returned to the AI, it would put a serious load on Fibery.
I think @helloitse’s suggestion of parameterising the query to only return specific spaces/dbs is plausible, but a per-user schema response is very unlikely.
As it happens, I suspect that the cost of AI tokens will go down, and context windows will go up, such that returning the whole schema becomes not such a big deal rather soon. Plus, the models will become ‘smarter’ at not re-requesting it.
I think it makes little sense for Fibery devs to work on optimisations when AI improvements will likely have a greater effect, sooner.
Just to be clear,
AI is not the best use case for this request. It’s a good one and a popular one.
But the request exists because I’ve spent years lightly irritated at having to sort through the large payload of a whole workspace when you need the configuration of one database or space. Most of us have built our parsing process for our dev environments and AI haven’t.
It’s preferable not to have to cache the workspace config or download the whole thing each time to later parse. That’s the request.
AI compute/costs were just a reminder of this longstanding issue.