Capabilities and contracts
Understand installed plugin capabilities and operation-specific schemas.
A plugin capability declares an operation and the configuration needed to run it. One installation can share connection settings across several capabilities; endpoint targets and node parameters remain operation-specific.
Contract roles
| Contract | Role |
|---|---|
install_config | Shared connection settings and protected credentials |
source_stream | Concrete read target, such as table, collection or path |
source_query | Connector-specific query configuration |
read | Declared read operation inputs |
write | Write target and operation settings |
ontology_fact_store | Materialization target for an official fact-store capability |
transform_params | Transform node parameters |
transform_inputs, transform_outputs | Named bindings |
mcp_tools | External MCP capability contract |
secret_resolution | Secret-provider resolution settings |
skill_instructions | Instruction-resource contract |
The published registry and custom authoring parser do not necessarily accept identical contract kinds. In particular, inspect validator support before building custom read-store-only packages; an official ontology_fact_store contract is not proof that the generic custom parser accepts it.
Schema fields
Configuration schemas use object properties and an object-level required list. Field types include string, number, integer, boolean, array and object. Defaults, enums, descriptions, nested properties, secret and multiline hints describe the editor and validation contract.
A secret hint identifies sensitive configuration; it does not prove every export or log is redacted. A declared default also does not configure an external service or supply a missing credential.
Capability and runtime kinds
Catalog capability kinds describe what the installation provides. Executable runtime declarations describe how to run it. For example a catalog connector can bundle runtime read and write capabilities; a catalog read_store uses a runtime fact materializer. Do not substitute one naming scheme for the other.
The core runtime exposes read, write, destination, tool, secret-provider, fact-materializer and skill interfaces within a multi-capability plugin. Implement the interface selected by the execution path and declare only supported operations.
Supported operations
Connection checks, discovery, projection, predicates, ordering, limits, write modes and recovery depend on the capability. A plugin with a write destination does not automatically support all governed source-write tools. Current durable source writes and governed action execution use the Iceberg adapter.
Internal setup guides link to their full published contracts. Inspect the actual installed version as the authority for configuration.
Read modes and discovery
A connector may declare full refresh, incremental reads, discovery depth and exactly-once behavior. Those declarations must match its executable implementation. An OAuth feature flag does not create an authorization flow on its own. The connection settings and target selectors remain distinct; inspect both before running a workflow.