An agent can only make good choices when it knows what actions are available. A generic list in documentation is not enough: the application may have enabled only a subset, the runtime may lack a capability, or a permission mode may rule out an action. SDK 0.3.2 adds a capability map grounded in the tools that actually reach a run.
Describe the run that exists, not the platform in theory
At the start of a run, the agent receives a compact outline of the active tool groups and their supported actions. If the application removes a tool, it disappears from that run's map. If a runtime cannot provide an action, the agent does not receive a promise that it can perform it. This keeps its planning closer to the real execution boundary.
One capability catalogue supports several decisions
The same catalogue can help the agent select an operation, direct it to the right documentation for usage details, and help developers see where a capability belongs. The summary answers what exists; the detailed reference explains how to call it. Separating those roles makes the initial map smaller and the follow-up explanation more targeted.
Coverage can be checked instead of remembered
A contract check compares methods exposed by SDK resources against the agent's tool source. Each method must be reachable through a tool or have a documented reason for staying out of reach. That makes an unconnected capability visible during development, instead of relying on someone to keep several hand-written lists synchronized.
This check is also a guard against accidental overreach. Some methods must remain outside the agent surface because they handle account authority or secrets; others are intentionally unavailable in a runtime. The catalogue can distinguish those deliberate boundaries from an omission.
A smaller map can still describe a broad SDK
The release measures agent access by actions rather than by the number of top-level tool names. One tool may represent many useful operations, and counting only names hides that breadth. A concise catalogue gives the model context without spending a long sequence of discovery calls before it can begin the task.
An agent should plan from the capabilities its run actually has, not from a brochure of everything the platform might support.
SDK 0.3.2 makes the boundary between the SDK and its agent loop easier to maintain: capabilities are described from the run's catalogue, and a contract check watches that the public resources and agent tools do not silently drift apart.
Frequently asked questions
Does the capability map enable every SDK operation?
No. It describes actions available to that particular run; application selection, runtime support and permission boundaries still apply.
How is the map different from API documentation?
It summarizes what the run can do. Detailed documentation explains how a supported operation works.
Why count actions instead of tool names?
A tool name can contain several operations, so action counts better describe the work an agent can perform.
Are sensitive operations automatically exposed?
No. Methods that require account authority or secrets can remain deliberately outside the agent surface, with the exclusion documented and checked.