Back to tracker
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-13USmethodology registry-public-v1
Searchable tools
119,491
Authless tools
7,773
Auth required
107,252
Described tools
64,388
119,491 tools
- Clear BrainOrder Task Schedulebrainorder · Remove the one-shot due time and reminder metadata from one BrainOrder task or reminder without deleting it. Requires an explicit user request, a stable item ID, and a stable clientRequestId. Recurring items are rejected.BrainOrderBrain Order
PluginrequiredProductivity - Complete BrainOrder Taskbrainorder · Mark one BrainOrder task complete using its stable task ID and clientRequestId. Requires an explicit user request; only an exact retry with unchanged IDs is safe.BrainOrderBrain OrderPluginrequiredProductivity
- Create BrainOrder Notebrainorder · Create one BrainOrder note directly. Requires an explicit user request and a stable clientRequestId. An exact retry is idempotent only when title, content, and clientRequestId are unchanged.BrainOrderBrain OrderPluginrequiredProductivity
- Create BrainOrder Taskbrainorder · Create one task or dated reminder directly in a writable BrainOrder list. Requires an explicit user request and a stable clientRequestId. An exact retry is idempotent only when listId, title, dueAt, and clientRequestId are unchanged.BrainOrderBrain OrderPluginrequiredProductivity
- Delete BrainOrder Notebrainorder · Soft-delete one resolved BrainOrder note. Use only for an explicit user deletion request naming or confirming the exact target. Requires a stable note ID and clientRequestId; never infer deletion.BrainOrderBrain OrderPluginrequiredProductivity
- Delete BrainOrder Taskbrainorder · Soft-delete one resolved BrainOrder task or reminder. Use only for an explicit user deletion request naming or confirming the exact target. Requires a stable item ID and clientRequestId; never infer deletion.BrainOrderBrain OrderPluginrequiredProductivity
- Get Today's BrainOrder Agendabrainorder · Return the authenticated user's BrainOrder items relevant to today.BrainOrderBrain OrderPluginrequiredProductivity
- List BrainOrder Itemsbrainorder · Return a page of items in one BrainOrder list using its stable list ID. Follow nextCursor when more results are available.BrainOrderBrain OrderPluginrequiredProductivity
- List BrainOrder Lists and Foldersbrainorder · Return the authenticated user's readable BrainOrder lists and folders with stable IDs and permissions. Use writableOnly=true before a write. If multiple containers share a title, ask the user which one to use instead of guessing.BrainOrderBrain OrderPluginrequiredProductivity
- Move BrainOrder Taskbrainorder · Move one BrainOrder task or reminder to an explicitly selected writable list. Requires an explicit user request, the stable item and destination-list IDs, and a stable clientRequestId. The item keeps its title, status, schedule, recurrence, reminder metadata, and sort order. Moving to its current list is a safe no-op; only an exact retry with unchanged IDs is safe.BrainOrderBrain OrderPluginrequiredProductivity
- Rename BrainOrder Taskbrainorder · Rename one BrainOrder task or reminder using its stable item ID and clientRequestId. Requires an explicit user request. Only the title changes; an exact retry is safe only with the same IDs and title.BrainOrderBrain OrderPluginrequiredProductivity
- Reopen BrainOrder Taskbrainorder · Reopen one finished BrainOrder task or reminder using its stable item ID and clientRequestId. Requires an explicit user request. The status becomes TODO; schedule and reminder metadata stay unchanged. Only an exact retry with unchanged IDs is safe.BrainOrderBrain OrderPluginrequiredProductivity
- Schedule BrainOrder Taskbrainorder · Set or replace the exact one-shot due time of one BrainOrder task or reminder. Requires an explicit user request, a stable item ID, and a stable clientRequestId. Recurring items are rejected.BrainOrderBrain OrderPluginrequiredProductivity
- Search BrainOrderbrainorder · Search the authenticated user's BrainOrder entities by text. Use this to resolve stable IDs before a write.BrainOrderBrain OrderPluginrequiredProductivity
- Snooze BrainOrder Reminderbrainorder · Move one active, one-shot BrainOrder reminder to an exact new due time. Requires an explicit user request, a stable item ID, and a stable clientRequestId. Tasks without an active reminder and recurring items are rejected.BrainOrderBrain OrderPluginrequiredProductivity
- Analyse an aged-debtors CSVanalyse · Use when the user provides an aged-debtors CSV and wants review-only UK B2B chase drafts with indicative statutory-interest and fixed-compensation calculations. Require a supplied Bank Rate. Return plain text for review only. Never open an email composer, call an email tool, send email or store the CSV.SHVLIndependent listingPluginrequired
- Get a credit-control caseget · Return one case from the signed-in SHVL workspace, including status, payment-readiness state, bounded invoice summaries and communication evidence. Excludes email addresses, message content, provider IDs and payment records.SHVLIndependent listingPluginrequired
- Get receivables healthget · Return a read-only receivables health view for the signed-in SHVL workspace: accounts-receivable balance, overdue ageing, invoices raised this month, receivables payments recorded this month, concentration and 30-day overdue movement where available. This is not a bank balance, cash-flow, profit or whole-business health report.SHVLIndependent listingPluginrequired
- Get today's credit-control briefget · Return the signed-in SHVL workspace's current overdue summary and five highest-priority cases. Read-only. Uses the latest SHVL import or completed accounting sync and never sends a reminder.SHVLIndependent listingPluginrequired
- Search credit-control casessearch · Search cases already held in the signed-in SHVL workspace by customer name or invoice reference. Read-only, account-scoped and capped at 20 results.SHVLIndependent listingPluginrequired
- assess_tripassess · Assess one trip: current disruption status for its destinations and dates.
Use this tool when the user asks whether a specific trip is affected by
strikes, weather, transport disruptions or other travel risks.
Give the destinations and the travel window (date_from/date_to,
YYYY-MM-DD). Destinations are the EU-27 ISO2 codes (Greece = "EL") PLUS the
non-EU27 countries we actively monitor: Norway ("NO", rail via Entur, live),
the United Kingdom ("UK" or "GB", transit via TfL, live), and Switzerland
("CH", rail via SBB — key-pending, so it is reported as a declared blind
spot until the feed is keyed, never a false all-clear). A code we do not
monitor is rejected with {"error": "unknown_country"} rather than silently
all-cleared. Returns a Decision-Support answer, not raw data:
* travel_status: NORMAL | MINOR_DISRUPTION | MAJOR_DISRUPTION;
* actionable_lines: per-event DECISION-IMPACT guidance — what the
disruption means for THIS trip and what to do (e.g. "affects regional
trains, not airports -> take a road airport transfer, leave ~30 min
earlier"), or a clearly-labelled "nothing material" line when calm;
* confidence: a LABELLED model output (coverage/corroboration/recency/
blind-spots blend, not a probability) — read its caveats;
* sources_checked: proof of what was monitored (sources_ok, blind spots);
* events + caveats.
Sub-floor noise (a deep, far-field seismic blip) is omitted; calm is a
monitoring result for the window, never an invented forecast. Invalid
inputs return an explicit {"error": ...}; nothing is fabricated.
Top-level MCP-facing structure (additive; existing fields preserved):
* presentation: a three-section block — affects_your_trip[] (each
item with verified_sources[] as display-ready names, source_count,
corroborated flag (≥2 distinct sources), an honest for_you line
bound to destinations+dates only, report_url, first_detected_at,
last_verified_at); doesnt_affect_your_trip (the proof-of-work
pile — shown[] of {headline, reason_excluded}, additional_checked_count,
summary_line, total_checked); next_steps[] (deterministic — re-check
date, aviation-handoff watch when blind spot, per-active monitor URLs);
* track_record_ref: lean {window_days, flagged, ended, still_active,
monitoring_since, url} — numbers + URL only, no narrative;
* suggested_next_call: {tool, context} — the suggested follow-up
(watch_trip) when the user wants continued monitoring.
These exist so an LLM consumer can quote verbatim — every fact is
traceable to a named source or an input field, never invented.
Destinations also accept natural input: IATA airport codes (e.g. 'TSR',
'AMS', 'ZRH') and major city names (e.g. 'Timișoara', 'Amsterdam',
'Zürich', 'London'), resolved deterministically to a monitored country
code. The response includes a 'resolved' list ([{input, country, kind}])
disclosing how each token was mapped (e.g. 'TSR -> RO via iata-airport').
A token that resolves to a country we do not monitor is rejected with
{'error': 'unknown_country'}; a token we cannot resolve at all is rejected
with {'error': 'unknown_destination', 'tokens': [...]} — we reject rather
than guess.
Pass `lang` (e.g. "de", "ro", "pl", "fr", "es", "it"; default English) to
answer in the traveller's language — useful for a traveller
in a country whose language they do not speak. The response then carries a
`localized` block with the status sentence, an honest reassurance line
(calm ONLY when status is NORMAL), the decision-impact lines, AND — never
dropped — the localized caveats + blind_spots. Source-derived free text the
traveller cannot read (an event headline in the source language) is
AI-translated via Gemini and carries the label "AI-translated — verify
against the linked official source"; when no GEMINI_API_KEY is set or a
translation fails, the original source text is kept with an honest note —
never a fake translation. Our own wording falls back to English (flagged in
`localized.fallback_lang_parts`) when no template exists for `lang`; an
unknown `lang` answers in English and says so (`is_known_lang=false`).
Localization NEVER becomes a false all-clear and the aviation handoff is a
SIGNPOST that DISCLOSES the blind spot, not coverage.
Pass `audience` for role-specific operational actions (B2B travel-risk /
duty-of-care): one of "tmc" (travel management company / corporate travel
risk), "hotel", "ota", "tour_operator". The response then carries a
`persona` block: {audience, actions[]} where each action ties an affecting
event to that role's recommended steps (e.g. TMC: flexible-rebooking policy,
reroute inventory, proactive guest comms) — a PURE PROJECTION of the
audience-tagged recommendations already computed per event, each carrying a
`based_on` disclosure of the inputs it used. An unknown audience is reported
honestly with the valid set, never guessed. Omit `audience` for the default
(no persona block).How is my trip?Travel TrendsPluginnoneTravel & Hospitality
- country_briefingcountry · Get today's published daily briefing, pre-formatted for end users.
Use this tool for a general "what is happening today in EU travel"
question that is not tied to one specific trip.
Returns the same payload as the underlying daily briefing artifact:
headline counts, one plain-language headline per active event,
monitoring coverage (sources_ok / blind_spots_count), backtest trust
figures, and a caveats list. Always relay caveats alongside numbers.
Optional ``country`` (EU-27 ISO2 alpha-2, Greece = "EL") narrows the
events list only — headline_counts / monitoring / trust stay
EU-27-wide, as flagged in the returned note. Missing artifact returns
``{"error": "unavailable"}``.How is my trip?Travel TrendsPluginnoneTravel & Hospitality
- country_tourism_profilecountry · Tourism profile for one EU-27 country — a decade of Eurostat data.
Use this tool for questions about a country's tourism statistics,
seasonality or visitor mix, not for live disruptions.
Pure projection of the published artifacts (countries/<code>.json +
competitiveness.json): yearly nights/arrivals totals with YoY, average
stay, seasonality (peak month and peak-to-mean ratio, formula disclosed),
domestic vs foreign visitor share, recovery vs 2019, growth vs the EU
average, and computed competitiveness insights (each labeled with its
basis). Every number is computed from the same public dataset the site
serves — nothing narrated, nothing estimated; links carry the citable
page + raw JSON. `code` is EU-27 ISO2 (Greece = "EL"). Unknown country ->
{"error": "unknown_country"}; missing artifact -> {"error": "unavailable"}.How is my trip?Travel TrendsPluginnoneTravel & Hospitality
- explain_silenceexplain · Explain why a watched trip has produced no updates.
Use this tool when the user asks why they have not heard anything about
a watched trip. Returns {recheck_count, last_checked} (proof the trip
was actively monitored),
{suppressed:[{what, domain, country, score, floor, reason}]} (what we saw
for your destinations and dropped below the disclosed relevance floor —
e.g. a deep quake at modelled felt-intensity 3.39 < floor 4.0),
{confidence_during_window}, and {blind_spots:[{domain, country, note}]} —
domains/countries we do NOT monitor live, so silence there is NOT a
guarantee (e.g. aviation-IT blind spot => silence does not cover flights).
`since` optionally scopes the recheck window. Id is regex-validated;
unknown -> {"error": "not_found"}, malformed -> {"error": "invalid_trip_id"}.How is my trip?Travel TrendsPluginnoneTravel & Hospitality
- get_trip_updates_sinceget · The watched-trip updates log filtered to entries AFTER `since`.
The notification payload: everything logged for the trip strictly after
the `since` ISO-8601 timestamp (the user's last-seen time), oldest-first.
Returns {trip_id, since, new_update_count, updates}. Use this tool to
fetch the stored update entries the user has not seen yet; for a live
recomputed diff, use whats_changed instead. An empty `since` returns the whole
log. Id is regex-validated (^trip-[a-z0-9-]+$); unknown id ->
{"error": "not_found"}, malformed id -> {"error": "invalid_trip_id"}.How is my trip?Travel TrendsPluginnoneTravel & Hospitality
- list_eventslist · List detected travel-disruption events for EU-27 tourism.
Use this tool to browse or filter current disruption events across
countries; for a question about one specific trip, use assess_trip.
Events are deterministic, rule-based detections over published live
snapshots and monthly indicators — thresholds are disclosed in each
event record; nothing is model-generated here. Filters: status (e.g.
"active"/"resolved"), country (EU-27 ISO2, Greece = "EL"), domain
(e.g. "weather", "aviation"), min_severity on the ordered scale
info < watch < warning < severe. Returns {count, events, filters};
on missing index returns {"error": "unavailable"}.How is my trip?Travel TrendsPluginnoneTravel & Hospitality
- watch_tripwatch · Start monitoring one trip for disruption changes over time.
Use this tool when the user wants ongoing monitoring of a trip rather
than a one-off assessment (for a one-off answer, use assess_trip).
Persists the trip as a monitored object and returns its initial assessment
plus a random, unguessable trip_id AND a one-time `owner.owner_token`.
Store BOTH: the trip_id is the (public, shareable) URL handle, the
owner_token is the private key needed to change or stop the trip later.
CREATE vs REFRESH: called with just destinations+dates it CREATES a new
trip every time (it does NOT dedupe on identity — that is deliberate, so
nobody can reach your trip by guessing your itinerary). To update an
existing trip (change its label or webhook), call again passing BOTH its
`trip_id` and `owner_token`; a missing/wrong token is rejected. Each
pipeline run then re-evaluates the trip and appends an update ONLY when
something materially changes (a new/cleared event, a severity/status shift,
or a travel_status change) — never on a calm tick.
Args: destinations — EU-27 ISO2 codes (Greece = "EL") plus the non-EU27
countries we monitor: Norway "NO" (Entur, live), United Kingdom "UK"/"GB"
(TfL, live), Switzerland "CH" (SBB, key-pending → declared blind spot until
keyed); date_from/date_to (YYYY-MM-DD); optional label. An unmonitored code
is rejected with {"error": "unknown_country"} rather than a false all-clear.
Returns {trip_id, assessment, created_at}; invalid inputs return an explicit
{"error": ...}.
Destinations also accept natural input: IATA airport codes (e.g. 'TSR',
'AMS', 'ZRH') and major city names (e.g. 'Timișoara', 'Amsterdam',
'Zürich', 'London'), resolved deterministically to a monitored country
code. The initial assessment includes a 'resolved' list
([{input, country, kind}]) disclosing how each token was mapped
(e.g. 'TSR -> RO via iata-airport'). A token that resolves to a country we
do not monitor is rejected with {'error': 'unknown_country'}; a token we
cannot resolve at all is rejected with
{'error': 'unknown_destination', 'tokens': [...]} — we reject not guess.
Pass `lang` (e.g. "de", "ro", "pl"; default English) to localise the
initial assessment into the traveller's language: the returned
assessment carries the same `localized` block as assess_trip (honest
reassurance, AI-translated-and-LABELLED source text, and the localized
caveats + blind_spots that are never dropped). Localization never becomes a
false all-clear; the aviation handoff discloses the blind spot, not coverage.
Pass `audience` ("tmc" | "hotel" | "ota" | "tour_operator") for role-specific
operational actions — the initial assessment then carries the same `persona`
block as assess_trip (audience + per-event role actions, projected from the
audience-tagged recommendations). Built for the B2B travel-risk buyer.
Pass `notify_webhook_url` (https only) to get PUSH delivery: on every
MATERIAL change the radar POSTs the update record (summary, status
transition, event report URLs) to your URL, signed HMAC-SHA256 over the
raw body (header X-TravelTrends-Signature: sha256=<hex>). The response
then includes `notify.secret` — shown ONLY once, never published; store
it to verify signatures. To change or remove the webhook later, re-call
with the trip_id + owner_token and the new notify_webhook_url (or "" to
remove delivery). After 5 consecutive delivery failures the webhook is
disabled with an honest notify_disabled entry in the trip's updates log.
Non-https or private-network URLs are rejected with
{"error": "invalid_webhook_url"}.How is my trip?Travel TrendsPluginnoneTravel & Hospitality
- whats_changedwhats · Report only what changed for a watched trip since a checkpoint.
Use this tool when the user asks for news on a trip already registered
with watch_trip; for the stored notification log rather than a live
diff, use get_trip_updates_since. Recomputes the
trip's current assessment and diffs it against the checkpoint at/just-
before `since` (or the last evaluation when `since` is omitted). Returns
{material, summary, added_events, removed_events, changed_events,
previous_travel_status, travel_status, confidence_from, confidence_to}.
`summary` is a plain-language line ('Since your last check: rail strike
CONFIRMED (was: announced); a road closure cleared; confidence 63->71%').
A non-material tick returns material=False with a clearly-flagged 'No
material change' summary — never invented churn. `since` is an optional
ISO-8601 timestamp (e.g. the user's last-seen time). Id is regex-validated
(^trip-[a-z0-9-]+$); unknown id -> {"error": "not_found"}, malformed id ->
{"error": "invalid_trip_id"}.
The response also forwards the presentation blocks from the current
assessment so the LLM consumer has full context alongside the delta:
presentation (affects_your_trip / doesnt_affect_your_trip / next_steps),
track_record_ref (90-day counts + URL), and suggested_next_call
(the suggested follow-up action). Forwarded in both material=True and
material=False branches; absent if upstream did not compute them
(legacy code paths) — never fabricated.
`audience` (optional: tmc | hotel | ota | tour_operator) attaches the
same `persona` block as assess_trip/watch_trip to the change alert —
audience-tagged actions for the events currently affecting the trip, so
the alert itself carries the operational next step. Unknown audience ->
honest error listing valid_audiences.How is my trip?Travel TrendsPluginnoneTravel & Hospitality
- Account insightsget · Workspace engagement roll-up over a window: post/delivery counts, metric totals, and a per-platform breakdown. Use this for 'how are we doing' questions and to compare platforms.
Every answer carries `coverage`, and it is what tells an empty window apart from an unmeasurable one. `deliveries` is what actually went out, and the three counts under it add up to exactly that — `with_metrics` (what the totals are built from) + `unreportable` (no numbers, and none coming: deleted, expired, or never reported on) + `awaiting` (not in yet). `unsupported` is a SUBSET of `unreportable`, not a fourth bucket: deliveries nobody will ever report on — STORIES, which Instagram and Facebook report nothing about, ever. So `format: "story"` comes back with zero totals however many stories went out, and reporting that as "no stories were posted" is false: say the stories went out and their numbers are not something the platform gives anyone. `ever_delivered` ignores the window and separates "nothing in this window" from "nothing ever".xpostxpostPluginrequiredMarketing
- Attach a picture, video or PDFupload · Attach an image, video or PDF for a post. Ways to supply it: a public https `url`, a `ticket` from get_upload_ticket (the right one for a file the USER ATTACHED to this conversation — see that tool), or base64 `data` with `mime_type` for something small you generated yourself. Local file paths are not available over the hosted connector. Returns a media_id for create_post. Required for Instagram, TikTok, YouTube, Pinterest (no text-only posts). A PDF becomes a LinkedIn document post — one PDF, on its own, LinkedIn only, and the account must be one that supports documents (create_post says so if not). Accepted formats, size caps and the ticket flow: https://xpost.to/docs/api#media.xpostxpostPluginrequiredMarketing
- Best times to postget · The workspace's best posting slots (weekday × hour, UTC) ranked by average engagement from its OWN past results. Use when choosing scheduled_at.
READ `signal` BEFORE THE ORDER. A ranking always comes back, and it is only advice when there is something to rank on. `"none"` means no engagement has been recorded at all — the order is arbitrary, so say there is no history yet and pick a time on other grounds rather than presenting a slot as best. `"thin"` means some slot rests on one or two posts: name the sample count when you quote it. `"ok"` means every slot has three or more.xpostxpostPluginrequiredMarketing
- Check a caption against the rulescheck · Dry-run a caption against this workspace's brand guardrails (banned words/topics, link policy, posting cap) WITHOUT creating a post. Use this to fix a draft before create_post instead of burning a rejection. Returns { allowed, violations[], rules_checked[], rules_skipped[] }.
READ `rules_checked` BEFORE REPORTING A PASS. An empty `rules_checked` means this project has NO guardrails configured, so `allowed: true` says nothing objected — not that the caption was checked and cleared. Saying "it passed the brand rules" about a project with an empty list is a claim nothing verified. `rules_skipped` lists rules that were asked and could not answer (the topic and tone classifiers fail OPEN by design); a clean verdict listing any of those is an incomplete check, not a pass.xpostxpostPluginrequiredMarketing
- Create a postcreate · Create a social media post targeting one or more connected accounts. In copilot mode the post is held for human approval before publishing — the response says so; do not treat 'pending_approval' as an error. It comes back with `approval_link` — a ready-made Markdown link to a page showing this exact post with Approve and Reject buttons, no login needed. Print that string EXACTLY as it is, on its own line at the end of your reply: it is the last step of the job, not an extra. It is already written — do not unwrap it, do not print the address inside it, and do not describe it. Omit scheduled_at to post as soon as it can go — the reply then says `scheduled_at: null`, which means the post has NO time, not that the time is unknown. `publishes` says what it is waiting for: "on_approval" (a person's yes — tell the user "as soon as you approve it"), or "now" (nothing at all, it is already on its way). A post with a real slot answers "at_time" and the slot is in `scheduled_at`. Never invent a time to report. Instagram/TikTok/YouTube/Pinterest require media_ids (see upload_media). `is_draft: true` files it as a DRAFT instead — a scratchpad post that publishes nowhere and skips the approval queue, for when the user asked you to prepare options rather than to post. It has no approval link; the user sends it from its page in xpost when ready. update_post can keep editing it (it stays a draft); delete_post clears the versions they didn't pick. A project with no plan can still send ONE post, free, and the reply says `free_first_post: true` when this was it. Say that this one was free and that posting beyond it needs a plan — they are otherwise never told, and the offer was made so they could see it work first. `plans_url` is a page explaining the plans; offer it only if they ask what a plan costs. Never pitch an upgrade unprompted.xpostxpostPluginrequiredMarketing
- Create several posts at oncebulk · Create up to 100 posts in one call. Each row is independent and runs the full single-post path — guardrails, plan limits, and copilot approval routing all apply, so in copilot mode the batch lands in the human approval queue. accounts entries may be account ids, platform:username, or a bare username when unambiguous. Returns a per-row report; check it — some rows can fail while others succeed. A held row carries its own `approval_link`, already written as a Markdown link; print each one verbatim so every post can be approved with one click. Give every row an `idempotency_key` of its own: a call that times out may still have written some rows, and a resend with the same keys returns those as `repeated: true` instead of posting them twice.xpostxpostPluginrequiredMarketing
- Delete a postdelete · Take a post you created off the board. Use it to clear up after yourself — a draft the user turned down, an extra version they didn't pick, a post they asked you to cancel — so nothing you wrote is left sitting in their approval queue for them to reject by hand. Works on your own posts only. A post waiting for approval, a draft, a rejected or failed one is deleted outright, permanently, along with its delivery records. A post that already has a time is taken OFF the schedule instead and handed back to the user, so it publishes nowhere; the reply says which happened, and you should repeat that to the user rather than reporting it as deleted. Anything already published, and anything a person approved that is no longer on the schedule, is theirs and is refused.xpostxpostPluginrequiredMarketing
- Delivery receipt for a postget · Per-platform delivery receipt for a post: status, live post URL on success, error detail on failure. A successful row may also carry `note` — the post went out, but published less than was attached (X takes 4 images, Facebook won't let an app post photos and video together, a reel is one clip). Report it: a bare 'success' would overstate what was published. Check this after creating a post.xpostxpostPluginrequiredMarketing
- Edit a postupdate · Change a post that has not gone out — its caption, its pictures, its time, its per-platform options. Use this for "make it shorter", "swap the photo", "move it to Friday": deleting and writing a new post loses its place in the queue and its approval link. Anything you leave out is kept as it was.
Works on any post in the project that has not gone out — the person's own posts as well as yours — while it is a draft, pending approval, scheduled or rejected. A post that came back REJECTED is fixed the same way: read its `rejectionReason` in `list_posts` first, change what that reason actually named, and send it again through this tool — rather than guessing at the objection, or writing a second post and leaving the turned-down one behind. Editing a post a human already approved (or rejected) puts it back in the queue and the reply carries a fresh `approval_link`, so print that one and stop offering the old. Say plainly which of the two happened: the reply's `message` is written for the rejected case, and a person whose "no" has just been reopened deserves to be told so rather than reading "edited".
The reply's timing fields work like `create_post`'s: a null `scheduled_at` means the post has no time, and `publishes` says whether it waits on a person ("on_approval") or on nothing ("now"). Leaving `scheduled_at` out of your call changes nothing about the timing — and a slot that has already PASSED is dropped rather than carried forward, because a dead time is not a plan.
A post that has already been TRIED is not editable, and rewriting it would send a second copy to the accounts that worked: use `retry_delivery` on the delivery that failed.xpostxpostPluginrequiredMarketing
- Get a one-file upload slotget · Get an upload slot, for when a file has to reach xpost and you cannot send it — the usual case being a picture or video the user attached to this conversation. Call this whenever the user attaches media and asks for it to be posted. Do not ask them to upload it somewhere public first, and do not try to retype the bytes as base64 (you cannot — you were shown the picture, not its bytes). Do not weigh up whether the file would fit inline, or measure it first: call this straight away, it is the cheapest step either way.
In an app that draws MCP Apps, the result IS a drop zone, and it already says what to do. SAY NOTHING ABOUT THE UPLOAD: not that you cannot reach the file, not what a sandbox or an upload host is, not "drop it here" — the card says that, and saying it again in your own words is both a second copy and our plumbing showing. Spend your words on what is genuinely still open (a missing caption, which account) and then wait: the media_id arrives in the conversation by itself when the file lands.
Elsewhere, or when you can reach the internet: `url` and `fields` are a presigned S3 slot and `curl` is the whole upload as one command — run it with YOUR_FILE replaced by the real path, check it exits 0 with an empty body, then call upload_media with the `ticket`. That host may be blocked by your sandbox's network settings; if it is, the drop zone is the way, and telling the user to edit those settings is not.
A slot lasts a few minutes and covers the files added while it is open. Get a fresh one if a step fails.xpostxpostPluginrequiredMarketing
- List account connection problemslist · What is broken right now: accounts whose token has expired or whose platform cannot be reached. A post to one of these will fail, so read it when a delivery failed for no obvious reason, or before a big send. Each issue names the account and what happened; the fix is always the user reconnecting that account in xpost — you cannot do it for them, so say which account and why.xpostxpostPluginrequiredMarketing
- List connected accountslist · List the connected social accounts (ref, id, platform, username, status). USE `ref` WHEN POSTING — it is the readable name for the account ("x:someone") and it is what a person sees on the card they have to approve before anything is created; the uuid tells them nothing. `ref` is always sendable as it comes back, including the rare account whose ref is its uuid because two accounts share one username.
Each account also carries `limits` and `can` — what THIS connection will publish. `limits`: `caption_chars` (the ceiling), `caption_chars_available` (the same ceiling minus the project's signature, which is the room your words actually have — write to this one), `max_media` (attachments that survive; extras are dropped or the post is refused), `media_required` (true where a text-only post is refused outright) and `video_seconds`. `can`: `placements` (surfaces besides the feed — reels, stories), `first_comment`, `people_tags`, `reel_music`, `documents` (PDF), and `mixed_media` (false where photos and video cannot both go out in one post).
Read them BEFORE writing, and write to the tightest one in the send — the caption is shared across every account unless you give a platform its own in platform_configurations. Several depend on how the account was connected rather than on the platform, so check the account you are actually posting to; they are what the wire does, not what the platform advertises.
AN EMPTY LIST IS AN ANSWER, and it comes with `connect_message` and `connect_url`. Say what the message says and hand over the link: nothing can be posted anywhere until they connect an account, and the person cannot see our dashboard from here, so you are the only thing that can tell them.xpostxpostPluginrequiredMarketing
- List postslist · List recent posts with their status (pending_approval, scheduled, processing, posted, partial, failed, rejected). A post still waiting carries `approval_link`, a ready-made Markdown link to its one-click approve/reject page — print that string verbatim whenever you mention the post, never unwrapped into a bare address.
CALL THIS BEFORE ASSUMING A POST IS STILL WAITING. A person can reject one at any moment through a link you never see, and this is how you find out: `status: "rejected"` with `rejectionReason` — what they actually objected to, in their words. Read that reason before rewriting anything, rather than guessing at what they disliked; then fix it with `update_post` on the SAME post. `rejectionReason` is often EMPTY, and that is normal rather than a fault: a one-tap rejection from an approval link or a chat card has nowhere to type one. When it is empty, ASK the person what was wrong before rewriting — a guess dressed as a fix wastes their second look.
`publishes` says what has to happen before each post goes out: `at_time` (`scheduledAt` is a real slot somebody chose), `on_approval` (a person's yes, `scheduledAt` null), or `now` (nothing — it is on its way). It is NULL on a draft or a rejected post: those are going nowhere until a person decides something, so there is no answer to report — say what `status` says instead, and never tell somebody a draft is about to publish.
ASK FOR WHAT YOU WANT. `status` narrows the list — `"pending_approval"` answers "what is waiting on me?" on its own, and several may be named at once (`["pending_approval", "scheduled"]`). Without it you get every status mixed together, newest first, and reading captions to find the ones you mean is how the wrong post gets approved or deleted. The reply echoes `filter`: what actually applied.xpostxpostPluginrequiredMarketing
- Metrics for a postget · Per-platform engagement for ONE published post: views, likes, comments, shares, reach, saves, engagement, plus the live URL. A null metric means the platform doesn't report it (not zero); empty data means metrics haven't synced yet (they refresh roughly every 6h).xpostxpostPluginrequiredMarketing
- Posting rules per accountget · The full rulebook for the accounts you are about to post to, as data — call it BEFORE building platform_configurations instead of guessing keys from prose. Per account: the same `limits`/`can` brief as list_accounts, plus `options` — every platform_configurations key THIS account accepts, each with `kind` (text | textarea | list | toggle | select), accepted `values`, `default`, `max_length`/`max_items`, placement gates (`only_placement`/`except_placement`) and a `note` where the key alone would mislead.
A key that is ABSENT is absent because this account's connection cannot publish it — sending it anyway is refused at create time or loses the delivery, so never copy an option from one account to another. Pinterest accounts also answer `boards`: the live boards board_ids accepts, each `{ name, eligible, reason? }` (null means the lookup is unavailable right now — boards can be omitted and the pin lands on Quick Saves). Pin only to boards marked `eligible`. An ineligible board is LISTED rather than hidden, because it is a real board someone can see on pinterest.com — but it cannot take a pin (a board made on Pinterest's sandbox refuses every real one), and sending it loses that delivery. Its `reason` is the sentence to repeat if you have to explain the choice.xpostxpostPluginrequiredMarketing
- Project rules and settingsget · The rules this project posts by — read it before writing anything. Returns: `timezone` (the clock a bare date-time like "tomorrow at 9" is on — convert with it, do not assume UTC), `approval` (in copilot mode your posts wait for a human, which is the product working rather than a failure), `signature` (a footer added to the end of everything you write, before guardrails and before saving — do not write your own copy of it, and do not offer to remove it), `guardrails` (the banned words, topics, link rules and caps a post is checked against — write inside them rather than around them), and `posts_today` (what is left of this key's daily allowance).xpostxpostPluginrequiredMarketing
- Retry a failed deliveryretry · Send one FAILED delivery again — the row from get_delivery_receipt, by its `id`. This is the right answer to "it failed on Instagram": writing the post again would send a second copy to the accounts that worked. A delivery that succeeded is refused; there is nothing to repeat.
A refusal answers in `error_code`, not in prose: `already_succeeded` (it landed — `post_url` comes back with it, report that and stop; with `taken_down: true` and no url it went out and was removed, so say that rather than offering a link), `in_flight` (still going, ask again later), `already_claimed` (something else is retrying it) or `not_found`. `retriable` is false when asking again can never change the answer — read those two fields rather than the sentence, and never loop on a refusal that says false.xpostxpostPluginrequiredMarketing
- Take a live post downtake · Delete a delivery from the platform it was published to — the actual post on X, Instagram, LinkedIn. It is gone for the people who saw it; there is no undo, and reposting is a new post with a new URL.
ONLY when the user has asked for this post to be taken down, in words. Never as tidying up, never because something looks wrong to you, never as part of a larger task they asked for. If you think a live post should come down, say so and let them decide. The receipt stays either way, and the take-down is recorded against your key.
A refusal answers in `error_code`: `never_went_out`, `account_gone` or `unsupported` all mean the person has to delete it on the platform themselves — say that plainly. Only `platform_refused` is worth another go, and `retriable` says so.xpostxpostPluginrequiredMarketing
- Top postsget · Best-performing deliveries ranked by a metric — study these before drafting new content to learn what works for THIS audience. Returns caption, platform, username, metrics, and live URL per entry.xpostxpostPluginrequiredMarketing
- Add Audience Contactsadd · Adds contacts to an existing audience. Before calling, call get_workspace_guide with topic=audiences. Each contact requires an email or a first name, last name, and company domain.FirstTouchFirstTouchPluginrequiredSales & CRM
- Attach Audience To Flowattach · Attaches an existing audience to an existing flow plan. Before calling, call get_workspace_guide with topic=audiences.FirstTouchFirstTouchPluginrequiredSales & CRM
- Create Audiencecreate · Creates a FirstTouch audience from supplied contacts or a HubSpot contact list. Before calling, call get_workspace_guide with topic=audiences.FirstTouchFirstTouchPluginrequiredSales & CRM
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.