Problem

The tool registry is mostly assembled from static Rust tool constructors and configured MCP bridge tools. Generated profile/runtime layers need a safe way to expose narrow capability tools without hardcoding each one in core or giving the agent a broad generic bridge.

Generic use case

A trusted profile, plugin, or compiler can register generated tools such as send_invoice, post_update, or run_report, each with its own schema and adapter, while hiding broad raw tools.

Managed-runtime use case

A compiled runtime contract can emit one tool per declared capability. The agent calls narrow tools such as send_message or web_search; policy maps each call to a capability id and adapter. Raw write-capable tools stay hidden.

Proposed shape

• Add a runtime/generated tool source alongside static tools.
• Each generated tool has name, description, JSON schema, risk/permission metadata, and adapter id.
• Generated tools dispatch through a generic adapter/policy layer, not arbitrary code by default.
• Make generation opt-in through config/profile.

Acceptance criteria

• Tests register a synthetic generated tool and execute it through the normal agent tool path.
• Tool visibility/whitelisting works with generated tools.
• Generated tools can be listed by existing tool-inspection surfaces.
• Default OpenHuman behavior is unchanged when no generated bundle is configured.

Alignment

This does not move away from Composio. It gives Composio-backed or MCP-backed actions a narrower, user-friendly capability surface when a profile/runtime wants that shape.