Chorus MCP integration for AI agents.
Connect AI agents to Chorus through 6 structured actions, including get conversation, get current user, and get team. Review authentication, inputs, workflow…
- ACTION CONTRACTS
- 6
- 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 Chorus integration exposes
The Chorus Agent App exposes 6 provider-backed actions for communication and data work. Its current contract lets an authorized agent get a specific chorus conversation with optional populated fields, get details about the current chorus api token user, and get a specific chorus team by id. 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 Chorus account, granted provider permissions, workspace policy, region, plan, and upstream API behavior.
VERIFIED ACTION SAMPLE
Real Chorus capabilities.
Showing 6 of 6 actions. Risk labels are conservative signals based on operation names, not substitutes for provider documentation or runtime policy.
get_conversationREADGet a specific Chorus conversation with optional populated fields.
INPUTS: id / fields / forceRegeneration / skipSummaryGeneration / includeMeetingMetadata
get_current_userREADGet details about the current Chorus API token user.
get_teamREADGet a specific Chorus team by ID.
INPUTS: id
list_engagementsREADList Chorus engagements with documented v3 filters and continuation pagination.
INPUTS: compliance / continuationKey / dispositionConnected / dispositionGatekeeper / dispositionTree
list_scorecardsREADList Chorus scorecards with documented filters and page pagination.
INPUTS: recipientIds / reviewerIds / initiativeId / submittedRange / pageSize
list_teamsREADList Chorus teams visible to the connected API token user.
INPUT CONTRACTS
Know what the action needs before it runs.
get_conversation
idREQUIRED- The Chorus conversation ID to retrieve.
fieldsOPTIONAL- Chorus conversation fields to populate.
forceRegenerationOPTIONAL- Whether Chorus should regenerate the conversation from latest data.
skipSummaryGenerationOPTIONAL- Whether Chorus should skip summary generation.
includeMeetingMetadataOPTIONAL- Whether Chorus should include meeting metadata such as provider calendar ID and meeting URL.
get_team
idOPTIONAL- The Chorus team ID.
list_engagements
complianceOPTIONAL- Filter by Chorus call recording compliance flag.
continuationKeyOPTIONAL- The Chorus continuation_key returned by the previous page.
dispositionConnectedOPTIONAL- Filter by Chorus connected disposition.
dispositionGatekeeperOPTIONAL- Filter by Chorus gatekeeper disposition.
dispositionTreeOPTIONAL- Filter by Chorus phone tree disposition.
list_scorecards
recipientIdsOPTIONAL- IDs of Chorus users who were scored.
reviewerIdsOPTIONAL- IDs of Chorus users who completed scorecards.
initiativeIdOPTIONAL- The Chorus initiative ID that scorecards were completed against.
submittedRangeOPTIONAL- The submitted datetime range in Chorus format, such as 2021-01-01T00:00:00Z:2021-01-31T00:00:00Z.
pageSizeOPTIONAL- The number of scorecards to return per page. Chorus allows 1 to 100.
PROVIDER-SPECIFIC WORKFLOWS
Jobs this Agent App can support
Inspect Get Conversation
Get a specific Chorus conversation with optional populated fields. Use this as a bounded discovery step, retain the returned identifier, and avoid expanding the read beyond the task's stated scope.
get_conversationVerify with Get Current User
Get details about the current Chorus API token user. Compare the returned provider state with the intended outcome and preserve stable IDs or canonical links in the run record.
get_current_userSAFETY BOUNDARY
Operate Chorus with explicit limits
- Authorize Chorus with API key and grant only the provider access required by the selected actions.
- The current action names appear read-oriented, but returned Chorus 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 Chorus rather than assuming unrestricted access.
- After a call, inspect the structured result and execution record before reporting that the Chorus task completed successfully.
CONNECTION MODEL
API key
Chorus API token sent as the raw Authorization header value. Generate it from Personal Settings in the Chorus application after your role has API access.
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
- 6
- 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 Chorus.