Skip to main content
proposes is where you tell a reviewer what you believe is true about your integration. The reviewer confirms it during promotion — the human review your integration passes before it’s enabled for real accounts.

Basic proposal

credentialModel

What kind of credentials your integration uses. Undeclared fails closed — the workflow engine treats your tools as not machine-executable.
  • 'account' — credentials resolve at the account level (typical). Declaring it asserts that no handler reads a personal grant or a session client
  • 'user' — credentials or identity are personal to a user
  • 'source' — source-level credentials

scope

Optional. Your declared intent for whether activation is per user or per team. The host assigns the real value; a credentialModel: 'user' + scope: 'team' pairing is flagged as unusual.

Tool classifications

Optional per tool:
  • effect — 'read' (data fetch) or 'write' (modifies state)
  • sensitivity — what kind of data: public, internal, personally identifiable, or financial

Key requirement

Tool names in proposes.tools must match declared tool names exactly (the raw name, not the slug-prefixed one). A proposal for a tool you didn’t declare is a validation error — proposes.tools["<name>"] does not match any declared tool — so a rename cannot leave stale classifications behind. proposes is the only place these classifications go: credentialModel and per-tool effect/sensitivity declared anywhere else in the definition are rejected as unrecognized keys.

Review

A reviewer reads your proposals against your code during promotion to verify honesty. Marking a tool that moves money as 'read' to get past a gate is what promotion review exists to catch.

Workflow impact

If credentialModel is not declared, the workflow engine’s tool allowlist treats your tools as not machine-executable. A tool you believe is workflow-callable will not be until credentialModel is declared and confirmed at promotion:

Next steps