Pylon

List the fields available when building an account filter, plus the org's custom account fields. Properties with a static value space (account_state, account_source, is_disabled) include allowed_values inline. Reference-typed properties (team_id → team, owner_id → user, parent_account_id → account) require UUIDs — resolve via search_teams / search_users / search_accounts first.

Get an AI agent's full event/action timeline on a specific real issue — kickoff, tool calls, runbook steps, reassignments/escalations, messages, and outcomes. The live-issue analog of get_playground; use it to diagnose what the agent did on a real issue. Both agent_id and issue_id are required (use list_agents and get_agent_issue_logs to discover them).

Get full details for a Pylon contact (customer). Pass the contact ID (UUID). Returns contact details including name, email, account, and custom fields.

List the fields available when building a contact filter, plus the org's custom contact fields. contact_portal_role includes allowed_values inline. contact_account_id references an account — resolve via search_accounts before passing a UUID.

Get custom field definitions for an object type in Pylon. Returns the list of custom fields configured for the given object type, including their slugs, labels, types, and options. Supports opportunities, accounts, issues, contacts, tasks, and projects.

List the fields available when building a feature request filter, plus the org's custom feature request fields.

List every active feature request status configured for this organization, including built-in and custom statuses. Use the returned value as request_status in update_feature_request.

Entry point for filter field discovery. Returns a directory of per-object tools — call the one matching your object type (issue / account / contact / task / project / opportunity / feature_request) to get its fields, operators, and reference types. For value spaces on dynamic properties (issue state, task_status), call the matching status tool (get_issue_statuses, get_task_statuses) in addition. Call this when you don't know which specific tool to use; skip straight to the specific one when you do.

Get full details for a Pylon support issue/ticket. Pass either the issue ID (UUID) or issue number. Returns title, body, state, metadata, custom fields, and nested account/assignee/requester info.

List the fields available when building an issue filter, plus the org's custom issue fields. Properties with a static value space (source, issue_type, booleans, last_message_from) include allowed_values inline. For state — the one dynamic, org-configured enum — call get_issue_statuses; this tool does not fetch statuses automatically. Properties with reference_type="team" or "user" (e.g. team_id, assignee_id, owner_id) require UUIDs: resolve names via search_teams / search_users before passing values to build_filter.

Get the full message history for a Pylon issue. Pass either the issue ID (UUID) or issue number. Returns all messages in chronological order with author info.

List every issue status configured for this org: the five default categories (open, in_progress, on_hold, waiting_on_action, closed) plus any custom statuses the admin has added. Call this when you need values for the issue state property in build_filter — pass value=<slug> to equals / values=[...slugs] to includes_any_of. The value "open" is the slug of the default New status (it matches only New, not every non-closed status). To filter for active/non-closed issues, use operator not_any_of with value "closed".

Get the currently authenticated user's details. Returns the user's name, email, and role. No parameters required.

Get full details for a milestone by ID.

List milestones, optionally filtered by project_id and/or account_id.

List the fields available when building an opportunity filter, plus the org's custom opportunity fields. opportunity_account_id references an account — resolve via search_accounts.

Get full details for a specific project. Returns project information including description, owner, and progress counts. Use get_milestones with project_id to retrieve its milestones.

List the fields available when building a project filter, plus the org's custom project fields. project_status and project_is_archived include allowed_values inline. project_owner references a user, project_account_id references an account — resolve via search_users / search_accounts.

List project templates in the organization by name and ID. Use a listed project_template_id with create_project_from_template or create_project.

Get up to 100 projects, optionally filtered by account. Without account_id, searches organization projects. Returns a lightweight list with project metadata including name, status, dates, and progress counts. Use limit to request between 1 and 100 results (default 50). Projects are a Plus plan feature.

Look up a single tag by its exact value. The lookup is case-sensitive and scoped to the organization's default tag key for the given object_type. Returns a not-found error if no tag matches — use list_tags for fuzzy or prefix discovery.

Get full details for a single task by ID, including its parent task ID and immediate subtasks.

List the fields available when building a task filter, plus the org's custom task fields. For the task_status property's allowed values (default + org-custom statuses), call get_task_statuses — this tool stays cheap and does not fetch them automatically. task_assignee references a user, task_account_id references an account — resolve via search_users / search_accounts.

List every task status configured for this org: the default categories (not_started, in_progress, completed) plus any custom task statuses the admin has added. Call this when you need values for the task_status property in build_filter — pass value=<slug> to equals / values=[...slugs] to includes_any_of. To filter for active/non-completed tasks, use operator not_any_of with value "completed".

Get tasks filtered by account and/or project. At least one of account_id or project_id is required. Returns a lightweight list of tasks with their details including title, status, assignee, due date, and project information.

Get one trigger's complete stored configuration, including kickoff metadata, branches, conditions, action/time-delay steps, and stable branch/step IDs.

Return canonical input-shaped examples for common trigger patterns. Call this before create_trigger or update_trigger when constructing branches, delays, condition checkpoints, multiple kickoffs, or front delays. Examples intentionally omit triggerID, groupID, title, and description; resolve those fields separately and use live discovery tools for action variables, kickoff conditions, filters, and entity IDs.

Get full details for a Pylon user (team member). Pass the user ID (UUID). Returns user details including name, email, and role.

List tags defined in the organization. Filter by object_type to get only issue tags or only account tags. Use this to resolve a tag's value to its ID before calling add_issue_tags, remove_issue_tags, update_tag, or to check whether a tag already exists before calling create_tag.

List all teams in the organization. Returns each team's ID and name. Useful for discovering team IDs to pass to other tools (e.g. the team_id filter on search_issues).

List every trigger action type and the kickoff types that support it. Call describe_trigger_action for each action you intend to use before building its variables payload.

List trigger groups in the current Pylon organization, including each group's ID, title, icon, and default status.

List every trigger kickoff type and whether it takes a condition. Call describe_trigger_kickoff for the selected type before building kickoffMetadata.

List triggers in the current Pylon organization with their kickoff/action structure and firing statistics. Condition trees and large action bodies are omitted; use get_trigger for one complete configuration.

Search for customer accounts in Pylon. Returns a lightweight summary of accounts matching the specified filters. Supports filtering by custom fields using the custom_field_filters parameter - pass the custom field slug as the field name. For user-type custom fields (e.g. Salesforce AE owner), you can pass a Pylon user name or user ID as the value. Supports cursor-based pagination - use the returned cursor to fetch additional pages. Pass a returned account ID to get_account for full details including custom fields, external IDs, and linked channels.

Search for contacts in Pylon. Returns a lightweight summary of contacts matching the specified filters. Supports filtering by name (fuzzy search), email, account, and custom fields. Use the get_custom_fields tool with object_type 'contact' to discover available custom field slugs. Supports cursor-based pagination - use the returned cursor to fetch additional pages. To get full contact details including custom fields, use the get_contact tool.

Search for issues/tickets in Pylon. Returns a lightweight summary of issues matching the specified filters. Supports cursor-based pagination - use the returned cursor to fetch additional pages. Pass a returned issue ID to get_issue for full details including body, custom fields, and nested account/assignee/requester info.

Search projects across the organization by project name, account, owner, status, and archive state.

Search tasks across the organization. Unlike get_tasks, this does not require account_id or project_id. Supports filtering by account, project, assignee, statuses, and full-text search.

Look up teams in the current organization by name (case-insensitive substring match). Returns team IDs and names. Use this whenever a filter, chart, or other tool requires a team ID — never pass a raw team name (e.g. "CS") as a team_id value.

Search for Pylon users (team members) by name. Returns matching users with their ID, name, and email.

Update an existing customer account in Pylon. You can update the name, owner, tags, and custom fields. Custom field keys must be configured account-field slugs. Use get_account to read the full account details before updating.

Update an existing issue/ticket in Pylon. You can update the state, assignee, team, tags, and custom fields. Custom field keys must be configured issue-field slugs. Use get_issue to read the full issue details before updating.

Update milestone fields. Pass empty string for due_date to clear it.

Update project fields. Pass empty string for nullable date fields or owner_id to clear them.

Update an existing task. Specify the task_id and any fields to update. Pass empty string for nullable fields (due_date, account_id, project_id, milestone_id, assignee_id) to clear them.

Fully replace the editable configuration of an existing enabled or disabled V1-compatible trigger. The trigger stays in its current custom group and keeps its enabled/disabled state. Call get_trigger_examples for canonical patterns, then get_trigger and preserve useful branch/step IDs while replacing the complete editable configuration. Call validate_trigger with the completed payload before updating it. One or more non-recurring, non-phone kickoffs and flat action/time-delay/condition steps may be used across multiple branches. Actions must be compatible with every kickoff. A failed standalone conditions step stops the rest of its branch. Front delays use the condition key and schema returned by describe_trigger_kickoff. Updates are rejected for default groups, recurring schedules, phone/IVR triggers, nested branches, or background-agent investigations.

Upload one or more files (e.g. PDFs) into the Files tab of an account. Files with a matching filename are overwritten. Max 5 files per call, max 10 MB per file.

Validate a complete create_trigger or update_trigger payload without writing a trigger or creating a version. Use groupID for a create proposal or triggerID for a full replacement update, but not both. Call this while iterating, then pass the same payload to the corresponding write tool when valid is true. Validation uses the same supported V1 shape, organization-scoped lookups, kickoff/action compatibility checks, and persisted trigger rules as the write tools.