Torii MCP integration for AI agents.
Connect AI agents to Torii through 9 structured actions, including get app, get contract, and get organization. Review authentication, inputs, workflows, and…
- ACTION CONTRACTS
- 9
- AUTHENTICATION
- API key
- SOURCE STATUS
- Provider-backed
CATALOG SOURCE REVIEWED AUGUST 23, 2026 / ACTION NAMES AND SCHEMAS DERIVED FROM WORKING MACHINES PROVIDER SOURCE
CAPABILITY PROFILE
What the Torii integration exposes
The Torii Agent App exposes 9 provider-backed actions for productivity, finance, and security work. Its current contract lets an authorized agent retrieve one torii app by app identifier, retrieve one torii contract by contract identifier, and retrieve the torii organization profile for the current api key. These operations are called through Working Machines as typed capabilities rather than through browser navigation or copied UI steps.
A connection uses API key. Before execution, the agent can inspect the selected action, its required fields, declared scopes, and expected output contract. Provider credentials remain inside the Working Machines runtime; the calling agent receives the capability and its structured result, not the underlying secret.
For reliable operation, start with the narrowest action that satisfies the task, resolve stable provider identifiers before changing state, and validate the returned object or status after execution. Availability still depends on the connected Torii account, granted provider permissions, workspace policy, region, plan, and upstream API behavior.
VERIFIED ACTION SAMPLE
Real Torii capabilities.
Showing 9 of 9 actions. Risk labels are conservative signals based on operation names, not substitutes for provider documentation or runtime policy.
get_appREADRetrieve one Torii app by app identifier.
INPUTS: appId / fields / includeLicenses
get_contractREADRetrieve one Torii contract by contract identifier.
INPUTS: contractId / apiVersion / fields
get_organizationREADRetrieve the Torii organization profile for the current API key.
get_userREADRetrieve one Torii user by user identifier.
INPUTS: userId
list_appsREADList Torii apps with optional search, filters, and cursor pagination.
INPUTS: fields / q / sort / size / cursor
list_contractsREADList Torii contracts with optional API version, filters, and pagination.
INPUTS: apiVersion / fields / q / sort / size
list_transactionsREADList recognized Torii expense transactions with optional filters and pagination.
INPUTS: idApp / source / q / mappingStatus / sort
list_usersREADList Torii users with optional filters, search, and cursor pagination.
INPUTS: email / lifecycleStatus / isDeletedInIdentitySources / isExternal / firstName
list_workflowsREADList Torii regular workflows for the organization.
INPUTS: type
INPUT CONTRACTS
Know what the action needs before it runs.
get_app
appIdREQUIRED- The Torii app identifier.
fieldsOPTIONAL- A comma-separated list of fields to return.
includeLicensesOPTIONAL- Whether to include the aggregated license summary for the app.
get_contract
contractIdREQUIRED- The Torii contract identifier.
apiVersionOPTIONAL- The Torii contracts API version header to send.
fieldsOPTIONAL- A comma-separated list of fields to return.
get_user
userIdOPTIONAL- The Torii user identifier.
list_apps
fieldsOPTIONAL- A comma-separated list of fields to return.
qOPTIONAL- A free-text search query.
sortOPTIONAL- A comma-separated list of fields to sort by, suffixed with :asc or :desc.
sizeOPTIONAL- The maximum number of results to return.
cursorOPTIONAL- The Torii nextCursor value returned from the previous page.
PROVIDER-SPECIFIC WORKFLOWS
Jobs this Agent App can support
Inspect Get App
Retrieve one Torii app by app identifier. Use this as a bounded discovery step, retain the returned identifier, and avoid expanding the read beyond the task's stated scope.
get_appVerify with Get Contract
Retrieve one Torii contract by contract identifier. Compare the returned provider state with the intended outcome and preserve stable IDs or canonical links in the run record.
get_contractSAFETY BOUNDARY
Operate Torii with explicit limits
- Authorize Torii with API key and grant only the provider access required by the selected actions.
- The current action names appear read-oriented, but returned Torii data may still be sensitive and should be minimized before it enters model context.
- Do not infer permission from catalog visibility. Workspace policy, connection identity, and upstream authorization still govern execution.
- No provider scope string is declared on the sampled actions. Verify the connected account's actual permissions in Torii rather than assuming unrestricted access.
- After a call, inspect the structured result and execution record before reporting that the Torii task completed successfully.
CONNECTION MODEL
API key
Torii API key sent as a Bearer token in the Authorization header. Generate it in Torii Settings > API Access: https://app.toriihq.com/team/settings/apiAccess.
Working Machines stores provider credentials behind the execution boundary. An agent can use an authorized connection identity, but catalog discovery alone does not reveal OAuth tokens, API keys, or provider secrets.
- READ SIGNALS
- 9
- WRITE SIGNALS
- 0
- HIGH IMPACT
- 0
- REVIEW SIGNALS
- 0
EVIDENCE AND AVAILABILITY
Provider reference
Action names, input fields, authentication types, and counts on this page are generated from the Working Machines provider catalog. Provider behavior, quotas, object semantics, account eligibility, and regional availability remain governed by Torii.