---title: "Tool Catalog And Execution"description: "How source materialization becomes callable tools and how invocation works."--- Executor turns connected integrations into a workspace tool catalog. That catalog is the thing the runtime actually executes against. The execution sandbox is selected from `.executor/executor.jsonc`: ```jsonc{  "runtime": "quickjs"}``` Supported values are `quickjs` (default), `ses`, and `deno`. ## How tools are produced At a high level: 1. an adapter materializes a source2. the materialization writes documents, schema bundles, and operations3. the control plane loads those persisted operations into a workspace tool index4. the runtime invokes one tool at a time through the control plane This means executor does not rebuild every integration from scratch on every execution. ## Why operations exist as a separate layer The operation layer exists to support: - search- inspection- policy- fast tool lookup- tool description without loading huge raw documents every time Raw upstream documents are still kept, but they are not the best hot-path query surface. ## Schema transport Executor uses compact operation-root schemas plus shared schema bundles. This is better than storing expanded per-tool schema blobs because it avoids: - massive duplicate schema payloads- slow formatting and rendering- treating presentation output as canonical storage The result is: - smaller payloads- more reusable schema graphs- cleaner tool detail responses ## Tool catalog shape The tool catalog is built from: - persisted source tools- built-in executor tools That lets executor present one unified discovery and invocation surface even though the underlying tools come from different places. ## Invocation flow At a high level, invocation works like this: 1. resolve the persisted operation by tool path2. run policy and approval checks3. resolve auth material for the correct slot4. load the manifest and schema bundle needed for the call5. delegate actual invocation to the adapter This is the key point: - the control plane orchestrates- the adapter performs the protocol-specific call ## Why this is flexible This architecture is flexible because it keeps a stable middle: - the runtime only needs tools and invokers- the control plane only needs the canonical operation and auth model- adapters can vary widely at the source boundary without changing the runtime contract That is what makes it possible to add more source types without constantly rewriting execution logic.