Plugin tracker

Tools

Explore what tracked Claude Connectors and ChatGPT Plugins can actually do. Search by tool, Plugin, Brand, category, verb, or access requirement.

Latest snapshot2026-09-11USmethodology registry-public-v1

Searchable tools

113,017

Authless tools

7,424

Auth required

100,766

Described tools

61,166

113,017 tools

Get Payroll Detailsget · Retrieves complete details for a single payroll by UUID, including worker earnings, taxes, deductions, and net pay. This tool is read-only; use update_payroll to modify payroll inputs (hours, memos, bonuses, PTO) or run_payroll to calculate and submit the payroll.GustoGustoPluginrequiredFinance
Get Time Sheet Detailsget · Retrieves detailed time entries for a single timesheet by UUID, including daily hours worked, overtime, breaks, and notes. Third-party time tracking only - there is no native equivalent, and passing a native shift id fails with a transport-level "resource not found" whose text talks about credentials and configuration rather than the real cause. Check that list_time_records reported a third_party source first, and take the timesheet's top-level id from there. For native companies list_time_records already returns per-shift detail, so no follow-up call is needed. Call this for a line-item breakdown of someone's hours for a specific pay period.GustoGustoPluginrequiredFinance
Get Time-Off Balancesget · Returns employees' current time-off balances - available (balance), accrued, used, and pending hours per policy - with each balance attributed to the worker (name) and policy uuid. Policy name and type are included only when the token also holds the time_off_policies:read scope; without it, policy labels come back blank (the policy uuid is still returned). Use this when an admin asks about PTO, sick, or vacation balances (e.g. "how much vacation does each employee have left?"). Optionally scope with employee_uuids or policy_uuids (comma-separated). Note - covers domestic (US) employees; balances reflect the company's configured time-off policies.GustoGustoPluginrequiredFinance
Get Time-Off Request Detailsget · Retrieves full detail for a single time-off request by UUID - the worker (name + uuid), status, policy (type + uuid), the per-day hours requested, and the initiator/approver. Employee and employer notes are omitted, since they are free text that may contain health information. Use list_time_off_requests first to discover the request UUID.GustoGustoPluginrequiredFinance
Get Token Infoget · Returns information about the current API access token including which permissions (scopes) are granted and which company resources can be accessed. Use this to check what data operations are available or troubleshoot access issues before attempting other API calls.GustoGustoPluginrequiredFinance
Get Work Address Detailsget · Retrieves full details for a single work location assignment by UUID, including the location address and effective dates. Use list_employee_work_addresses first to find the work address UUID. Call this for complete details about a specific work location assignment.GustoGustoPluginrequiredFinance
List Contractor Payment Groupslist · Lists batched contractor payment runs for the company. A payment group represents multiple contractor payments processed together on the same date. Shows group UUID, check date, and processing status. Use this to see batched payment history or find payment group UUIDs.GustoGustoPluginrequiredFinance
List Contractor Paymentslist · Lists all payments made to independent contractors within a date range. Shows payment amounts, check dates, and contractor info. Requires start_date and end_date parameters. Use this to see contractor payment history, audit 1099 payments, or find how much was paid to contractors. Note - only includes payments to domestic (US) contractors. International contractor payments are not included.GustoGustoPluginrequiredFinance
List Contractorslist · Lists all independent contractors (1099 workers) for the company with pagination and search. Returns contractor UUIDs, names, and basic info. Unlike employees (W-2), contractors are paid separately and file their own taxes. Use this to find contractor UUIDs or get a roster of non-employee workers. Returns all contractors including inactive; check the is_active field for current status. Note - this only includes domestic (US-based) contractors. International contractors are not included in results. If the company has international contractors, mention that totals reflect domestic contractors only.GustoGustoPluginrequiredFinance
List Custom Fields Schemalist · Retrieves the definitions of all custom fields configured for the company, including field names, data types, and selection options. Custom fields let companies track additional worker attributes beyond standard HR data. Use this to understand what custom data is available before querying individual worker field values.GustoGustoPluginrequiredFinance
List Departmentslist · Lists all departments in the company org structure, including department names, UUIDs, and which employees are assigned to each. Use this to see the organizational breakdown, find department headcounts, or understand how workers are grouped. Note - department employee lists and headcounts only include domestic (US) employees. International employees are not reflected in these counts.GustoGustoPluginrequiredFinance
List Earning Typeslist · Lists all earning type categories configured for the company, such as regular pay, overtime, bonuses, commissions, tips, and custom earning types. Shows type name, category, and whether it's taxable. Use this to understand available pay types for payroll input.GustoGustoPluginrequiredFinance
List Employee Custom Fieldslist · Retrieves all custom field values set for a specific employee. Custom fields are company-defined attributes like T-shirt size, emergency contact, certifications, or any other custom data. Use list_custom_fields_schema first to see available field definitions.GustoGustoPluginrequiredFinance
List Employee Employment Historylist · Retrieves the complete work history timeline for an employee, including all positions held, role changes, and status transitions. Use this to answer questions about someone's tenure, past roles, or employment dates within the organization.GustoGustoPluginrequiredFinance
List Employee Home Addresseslist · Lists all residential addresses on file for an employee, including current and historical addresses with effective dates. Home addresses are used for tax withholding calculations and mailing.GustoGustoPluginrequiredFinance
List Employee Jobslist · Lists all job positions held by an employee, including current and past roles. Each job record contains title, location, hire date, and rate information. Use this to see someone's role history or find job UUIDs needed for compensation lookups.GustoGustoPluginrequiredFinance
List Employee Separationslist · Retrieves offboarding and separation records for an employee, including departure dates, reasons for leaving, and final pay information. Use this to find when someone left the company, their exit date, or details about their offboarding process.GustoGustoPluginrequiredFinance
List Employee Work Addresseslist · Lists all work locations assigned to an employee, including current and historical assignments with effective dates. Work addresses determine work-state tax jurisdiction. Use this to see where someone works or has worked, especially for remote or multi-location workers.GustoGustoPluginrequiredFinance
List Employeeslist · Lists all employees for the company with pagination and filtering options. Returns basic profile data for each person. Filter by onboarding status, active/inactive status, or search by name. Use this to find employee UUIDs, get headcount, or answer questions about the workforce roster. Without filters, returns all employees including terminated; use terminated=false for active employees only. Note - this only includes domestic (US-based) employees. International employees are not included in results or headcount. If the company has international employees, mention that totals reflect domestic employees only.GustoGustoPluginrequiredFinance
List Job Compensationslist · Lists the pay rate history for a job position, showing all salary or hourly rate changes over time. Each entry includes effective date, rate amount, and payment unit (hourly/salary). Use this to see pay history or track when raises were given. By default only the current compensation is returned. Set include to all_compensations to retrieve the full history.GustoGustoPluginrequiredFinance
List Locationslist · Lists all physical office or work locations registered for the company, including addresses and whether each is active. Locations are used for tax filing, work address assignments, and compliance. Use this to see all company offices or find location UUIDs.GustoGustoPluginrequiredFinance
List Pay Periodslist · Lists all pay periods (date ranges when work is performed) for the company, with links to associated payroll runs. Shows start date, end date, check date, and payroll status. Use this to see upcoming pay periods or find which payroll covers a specific date range.GustoGustoPluginrequiredFinance
List Pay Schedule Assignmentslist · Shows which employees are assigned to which pay schedules. Returns mappings between worker UUIDs and schedule UUIDs. Assignment rules vary by company setup - some assign by department, others individually. Use this to find out when a specific person gets paid or which schedule they follow.GustoGustoPluginrequiredFinance
List Pay Scheduleslist · Lists all configured pay schedules for the company, showing frequency (weekly, biweekly, monthly, etc.), name, and schedule UUID. Does not show which workers are on each schedule. Use this to understand pay frequency options or find schedule UUIDs for assignment lookups.GustoGustoPluginrequiredFinance
List Payroll Blockerslist · Identifies issues preventing a specific payroll from being processed, such as missing bank accounts, incomplete tax setup, or unsigned documents. Each blocker includes a description and resolution steps. Use this to diagnose why payroll cannot run or to check readiness before processing.GustoGustoPluginrequiredFinance
List Payrollslist · Lists all payroll runs for the company with filtering options. When called with no arguments, returns all payrolls (processed and unprocessed, regular, off_cycle, and external) from the past 6 months (start_date defaults to 6 months ago, end_date defaults to today). You can filter results by providing processing_statuses, payroll_types, start_date, end_date, or include parameters. Date filters apply to pay period (work dates), not payment dates. Date range constraints are that the range cannot exceed 1 year, and end_date cannot be more than 3 months in the future. Returns payroll UUIDs, check dates, processing status (processed,unprocessed), and type (regular,off_cycle,external). Use include=totals to get payroll-wide aggregate amounts (gross pay, taxes, net pay, total commissions, total bonuses). These totals are NOT broken down per employee. For per-employee earning breakdowns (who received which commissions, bonuses, etc.), use get_employee_earnings_summary instead. IMPORTANT - Never guess or infer which employees received specific earning types from aggregate totals alone. Common use case is to find the next payroll to process by filtering for processing_statuses=unprocessed and selecting the payroll with check_date closest to today's date. Note - payroll data only covers domestic (US) employees. International employee payroll is managed separately and not included here. Payroll sub-state within `unprocessed`: each list item carries `processed` (boolean) and `calculated_at` (nullable timestamp), but the roster (`employee_compensations`) is NOT included in list responses. From this list alone, use `calculated_at` to distinguish sub-states within `processing_statuses=unprocessed`: - pre-prepare candidate: `calculated_at: null`. - calculated: `calculated_at` is a timestamp. When the user asks for "unprepared", "draft", or "not-yet-prepared" payrolls, filter by `processing_statuses=unprocessed` and pick items with `calculated_at: null`. Then call `get_payroll` on the chosen item to confirm the roster is unmaterialized (`employees: []`, `employee_compensations` empty or absent) before invoking `update_payroll` — that combined signal is what makes the pre-prepare materialize path safe.GustoGustoPluginrequiredFinance
List Time Recordslist · Requires an existing company — if the account does not have one yet, call create_company first, otherwise this fails. Lists time records for the company over a pay period. The response is discriminated by `source`: - `source: 'native'` returns `shifts` (clock-in/out events, breaks, durations) plus `workers`, everyone who tracks time at the company, for companies on Gusto's native time tracking. `workers` covers employees and contractors alike, and lists a worker even when they have no shifts in the requested period, so use it to find the `companyMemberUuid` for someone you want to record a first shift for. - `source: 'third_party'` returns `timesheets` for companies with an active third-party time tracking integration, each carrying `shiftStartedAt`, `shiftEndedAt` and `timezone` so you can tell which day it covers. The tool eagerly paginates the third-party feed internally, so callers receive every timesheet in one response. - `source: 'none'` returns neither array; the company has not completed native onboarding and has no active third-party integration. For companies that have both native onboarding and third-party time tracking active, only the third-party data is returned, mirroring what those customers see in product. Always check `source` before reading shape-specific fields. Every shift and timesheet also carries the worker's identity: `firstName`, `lastName`, `preferredName`, `workerType` (`employee`, `contractor`, or `international_contractor`), and the worker's public id - `employeeUuid` for employees or `contractorUuid` for contractors (the other is null). Use these to label records and to join back to employee/contractor tools. Identity fields are null when a member can't be resolved. On native time tracking, a contractor's `clockInTimestamp` and `clockOutTimestamp` are only readable when the time was entered or edited by an admin; for time the contractor clocked themselves both come back null, because Gusto withholds a contractor's raw clock times from everyone but the contractor. `date` and `durationInMinutes` are always populated, so report contractor hours from those rather than treating a null timestamp as a missing shift. Employee timestamps are unaffected.GustoGustoPluginrequiredFinance
List Time-Off Requestslist · Lists a company's time-off requests (PTO, sick, vacation, etc.). When called with no filters, returns all requests. Filter by status (comma-separated - pending, approved, declined, consumed), start_date/end_date (YYYY-MM-DD, matched against the request's dates), and employee_uuids (comma-separated) to scope to specific workers. Each request includes the worker (name + uuid), status, policy (type + uuid), the per-day hours requested, and the initiator/approver. Employee and employer notes are omitted, since they are free text that may contain health information. To get full detail for one request, call get_time_off_request with its uuid. Time off may be managed natively in Gusto or by a third-party integration; this returns the company's requests either way. Note - covers domestic (US) workers.GustoGustoPluginrequiredFinance
Manage Accountmanage · Performs account-level actions on the signed-in Gusto account. Set `action` to choose what to do; only the actions listed below are supported, so do not invent others. action "get_status" — reports whether this account has set a Gusto password and can sign in on the website. Onboarding tools already withhold their gusto.com `url` until a password is set, so you need this only when the user says they set one, asks why they cannot sign in, or when a chat-signup account reaches next_step `complete` — that covers the company's setup, not website access, so mention any unset password alongside the good news. action "resend_password_setup_email" — re-sends the email that lets the user set a Gusto password and finish converting their signup into a full account. Use this only when the user says they did not get that email, deleted it, or the link expired. The email is sent automatically when signup setup completes, so there is no need to call this as a normal step. Sending is rate limited, so a repeat call inside a few minutes reports that the most recent email is still valid rather than sending another — relay that to the user instead of retrying. A successful response means the email was sent, NOT that the account is already upgraded: the user still has to open it and choose a password.GustoGustoPluginrequiredFinance
Record Timerecord · Records admin-entered time for a worker over a pay period. Routes automatically to the company's native time tracking or their connected external time-tracking partner - the caller never chooses the destination. Always preview existing hours with list_time_records and get explicit admin approval before calling this tool. On success the response carries `status`, `source`, `id`, and `resulting_hours`, and sometimes `warning`. `resulting_hours` is only populated for third-party writes; it is always null on the native path, so confirm native hours by re-reading with list_time_records rather than from the write response. `id` is the value to pass back as `shift_id` when updating the same record, but it is null whenever Gusto can't tell which shift it just wrote. That covers a native contractor, whose clock times are withheld, on any day that ends up holding more than one of their shifts, and any worker whose recorded clock-in doesn't match the one Gusto echoes back. The write still succeeded; get the shift's id from list_time_records before updating it. A `warning` means the write landed but something the caller asked for did not - relay it to the admin instead of reporting a clean success. One case where re-reading is not proof: a contractor who has no Gusto account of their own comes back from list_time_records with null start and end times even though the hours recorded, because Gusto withholds a contractor's clock times from admins unless it can confirm who last edited them. Do not re-record hours that came back successful, and do not tell the admin the write failed - a second write books the hours twice.GustoGustoPluginrequiredFinance
Run Payrollrun · Calculates and submits an existing unprocessed payroll. CANNOT create new payrolls or off-cycle payrolls. To modify payroll inputs (hours, amounts, earnings, memos, PTO) before running, use update_payroll. If the user needs an off-cycle payroll (bonus, correction, termination), they must first create it in Gusto, then return here to run it. When multiple unprocessed payrolls exist, prefer the one with a check date closest to today.GustoGustoPluginrequiredFinance
Save Company Onboarding Answersave · SIGNUP/ONBOARDING PHASE tool. Requires an existing company — if the account does not have one yet, call create_company first, otherwise this fails. Saves a single onboarding answer for the company. A saved answer can RE-ROUTE the onboarding flow — e.g. answering who_to_pay as a solo owner changes which questions remain — so any previously fetched question list is stale after a save. A successful response includes `onboarding_status`: the refreshed post-save status in the same shape as get_company_onboarding_status. Always re-derive the remaining questions from it (or re-call get_company_onboarding_status) instead of continuing through an earlier list. The re-routing is yours to handle, not the user's to hear about: do not tell them the question set or its count changed, and just ask the next question. Report a count only if they ask for one. If the answer is invalid, the response `errors` list names the expected fields and allowed values — retry with corrections. Don't invent question_keys; use the get_company_onboarding_status tool to discover valid keys and which remain unanswered. For question_key `tier_selection` (plan selection), first call get_company_onboarding_package — its plans/addOns `key`s are the valid `plan` and `add_ons` values, and it includes Gusto's recommendation to present to the user. Present that recommendation and confirm the user's choice before saving tier_selection. For question_key `industry_selection`, first call search_business_info with type "industry" and the business's own words — its results carry the verified `naics_code` to save. Present those candidates and confirm which one the user picks before saving: the pick is theirs, not yours, so do not settle on the top-ranked result yourself, and a document or profile that names the business's industry is not a pick — it describes the business, it does not choose between codes. A code or classification the user names themselves is the exception: that already IS their pick, so save it without asking them to choose again. Never guess NAICS/SIC codes; only save a code returned by that tool. The industry_selection answer also carries `is_crb`, a cannabis-related-business flag that steers package eligibility (a cannabis business cannot be offered 401(k)), so it must be set, not left blank. Ask the user a standalone yes/no question — near-verbatim: "To make sure we show you the right package options, is your business in the cannabis industry?" — and include `is_crb` (true or false) in the same industry_selection answer you save. Ask it plainly on its own; do not fold it into the industry-description question, and never set `is_crb` true without the user's explicit yes — do not infer it from the industry, NAICS code, or business name. For question_key `tax_payer_type`, only "LLC" and "C-Corporation" can elect S-corp taxation. When the user picks one of those, ask a separate follow-up — whether the business is taxed as an S corp (an elective status that passes profits through to the owner's personal return, avoiding double taxation) — and include `taxable_as_scorp` with their answer; do NOT assume false. For any other classification you don't need to ask about or send `taxable_as_scorp`; the system sets it. Bank accounts ARE connected here, with connect_bank_via_plaid: give the user the url it returns and confirm the outcome with check_plaid_connection_status rather than assuming it worked. Never tell the user the bank step has to happen in the Gusto web app while that tool is available. What cannot happen here is typing the details into chat: `company_bank_account` and `plaid_bank_account` are rejected if sent and are not listed as questions, so never ask for an account number, routing number, or bank login, and never offer to enter them on the user's behalf — even if they volunteer them or insist. Only if connect_bank_via_plaid is unavailable, send them to Gusto instead. The response also includes `next_step`, a structured cue for what to do next — follow it: `answer_questions` means the key(s) in `next_question_group` are all safe to ask this turn — ask them in a few related, digestible chunks (not all at once, not strictly one at a time), then make a SEPARATE save call per key with the answers you collected — there is no multi-answer save. The status returned by each save still lists the not-yet-saved keys, so keep saving them rather than re-asking; do not skip ahead or ask keys outside that group (`remaining_question_keys` is the full outstanding list for context; drive from `next_question_group`); `continue_in_mcp` with detail `select_plan` means call get_company_onboarding_package and then save the `tier_selection` answer; `continue_in_mcp` with detail `connect_bank` means call connect_bank_via_plaid and relay its url — do not ask for bank numbers instead; `continue_in_mcp` with detail `set_password` means the account cannot sign in yet, so no `url` is returned — follow the step's own message and never give out or invent a gusto.com link; `continue_in_gusto` means relay the returned `url` to the user — if it is absent, treat the step as `set_password`; `complete` means onboarding is fully finished — before saying anything else, present a concise recap of the onboarding answers gathered during this conversation (each question covered and its answer) so the user can confirm what was submitted, then tell them they're all set and do NOT prompt for more answers. Build the recap from what you gathered in this conversation; onboarding_status carries no questions at this point. Do not restate sensitive values in full (e.g. SSN, full bank account numbers) — refer to them without echoing the digits. You may still offer any remaining non-required questions before a `continue_in_*` step, but they don't block progressing. VOICE: helpful, not technical. Don't show the user this tool's internal names — question keys, field names, tool names, status values — describe what they mean instead, and don't volunteer counts unless asked. Where a value has a proper name, use it: "the Plus plan", not "plus". Codes the user picks from a list, like NAICS or workers' comp class codes, are content: show those verbatim.GustoGustoPluginrequiredFinance
Search Business Infosearch · Resolves a free-text description into verified, codified business-information candidates the user can choose from. Set `type` to pick what you're resolving; `query` is the user's free-text description in their own words. type "industry" — resolve what the business does into NAICS industry candidates, each with a verified 6-digit naics_code, name, and description. Use this whenever you need to set the industry_selection answer: pass the business's own words (e.g. "we run an apple orchard"), then save the naics_code the user picks with save_company_onboarding_answer. Candidates come back ranked by relevance, but ranking is a hint, not a decision — list them with their names and descriptions, ask which one fits, and wait for the answer before saving. Do not pick the top result on the user's behalf, and do not treat a document or profile that names the industry as the pick: near-identical candidates differ in how the business is treated downstream, so only the user can say which describes them. The exception is the user naming a code or classification themselves — that IS their pick, already made: check it appears in the results, then save it straight away rather than listing the candidates or asking them to choose again. Never guess NAICS codes; only save codes returned here. type "occupation" — resolve a job/role description into Bureau of Labor Statistics (BLS) occupation candidates, each with a code, name, and description (e.g. the code a reasonable- salary estimate needs). Pass the user's role in their words (e.g. "software developer" or "restaurant line cook"), present the options, and use the chosen candidate's code. Never guess BLS codes; only use codes returned here. For either type, if the list comes back empty, ask the user for a clearer description and search again. VOICE: helpful, not technical. Don't show the user this tool's internal names — question keys, field names, tool names, status values — describe what they mean instead, and don't volunteer counts unless asked. Where a value has a proper name, use it: "the Plus plan", not "plus". Codes the user picks from a list, like NAICS or workers' comp class codes, are content: show those verbatim.GustoGustoPluginrequiredFinance
Submit AI Integration Feedbacksubmit · Submits feedback about this Gusto AI integration to the team that builds it. The message is sent to the Gusto team; this does not change any account data. SCOPE: only feedback about the AI integration itself belongs here - a tool that is missing or broken; a tool whose data disagrees with what the Gusto app shows for the same thing; a capability the user expected to reach through chat but cannot; a confusing or inaccurate tool description; the assistant misreading a request or formatting a reply badly; the connector itself failing, e.g. dropping the Gusto sign-in or losing authorization mid-session. OUT OF SCOPE: feedback about what Gusto does, where chat is merely how the user happens to be talking to you - accounting-sync behavior (e.g. QuickBooks), billing and subscription terms, benefits, or a Gusto policy the user dislikes. "Expose X through the tools" is in scope; "change what Gusto does" is not. A number the user disputes is out of scope when they disagree with how Gusto calculated it, and in scope when the tool reports something different from the app. WHEN TO USE: When the user vents, suggests an improvement, reports a bug, or praises something about this integration while working in chat. Offer it after a notable action (e.g. running payroll) when the user reacts to how the assistant handled it. If you cannot tell whether the feedback is about this integration or about Gusto itself, ask one clarifying question rather than guessing; if it is still unclear after that, submit it - a misrouted note costs less than a lost one. When one message mixes in-scope and out-of-scope feedback that you can already tell apart, do not ask - submit the in-scope part and tell the user why the rest is not going through. WHEN NOT TO USE: For clearly out-of-scope feedback - do not call this tool. Tell the user plainly that this reaches only the team building the Gusto AI integration, so their feedback would not reach the team that owns it, and point them to https://support.gusto.com - name that URL rather than telling them to look in the Gusto app, since they may be in ChatGPT or Claude rather than in Gusto. Never reword out-of-scope feedback to sound in-scope. Also not for support that needs a synchronous answer, or for account problems only a human can fix on the user's own account - this is one-way product feedback, not a support ticket. RETURNS: Branch on `success`. On success, `{ success: true, status: "received", feedback_id: "<uuid>" }` - `received` means the feedback was accepted and queued for the Gusto team (delivery is asynchronous, so this confirms acceptance, not that the team has seen it yet); surface the feedback_id so the user can reference it. On invalid input, `{ success: false, error_type: "validation_error", message: "<reason>" }`. If the feedback can't be queued, `{ success: false, error_type: "delivery_error", message: "<reason>", feedback_id: "<uuid>" }` - the submission was not accepted; ask the user to retry. PREREQUISITES: A valid access token. No company context required. GOTCHAS: One-way product feedback, not a support ticket - there's no in-channel reply. `message` is capped at 5000 characters.GustoGustoPluginrequiredFinance
Submit Payrollsubmit · Internal tool for payroll submission. Use run_payroll instead.GustoGustoPluginrequiredFinance
Update Payrollupdate · Updates an existing UNPROCESSED payroll with new hours, earnings, PTO, memos, payment methods, or off-cycle settings. Use this to correct or finalize payroll inputs before running the payroll. REQUIRED WORKFLOW: Call get_payroll FIRST for any payroll you intend to update. If get_payroll returns a populated employee_compensations array, show the user the current values, get approval for the exact proposed change, then invoke this tool with the touched employees and deltas. If get_payroll returns no materialized roster (`employee_compensations` is empty or absent, `employees` is `[]`, and `calculated_at` is null), the payroll is in a pre-prepare state (its roster has not been materialized yet). In that case, invoke this tool with an empty employee_compensations array. The tool will materialize the roster and return it; you can then read the populated employee_uuids from the response and invoke this tool again with your specific deltas. CANNOT create new or off-cycle payrolls. CANNOT run or submit payroll (use run_payroll). CANNOT edit processed or submitted payrolls — this tool returns a recoverable error and no change is made. CANNOT restructure the payroll (only values of existing fields). VALUE SEMANTICS: values REPLACE existing values, they do NOT add. Sending hours: "5" sets total hours to 5, not +5. Omitted employees, compensations, and PTO entries are LEFT UNTOUCHED — this is a partial update, not a full replace. If the user's intent is additive or subtractive ("add 5 hours", "give her 2 more hours of PTO", "cut his overtime in half"), compute the new total yourself using the current value from get_payroll's response, then send the computed total — never send the delta. Example: user says "add 5 hours to Bob" and Bob's current Regular Hours from get_payroll is 40; send `hours: "45"`, not `hours: "5"`. Show the user "40 → 45" before invoking the tool. KEYING (how a submitted entry matches an existing one): - fixed_compensations and hourly_compensations: keyed by `name` (immutable identifier — must match an existing entry from get_payroll's response; do not invent names). - paid_time_off: keyed by `name` OR `policy_uuid` (supply exactly one, not both). Per-employee updatable fields: excluded (skip employee for this payroll), payment_method ("Direct Deposit" or "Check"), memo (paystub note), fixed_compensations, hourly_compensations, paid_time_off. Deductions and reimbursements cannot be edited here. Removing an employee from a payroll: set `excluded: true` on their entry. The employee stays on the roster but is not paid on this run. Send `excluded: false` to re-include. Use this whenever the user asks to "remove", "skip", "drop", or "take off" an employee for a specific payroll run. Off-cycle-only top-level fields: withholding_pay_period, skip_regular_deductions, fixed_withholding_rate. These apply to GENERAL off-cycle payrolls only (Correction, Bonus, Adhoc). Termination and transition off-cycles reject them. Use get_payroll first to check the payroll's off_cycle_reason before sending these fields. Constraints and edge cases: - Setting payment_method to "Direct Deposit" is rejected if the employee has no bank account on file. - Response currency fields (amount, hours) are returned as strings. Do not do arithmetic on them without parsing. - Follow the input_schema types for each field: amount/hours fields are strings. - Blockers: the response may include a `blockers` array when the caller has `payrolls:run` scope. Do NOT preemptively surface these to the user during the update turn. Complete the requested update and describe what changed. Blockers will surface naturally when the user attempts to run the payroll (`run_payroll`); that is the correct moment to discuss them. - Hourly editability by FLSA status: `hourly_compensations` are editable only for employees whose `flsa_status` is Nonexempt, Salaried Nonexempt, or Commission Only Nonexempt. Attempts to edit hours on any other status (Exempt, Commission Only Exempt, Owner, Unknown) are rejected with a validation_error, since hour edits on those statuses corrupt the paystub without changing pay. To adjust pay for a non-hourly employee, use `fixed_compensations` (Bonus, Correction Payment, etc.) instead. The response returns an empty `hourly_compensations` array for non-editable employees so there is no ambiguity about what is editable. Max 100 employees per call. For payrolls with more than 100 employees, invoke this tool multiple times; each call is cumulative on the roster (omitted employees are untouched, and prepare refreshes only the specified subset of the existing roster). Use `list_employees` to discover the UUIDs of employees not returned in the first materialize response.GustoGustoPluginrequiredFinance
Browse model catalogget · List AI models enabled for this account. Filtered by the workspace AI inference region (Settings → Workspace). Workspaces with Fallbacks & Guardrails may use compatible LLM/realtime entries as per-assistant engine overrides; null follows the personal then platform default. Without 'type' the models are grouped by type.FamulorFamulorPluginrequiredAI
Browse voice libraryget · Browse the text-to-speech voice library. Providers and voices follow the workspace AI inference region. ElevenLabs voices with custom rates or credit multipliers are excluded. Filter by provider (default 'elevenlabs'), language, gender, accent, or free-text search. Use the returned voice 'id' as tts_voice when creating or updating an assistant.FamulorFamulorPluginrequiredAI
Get assistantget · Fetch the full configuration of a single assistant by its ID.FamulorFamulorPluginrequiredAI
Get assistant versionget · Fetch one version including its full configuration snapshot.FamulorFamulorPluginrequiredAI
Get callget · Fetch a single call including transcript messages, typed tool calls/results, chronological events, summary, evaluation, a provider-neutral failure when applicable, and a time-limited recording_url (valid for 1 hour). Transfer-failure events expose only their safe failure object, never raw connection details.FamulorFamulorPluginrequiredAI
Get email history itemget · Fetch a complete multi-turn email conversation in chronological order, including stable thread and parent IDs, reply statuses, errors, and attachment metadata.FamulorFamulorPluginrequiredAI
List assistant versionslist · List saved configuration snapshots for an assistant (newest first).FamulorFamulorPluginrequiredAI
List assistantslist · List all AI phone assistants of the account, including their full configuration (prompt, voice, models). Supports limit/offset pagination.FamulorFamulorPluginrequiredAI
List conversation historylist · List calls, messaging, and assistant email conversations together, newest first. Failed outbound call rows include a provider-neutral failure object. Email turns with the same stable thread ID are grouped into one conversation. Filter by Audience contact, contact tags, type, direction, status, assistant, campaign, search text, or time range.FamulorFamulorPluginrequiredAI
List prompt templateslist · List prompt and flow templates visible to this workspace (platform + workspace/reseller). Same as GET /api/v1/prompt-templates. Pass the selected id as create_assistant.template_id for server-side resolution. blueprint describes surfaces, outcome, setup and avatar presentation; compatibility summarizes graph support. avatar_url is only the catalog portrait, not the virtual speaking avatar. Filters: language, theme, branch, q, has_flow.FamulorFamulorPluginrequiredAI
List supported languagesget · List the platform's assistant language catalog ({ code, label }, ISO-639-1). Use the codes for an assistant's primary_language; secondary_languages accepts the same codes. Which codes are effectively selectable also depends on the assistant's TTS/STT/realtime models.FamulorFamulorPluginrequiredAI
Account Contextaccount · Return privacy-safe Wazu connection, effective actor, active data scope, and available capability information. Does not return email, phone number, raw user ID, organization ID, credentials, or payer identifiers.WazuWAZUPluginrequiredProductivity
Explore Hive Mapmap · Return a bounded Hive Map of related Wazu evidence as nodes and edges in an explicit authorized personal or cohort scope. Hydrate selected nodes with get_item.WazuWAZUPluginrequiredProductivity
Get Evidence Itemget · Hydrate one authorized Wazu evidence item by ID after search or Hive Map discovery. Use this authoritative item record before quoting a search snippet.WazuWAZUPluginrequiredProductivity

Tool Explorer FAQ

What is Tool Explorer?

Tool Explorer indexes the callable tool names and descriptions attached to public registry profiles. It is useful for seeing what agents can actually invoke, not just which profile exists.

How do category and verb filters work?

Category filters use the live registry category rollup. Verb filters use the public tool insights rollup, so the page stays backed by the same read models as the tracker charts.

Why do auth requirements matter?

Auth requirements show whether a tool is likely usable without account connection, requires authentication, is private, or is unknown in the current snapshot.