Tool Catalog

Beta

The tool catalog is in beta. It is a point-in-time snapshot of the integration inventory, so an entry can differ from what your organization sees in product. Confirm availability in the agent’s tool configuration, and tell your Kindo representative if something here looks wrong.

A Kindo agent acts through tools. This catalog lists the tools an agent can be granted: the 123 integrations Kindo ships, the 2,368 tools they expose, and the built-in tools that need no integration at all.

Which of these an agent can actually call is set per agent and per user group. See Tool Action Access Controls for how access is scoped, and Integrations Setup for how connections are configured.

How tools are named

Once an integration is connected, each of its tools is exposed to the agent under a fully qualified name: the integration prefix, an underscore, then the tool name. The GitHub integration’s list_pull_requests tool reaches the agent as github_list_pull_requests. The catalog pages list these fully qualified names.

An integration can be connected in more than one way. Microsoft Entra ID, for example, offers delegated OAuth, application credentials, and GCC High variants of each. Each variant is a separate connection with its own credentials, which is why 123 integrations yield 159 connectable entries.

The prefix comes from the connection, not from the integration, so each variant prefixes its tools with its own identifier. Jira Data Center’s tools arrive as jira-data-center-basic_*, not jira_*. The catalog lists each integration’s tools once, under its primary connection’s prefix; if you connect through another variant, expect that variant’s prefix on the same tool names.

Platform tools follow the same rule under the platform prefix, so get_conversation reaches the agent as platform_get_conversation. Most built-in tools carry no prefix at all: the agent sees file_read and shell_exec. The exception is platform_search_docs, which is a built-in despite the prefix — it is listed with the built-ins below, not with the platform tools. The kindo_-prefixed spellings below are the request-side type values used by the Responses API, not the names an agent, transcript, or approval card shows.

Integrations by category

Threat detection and response32 integrations, 645 tools.

Engineering and code10 integrations, 309 tools.

Vulnerability and exposure19 integrations, 281 tools.

Identity and secrets10 integrations, 274 tools.

Cloud and infrastructure16 integrations, 255 tools.

Service and incident6 integrations, 214 tools.

Workplace16 integrations, 202 tools.

Data and records11 integrations, 185 tools.

Business systems3 integrations, 3 tools.

Built-in tools

These tools need no integration. Granting one in an agent’s configuration is necessary but not sufficient: almost every built-in also depends on how your deployment is set up, so read the Requires column alongside the tool.

Tool	Responses API type	Description	Requires
library_list	—	List the files in the Kindo file library, with the content IDs the download tools take.	Nothing further
shell_exec	kindo_shell	Run a shell command in the agent’s sandbox.	A configured sandbox provider
file_read	kindo_file_read	Read a file in the sandbox workspace.	A configured sandbox provider
file_write	kindo_file_write	Write a file in the sandbox workspace.	A configured sandbox provider
file_list	kindo_file_list	List the workspace’s files.	A configured sandbox provider
web_download	kindo_web_download	Download a URL into the workspace.	A configured sandbox provider
files_download_original	kindo_files_download_original	Fetch an uploaded file in its original form.	A configured sandbox provider
files_download_as_text	kindo_files_download_as_text	Fetch an uploaded file converted to text.	A configured sandbox provider
file_share_with_user	kindo_file_share_with_user	Hand a workspace file back to the user.	A configured sandbox provider
browser_control	kindo_browser_control	Drive a headless browser session.	A sandbox provider, and browser automation enabled for the org
browser_screenshot	kindo_browser_screenshot	Capture the browser viewport.	A sandbox provider, and browser automation enabled for the org
browser_list_network_requests	kindo_browser_list_network_requests	List the requests the page made.	A sandbox provider, and browser automation enabled for the org
browser_export_request_as_curl	kindo_browser_export_request_as_curl	Export one captured request as curl.	A sandbox provider, and browser automation enabled for the org
mint_upload_url	—	Mint a short-lived signed upload URL for the integration tools that write files.	A configured sandbox provider
search	kindo_web_search	Search the web.	Web search enabled for the org
knowledge_store_search	kindo_knowledge_store_search	Search the org’s knowledge store.	Knowledge Store enabled, with documents attached to the conversation
vpn_connect	kindo_vpn_connect	Attach the sandbox to a customer network.	Kindo-hosted deployments, with VPN tools enabled for the org
vpn_disconnect	kindo_vpn_disconnect	Detach the sandbox from that network.	Kindo-hosted deployments, with VPN tools enabled for the org
platform_search_docs	—	Search Kindo’s documentation for product and platform guidance.	Kindo docs search enabled for the deployment, and not a whitelabeled deployment

Platform tools

Tools an agent uses to read and drive Kindo itself, rather than an external system. Unlike the built-ins above, these arrive together when the Platform server is selected.

Tool	Description
platform_list_conversations	Discover accessible conversations by title, agent, and ownership scope.
platform_get_conversation	Read a conversation’s messages and tool calls.
platform_get_agent_conversation_metadata_schema	Read an agent’s chat structured-metadata schema, if one is configured.
platform_search_agent_conversation_metadata	Search an agent’s conversations by chat structured-metadata fields.
platform_get_conversation_metadata	Read one conversation’s complete chat structured-metadata document.
platform_patch_conversation_metadata	Apply set/remove changes to one conversation’s chat structured-metadata document.
platform_get_agent_run	Read a run’s timeline, separate run/turn/step states, or complete text with continuation.
platform_list_agents	List the agents the caller can see.
platform_view_agent_configuration	Read an agent’s configuration summary, or use section and cursor for paged exact text and resource IDs.
platform_export_agent_definition	Save an agent’s complete definition as a JSON file and return its file handle.
platform_list_agent_runs	List accessible runs across agents, filtered by agent, stored status, and creation time.
platform_stop_agent_run_turn	Request cooperative stop of a specific active turn and return the observed state.
platform_retry_agent_run_step	Retry an eligible failed LLM step in the same run, preserving completed output and the pinned agent version.
platform_start_standalone_agent_run	Start an agent run.
platform_get_event_trigger_options	Discover supported event configuration for a usable integration connection.
platform_get_agent_trigger	Inspect an event or Direct Webhook trigger without returning its secret.
platform_set_agent_event_trigger	Set event conditions, connection, and explicit enabled state.
platform_set_agent_direct_webhook_trigger	Set a Direct Webhook condition and enabled state; return a builder setup link.
platform_get_agent_schedule	Read an agent’s recurring schedule, permissions, and your organization’s scheduling limits.
platform_set_agent_schedule	Set the complete recurring configuration, or clear it with null, on an agent you created.
platform_create_agent	Create a prompt-based agent with optional model and initial tool servers, returning a saved configuration snapshot.
platform_edit_agent	Change an agent’s name, description, instructions, or model and return a saved configuration snapshot.
platform_set_agent_tool_server	Enable or disable a whole tool server on an agent. Account connections and tool approval settings still govern execution.
platform_set_agent_skill	Attach or detach an existing accessible skill by lineage ID.
platform_set_agent_knowledge_content	Attach or remove existing accessible knowledge content. Requires Knowledge Store to be enabled; attachment may start indexing.
platform_list_agent_configuration_options	List accessible model or tool server IDs, with pagination.
platform_list_integrations	Discover allowed integrations and the destination for connecting an account in Kindo.
platform_list_integration_connections	List accessible account metadata and active connections for an integration.
platform_get_agent_connection_readiness	Inspect agent defaults and step overrides, selected accounts, missing connections, and account-routing restrictions.
platform_set_default_integration_connections	Replace your active connections for an integration; an empty set restores automatic selection.
platform_set_agent_integration_connections	Replace or clear pins on an already-enabled agent tool server.
platform_list_departments	List active departments, including Unassigned, and member counts, newest first, with pagination.
platform_create_department	Create a department and return its ID. The name Unassigned is reserved.
platform_rename_department	Rename a department by ID, including an archived one. Unassigned cannot be renamed, and the name is reserved.
platform_archive_department	Archive a department, move every current member to Unassigned, delete its own budget (warning and block amounts), and keep its name; rename it by ID to reuse the name. Unassigned cannot be archived.
platform_list_users	List organization members with roles, departments, and bounded user-group summaries.
platform_get_user	Look up one organization member by user ID or email.
platform_set_user_departments	Preview or apply up to 100 department assignments, reporting rejected rows separately.
platform_list_audit_events	Browse audit events by date, user, and event type, with pagination.
platform_get_audit_event	Read one audit event’s recorded metadata.
platform_get_organization	Read the organization’s ID, name, and settings. Available to any member.
platform_update_organization_name	Rename the organization.
platform_update_organization_settings	Change organization settings and return all of them. Turning off pinned connections clears pins.
platform_list_organization_invites	List pending invites, newest first, with pagination.
platform_invite_organization_member	Invite an email address with a role. Sends an invitation email; a pending invite for the address is replaced.
platform_revoke_organization_invite	Revoke a pending invite by ID.
platform_update_organization_member_role	Set a member’s role by user ID. The only admin or a superadmin cannot be demoted.
platform_remove_organization_member	Remove a member by user ID; they move to a new organization of their own. The only admin and superadmins cannot be removed.
platform_describe_ai_spend_query	Read the AI Spend query language: metrics, groupings, filters, rules, examples, and the first month with spend.
platform_query_ai_spend	Query spend, tokens, hours saved, ROI, and agent counts for one UTC calendar month, with filters, grouping, daily series, and pagination.
platform_list_ai_spend_filter_options	List up to 100 agent, department, user, or user-group filter options for one month, alphabetically by name. Use search to find omitted names when truncated is true.
platform_list_models	List chat models you can view, including ones disabled by security controls, with deployment summaries and pagination.
platform_get_model	Get one available model by ID with its deployments.
platform_list_model_providers	List model providers, up to 100.
platform_delete_model	Delete one of your organization’s own models and its deployments.
platform_set_model_deployment_priority	Set the routing priority of one deployment of your organization’s own model.

Platform tools require Platform MCP to be enabled and configured for your organization. Knowledge attachment also requires the KNOWLEDGE_STORE feature flag. Chat structured-metadata tools also require Chat Structured Metadata (CONVERSATION_METADATA) to be enabled for your organization; whether an agent has a schema does not affect discovery. Agent-level model selection requires the Agent Builder Instructions beta (AGENT_BUILDER_INSTRUCTIONS); while it is disabled, a model can be saved on the agent but does not override the request’s model at execution. Contact Kindo to request beta access.

Connection tools return account configuration without testing credentials or network reachability. A configured result does not guarantee that a live operation will succeed; execution still applies integration and tool policy. Account information is limited to connections you may use. Readiness is evaluated for you as the runner, with separate rows for agent defaults and each LLM step’s effective configuration. Existing conversations keep their own configuration.

Selection tools accept up to 25 connections. Readiness returns limit_exceeded if more than 25 accessible accounts are selected or a single row exceeds the response-size limit. Lowering the page limit does not shrink a single row; selected accounts are never silently omitted.

Your active connections are the selections you manage in Command Center → Integrations. Changes to active connections and pins select already-authorized accounts. Pins require your organization to allow pinning; selecting multiple accounts requires account routing to be enabled. Agent pins require edit access, and step overrides remain in effect. Kindo never replaces an unavailable pin with a connection outside the pinned set; any remaining authorized pinned connections still apply. When an administrator disables pinning, the running user’s active connections apply. See pinned connection behavior. If a write result is unavailable, inspect the connection list or agent readiness before retrying. You can clear your saved active connections after integration access is revoked. Agent editors can also clear stale pins on an already-enabled tool server. Clearing these selections does not restore integration access.

When human authorization is needed, open the returned connection_destination and select the integration in Command Center → Integrations. Complete the existing connection flow there, then inspect accounts again. These tools do not start an authentication session, accept credentials, change sharing, or resume an interrupted operation.

Audit, department, member-directory, and organization-management tools require organization-admin access, except platform_get_organization, which any member can call. Department tools also require your organization’s plan to include department management. Audit, directory, and organization-management tools remain available without that plan requirement. Discovery omits admin-only tools when their requirements are not met. Calls recheck current access, including when you use a previously discovered tool.

AI Spend tools require organization-admin access. The tools only read data, and their numbers match the AI Spend dashboard. Each query covers one UTC calendar month and returns up to 10 groups per page. A query that requests an All Others row returns at most one more row, for the remaining groups, and has no further pages. A daily breakdown returns one row for each day. Keep the same month, filters, and query when continuing with next_cursor. Each filter accepts up to 50 IDs. The agent_status filter uses warning for Warning and stopped for Over limit.

Audit tools let organization admins read retained events on any plan, including after a downgrade. Events are recorded only on the Enterprise plan; see Audit Log. Each successful list call, including each page, attempts to record AUDIT_LOG_VIEWED subject to the organization’s audit configuration.

Audit listings return event headers and actor metadata, newest first. They hide system event types by default; use include_system_events to include them, or event_type to select one exact type. Dates must include a timezone. Keep the same filters when continuing with next_cursor. The maximum page size is 100; the response budget can shorten a page further. If actor metadata cannot fit, the listing returns it as null with user_metadata_truncated: true, preserving the event and user IDs so pagination can continue. Individual event reads return the metadata as recorded, including any original redaction or truncation. An event that exceeds the tool response budget returns limit_exceeded; inspect it in the audit log UI if your plan includes security settings. Coverage depends on the organization’s audit configuration, so a missing event does not establish that an action never occurred.

Model tools never accept or return provider API keys. A deployment is one of the providers listed for a model in Settings → Models; its priority sets its place in the fallback chain. Listing and reading models is open to every organization member. Deleting a model and setting a deployment priority require organization-admin access and an Enterprise plan; discovery omits them otherwise and calls recheck current access. Deleting a model is permanent: agent steps using it move to the default step model, and agents whose model it was fall back to your organization’s default chat model; if the deleted model is that default, the setting is cleared and the platform default applies. Endpoint URLs omit credentials and query strings, and at most 10 deployments are listed per model in platform_list_models (use platform_get_model for more). Use model and deployment IDs from the list results.

Each assignment names its user by email or user ID, and its department by ID or by exact name. Name matching is case-sensitive after trimming leading and trailing spaces, even though department name uniqueness ignores case. null or Unassigned moves the member to Unassigned. Assignment does not create departments; create missing ones with platform_create_department first. Archived departments cannot be assigned to, and their names stay taken, so restore or rename one in Settings → Departments before reusing its name. Display values over 255 characters end in …, so use IDs for exact references; group lists contain at most 50 entries and report truncation. For bulk assignment, call with dry_run: true to preview, then dry_run: false to apply. Omitting dry_run applies changes. One batch can assign members to different departments. The first assignment for a user wins. Rows are rejected individually as user_not_found, department_not_found, or duplicate_user without blocking valid rows. The changes and rejected lists can be truncated to fit the response, as their truncation flags report; the counts always cover the whole batch. Changes commit by department, so a failure can leave part of a batch applied. If the result is unavailable, inspect current departments and users before retrying. Archiving moves all current members to Unassigned, deletes the department’s own budget (warning and block amounts), and cannot be reversed through these tools.

Organization tools take user and invite IDs from platform_list_users and platform_list_organization_invites. Invite listings page like other lists: limit is 1 to 100 (default 20) and next_cursor continues. Names and emails are at most 255 characters, and an invite email is lowercased. Inviting an address that already has a pending invite replaces it and sends another email; an address that belongs to an organization with other members is a conflict. platform_update_organization_settings takes the settings to change and at least one is required. allow_unverified_integrations, skills_enabled, and default_tool_call_approval_mode can be read but not changed. Only blended_hourly_rate_usd, default_chat_model_id, default_hours_saved_per_run, and default_user_group_id accept null to clear them. sso_enforced is a conflict until an SSO connection is configured, and turning off pinned connections clears existing pins. A role change or removal that would leave no admin, or that targets a superadmin, returns a conflict.

Discover conversations

Use platform_list_conversations to find conversations, then pass a returned conversation_id as id to platform_get_conversation to read the selected chat. The list includes conversations you can read under normal access controls. It excludes chats you have hidden, deleted chats, and chats with no messages.

All inputs are optional:

Input	Contract
query	Case-insensitive literal title text, at most 255 Unicode code points. Leading and trailing whitespace is ignored; do not URI-encode the text. Message content is not searched.
agent_id	Agent UUID to filter conversations by agent.
scope	own (default) for conversations you created, or all_accessible for all conversations you can read.
cursor	Continuation cursor, at most 4,096 characters.
limit	Integer from 1 to 100; defaults to 20.

The response contains items and a required next_cursor, which is null when there are no more results. Each item contains:

Field	Contract
conversation_id	Conversation CUID.
title	Title or null, limited to 255 Unicode code points.
title_truncated	Whether the title was shortened.
last_interaction_at	Last interaction time in ISO 8601 format.
agent_id	Current associated agent UUID, or null when there is no associated agent or it has been deleted. A direct association takes precedence; the hosting run is used only when there is no direct association.

Results are ordered by last interaction, newest first, with conversation IDs in descending order to break ties. Pass next_cursor as cursor with unchanged filters to continue. Response size can produce a short page with a next_cursor; continue until next_cursor is null. Cursors are tied to your account and organization. Pagination does not provide a snapshot: interactions and access changes can change results between pages. This tool discovers conversation summaries; it does not change chats, retrieve files, or continue a conversation.

The list’s agent_id describes the conversation’s current association. platform_get_conversation.agent_run.agent_id describes the hosting run’s agent, which can differ. The reader’s agent_run is null for chats with only a direct agent association.

Chat structured metadata

Some agents keep a structured document on each of their chats — shown and editable in the chat panel, and described by a per-agent schema configured in the agent builder. Call platform_get_agent_conversation_metadata_schema with an agent_id to read that schema; it requires access to the agent’s configuration. enabled: false and schema: null mean the agent has none configured, which is not an error. A schema too large to return through the tool (roughly 12 KB) fails with an explicit, non-retryable error.

Call platform_search_agent_conversation_metadata with an agent_id to find the agent’s conversations by metadata field. Results include only conversations you can read that have a metadata document, and the call requires access to the agent’s configuration. predicates are AND-ed, up to 16 per call; each predicate’s path is a list of keys addressing a value in the document (a single-element list for a top-level field). equals requires an exact, type-sensitive match; contains does a case-sensitive substring match for string values and falls back to exact equality for numbers and booleans. created_after and created_before bound creation time inclusively, in ISO 8601 with a timezone. Results are newest first, with conversation IDs in descending order to break ties; pass next_cursor back with the same agent_id, predicates, and time bounds to continue, until it is null. This is a live list, not a snapshot. agent_run is null for a conversation with no hosting run.

A metadata document too large for a search result page is returned with metadata: null and metadata_truncated: true, never omitted — read it in full with platform_get_conversation_metadata and a conversation_id from the search result. That tool requires read access to the conversation; a document too large even for its own larger response budget fails explicitly rather than returning a silently shortened one.

Call platform_patch_conversation_metadata to change a document; it requires write access to the conversation. operations, up to 64 per call, apply in order: set creates or replaces the value at path, and remove deletes it. expected_revision is required and must match the document’s current metadata_revision, from platform_get_conversation_metadata or a previous write; a stale value fails as a conflict rather than silently overwriting a change you have not seen — re-read the current revision and retry with it. For a document too large for platform_get_conversation_metadata (roughly 12 KB), the search tool still returns its metadata_revision alongside metadata_truncated: true. The merged document is validated against the agent’s configured schema; a value the schema rejects, or an agent with chat metadata not configured, fails as invalid_input with no change. The call returns the new metadata_revision; read the full document back with platform_get_conversation_metadata. Execution may require approval under your organization’s current tool-call policy.

Export an agent definition

Call platform_export_agent_definition with an agent_id to save the agent’s complete definition as a JSON file, the same file an agent export downloads. The result returns content_id, filename, bytes, and sha256 instead of the definition text. For a summary or the exact text of one field, use platform_view_agent_configuration. In chat with a configured sandbox provider, the agent reads the file by downloading it with files_download_original and its content_id.

• The file holds the agent’s inputs, triggers, tool servers, knowledge, and every step, including prompts, API requests, and script step settings. It does not include skills attached to the agent; read those with platform_view_agent_configuration and section: skills.
• Exporting requires access to the agent’s configuration.
• The file is saved as yours, and only you can download it. Exporting again while the definition’s contents are unchanged returns the same file, unless you removed it; otherwise a new file is saved. Renaming a model or secret the agent uses also changes the contents.
• If your access to the agent is removed, you can no longer export it. A file you exported earlier stays yours, but you get no later version of the agent.
• Values stored as Kindo secrets appear only as secret references. Literal header, parameter, and body text is included as configured, so a credential typed into a step instead of stored as a secret appears in the file.
• Import from file accepts the file to create a new agent.

Inspect and control agent runs

Use platform_list_agent_runs without agent_id to search across accessible agents. The optional status filter accepts in_progress, success, failure, or cancelled and filters the stored run status. created_after and created_before are inclusive creation-time bounds in ISO 8601 with a timezone. Results are newest first; pass next_cursor with unchanged filters to continue.

platform_get_agent_run accepts a run UUID in id and these section values:

Section	Result
timeline (default)	Message and tool-call display summaries. Truncated fields are marked.
status	Stored run status, latest persisted turn, safe error details, invocation source and pinned version when available, and paginated step states.
text	Complete persisted text, tool arguments, and tool results in message/part order, in chunks of at most 4,000 Unicode code points.

Keep the section unchanged when following next_cursor. For text, concatenate chunks by message_id, part_index, and field; offset counts Unicode code points within that field. A nonzero omitted_source_part_count identifies parts outside the text contract, such as files. message_unreadable: true marks a malformed message whose content could not be read; continue to retrieve later messages. Absent tool fields are not invented as placeholder text. If a partially read message changes before you finish its chunks, continuation returns a conflict; restart the text read. Pagination does not provide a transcript snapshot. Restart to refresh a live result after reaching the end. These tools do not download files.

Run and turn statuses can disagree. The status section reports each separately; a failed run does not imply its latest turn has stopped. invocation_source reports persisted lineage as child_agent, child_chat, trigger, or unknown. Runs started directly through the UI, API, or Platform tools report unknown.

To stop a supported turn, read its status and pass current_turn.triggering_user_message_id as message_id to platform_stop_agent_run_turn, together with run_id. It requires conversation write access; callers with read-only access receive not_found. Check current_turn.stoppable first: it reports whether an execution target is available, independently of your access. A stale target or one that cannot currently be stopped returns not_active and never targets a later turn. For example, a pending turn may not have a worker ID yet. Read status again and request stop if it becomes stoppable; not_active does not mean the turn has finished.

The response cancellation_requested confirms that the request was published. Stopping a turn can also cancel its queued or running direct child work. Inspect current_turn and read status again to see whether the turn has stopped.

platform_retry_agent_run_step takes run_id and step_run_id. It requires conversation write access and agent access. It supports a failed LLM step in a failed run that was not started by a trigger, with no completed later step; an active turn must settle first. Retry removes the failed step’s partial messages, retains earlier completed output and the pinned version, and returns retry_started. Inspect the run before repeating a call with an uncertain outcome. Run-wide restart, arbitrary pause/resume, and separate child-run management are outside these tools.

Event and Direct Webhook triggers

Use platform_get_event_trigger_options with a usable integration connection ID to discover supported ticket-created event fields, comparisons, and operators. platform_get_agent_trigger returns an agent’s non-scheduled trigger or null, along with edit permission, event-creation plan eligibility, and schedule or child-agent conflicts.

Set the complete desired configuration with one of these tools:

• platform_set_agent_event_trigger: agent_id and config containing connection_id, input_type, operator, conditions, and enabled.
• platform_set_agent_direct_webhook_trigger: agent_id and config containing natural_language_condition and enabled. An empty condition accepts any payload.

Event configurations accept up to 20 predicates with 1–1024 characters per value. Direct Webhook conditions accept up to 2048 characters. The complete config object must also fit 2500 UTF-8 bytes of compact JSON. These limits apply together; use fewer predicates or shorter text if the total is too large. Over-limit configurations are rejected before saving.

Reading requires access to the agent’s static configuration. Changes also require creator edit access. Event setup requires permission to use the selected connection and an integration that supports webhooks. Only event creation requires Enterprise; Direct Webhook setup has no plan or connection requirement.

Each agent has one trigger. A different trigger type or child-agent configuration blocks setup; remove the conflict in the builder first. To enable or disable a trigger without changing its configuration, pass config containing only the desired enabled value to the matching setter. This also works for legacy configuration outside setup limits and retained triggers whose connection was removed or is no longer usable. It requires the same agent permissions and never selects a connection. Disabling preserves its configuration and any webhook secret. Unchanged completed requests avoid another write. After a failed write, inspect platform_get_agent_trigger before retrying, because changes may have been saved.

When configuration_complete is false, the read result omits condition text that is too large to return. Use an enabled-only update, replace the full configuration with a smaller one, or open the builder; never resend the summary as complete configuration.

Direct Webhook results include a credential-free builder link. A Direct Webhook created by these tools has no visible URL until you open that link and select Regenerate token, so the agent should tell you to do that. Never give the token to the agent. These tools configure triggers without testing delivery or stopping runs already in progress.

Recurring schedules

Call platform_get_agent_schedule with an agent_id. Its schedule is either null or an object with enabled, cron_expression, and time_zone. The result also includes constraints: your edit permission, plan eligibility, whether another trigger blocks creation, and your organization’s enabled-schedule count, quota, and minimum interval. A shared agent does not expose its owner’s private organization limits. Reads require access to the agent’s configuration; changes also require the agent’s creator permissions.

Call platform_set_agent_schedule with the same agent_id and the complete desired schedule object. All three fields are required. Use an IANA time zone, such as UTC or America/Los_Angeles; the cron uses that display time zone and the same conversion as the schedule builder. Set enabled: false to preserve the configuration without scheduled starts, including when first creating it. Pass schedule: null to clear the configuration. Repeating the current state does not write changes or register the schedule again.

An agent supports one trigger, including a schedule, event trigger, or webhook. A disabled schedule still occupies that slot; clear it to allow another trigger. Creating a configuration requires an Enterprise plan. Adding an enabled schedule enforces your organization’s enabled-schedule quota. Creating or changing the cron or time zone, or enabling a disabled schedule, also enforces the minimum interval. Disabling, clearing, and unchanged-state calls remain available if those limits tighten.

Disabling or clearing a schedule does not stop runs that have already started. Results describe persisted configuration, not scheduler health or guaranteed delivery. If a mutation fails or its result is unavailable, inspect platform_get_agent_schedule before retrying. A failure can leave part of the change applied, including a new cron saved with the schedule disabled.

These tools use the existing Platform permission and approval policies. They manage recurring starts without schedule payloads or one-off runs.