Finding existing work

search and fetch are the read-only pair: find something by keyword, then read it in full. Everything they return is already reachable through list_recent and get_script; what makes them worth their own page is that they are, in one important client, the only tools available.

Why these two names

They are not Editory’s vocabulary. search and fetch are a contract OpenAI defines: two fixed names with a fixed result shape, which a ChatGPT connector can call outside developer mode when it can call nothing else. So they are implemented to that shape exactly rather than to the conventions the rest of this reference follows: the ids are prefixed strings, not the bare UUIDs every other tool takes, and the result is { id, title, text, url } rather than a card.

search

search

Search the user's Editory scripts and videos by keyword. Matches script titles and script text; a video matches on the script it was made from. Returns items with an id to pass to fetch. An empty query returns their most recent work.

Parameter	Type	Description
query required	string	Keywords to match. Pass an empty string for the most recent work.

Returns

Field	Type	Description
results always	object[]	Scripts and videos interleaved, newest first, so the most recent match leads whichever table it lives in.

Matches script titles and script text. A video matches on the script it was made from, so a video generated from a brief with no article behind it is findable by its narration.

An empty query is valid and returns the account’s most recent work, newest first. That is the right call for “what have I been working on”, and it is cheaper than a keyword the user has not given you yet.

Results interleave scripts and videos by date rather than listing all of one then all of the other, because the useful answer to “my last piece about the housing story” is whichever came last, not whichever table it lives in.

{
  "results": [
    {
      "id": "video:44444444-4444-4444-8444-444444444444",
      "title": "Housing costs",
      "url": "https://editory.news/videos/44444444-4444-4444-8444-444444444444",
      "text": "Video: planned. Rents rose again this year…"
    },
    {
      "id": "script:33333333-3333-4333-8333-333333333333",
      "title": "Housing costs",
      "url": "https://editory.news/scripts/33333333-3333-4333-8333-333333333333",
      "text": "Script: completed. Rents rose again this year…"
    }
  ]
}

fetch

fetch

Retrieve the full contents of one Editory script or video, using an id returned by search. A script returns its text; a video returns its status, links and the narration it was built from.

Parameter	Type	Description
id required	string	An id from search, e.g. "script:0f2c…" or "video:9ab1…".

Returns

Field	Type	Description
id always	string	The id that was fetched, echoed back with its prefix.
title always	string	Falls back to a dated placeholder when the item has no title yet.
text always	string	The full document: a script's text, or a video's state and the narration it was built from.
url always	string	The item's page in Editory.
metadata	object	Flat string map: type, status, stage, created_at, and rendered_url where there is one. Absent fields are omitted, not empty.

Takes an id from search. The prefix is what tells the two apart:

Id	Returns
script:<uuid>	The script’s full text, plus its status in metadata
video:<uuid>	The video’s status, its rendered URL if one exists, and the narration it was built from

A bare UUID with no prefix is also accepted (scripts are tried first, then videos), so an id read off a /scripts/<uuid> link works. A prefixed id that misses is an error rather than a fallback: script: on something that is not a script is a wrong id, and answering about a different object would be worse than saying so.

A planned video is finished, not pending

fetch on a video whose status is planned says in its text that the cut is assembled and watchable and that no mp4 has been rendered. That is the finish line for anything created over MCP (the endpoint does not render), and “planned” reads like “not done” to a model that has not been told otherwise.

Using them from ChatGPT

ChatGPT’s developer mode gives a connector the whole tool surface: scripts, videos, editing, everything else in this reference. Without it, a custom connector is restricted to search and fetch, so those two are what a default ChatGPT connection can do: find work, read it, quote it, link to it. Making something new needs developer mode, or one of the other clients in Connect.

Both tools are read-only and annotated as such, so a client that auto-approves read-only tools will not prompt for either.