# IaGenify SDK 0.3.2 gives agents a map of the tools they can use.

Canonical URL: https://www.iagenify.com/news/iagenify-sdk-agent-capability-catalogue

Agent instructions are now grounded in the actual tools and actions enabled for a run, so the model can choose from a current capability map instead of guessing from generic documentation.

## Key points
- The agent receives a compact inventory of capabilities available in its current run.
- The inventory reflects the tools the application actually enabled, including mode and runtime limits.
- A contract check compares SDK resource methods with agent tool coverage or an explicit reason for exclusion.

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.

## FAQ
### 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.