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
'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
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 inproposes.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
IfcredentialModel 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
- Integration shape — full definition structure
- Tools — declare tools with classifications