Three Registries, One Screen: What Your Agent Can Actually Do
Why 'what can this agent do' has three different, honest answers in Piskes, and where to find all three on one screen instead of guessing.
"What can this thing actually do?" is the single most common question about any agent product — and it's also, for most products, a question with no clean answer, because the honest response depends on which layer you're asking about. Piskes's Capabilities screen exists specifically to stop making you guess.
Three sources of truth, shown separately on purpose
Built-ins are the tools wired directly into the agent runtime — things like reading a web page or running a calculation. Crucially, what shows up here is measured live from the worker's own environment, not read off a hardcoded list somewhere in the frontend. That distinction matters: a hardcoded list can claim a capability that a given deployment doesn't actually have a working binding for. Measuring from the runtime's own env means this screen never promises a tool the model isn't actually being offered in that session.
Capabilities are the broader platform capability registry — everything the platform as a whole knows how to do, whether or not it's included in the specific pack your current agent is running. Both the ones inside your pack and the ones outside it are shown, and the ones outside are labeled as such rather than simply hidden. That labeling is the point: "the platform cannot do that" and "this chat cannot do that" are two different, both-true-somewhere statements, and conflating them is exactly what leaves people guessing.
MCP servers are the connections you've made yourself — per-person, not per-workspace. Connecting one is an OAuth round trip that takes you off this screen and back. What's shown here is split the same way: the catalogue of servers the platform has vetted, and the ones you've actually connected, because those are two different facts too.
Why splitting them is the actual design decision
It would be simpler to merge all three into one flat "here's what I can do" list. It would also be dishonest, because the three layers fail in three different ways. A built-in can be missing because this particular deployment lacks a binding. A capability can be real on the platform but excluded from your current pack. An MCP server can be vetted by the platform but never connected by you. Collapsing those into one list would hide which of those three reasons explains any given gap — and "why can't it do that" is a much more useful question to be able to answer precisely than to wave away.
Using it
If you're ever unsure whether your agent can do something, the Capabilities screen is a more reliable answer than asking the agent directly and trusting whatever it says back. Check which of the three sections the thing you want lives in: if it's a built-in that's missing, that's a deployment question; if it's a capability outside your pack, that's a pack-configuration question; if it's an MCP server you haven't connected, that's a you-need-to-connect-it question. Three different problems, three different fixes — which is exactly why the screen keeps them apart.