Sheet 05.5 — Field note

Where the page is ahead of the tool

The same clip search answers a person through a page and an agent through three MCP tools. One query run both ways, and a list of what the person gets that the agent cannot reach yet. The tools have a few things the page lacks too.

Published
Reading time
4 min read
Drawn by
E. Knuth

Type “a small airship inside a hangar with men working under the nose” into the search box at clip-portal.eknuth.dev. You get a grid of cards. Each card is a frame from a film, with the title, the year, and the second it was taken from. The first one is a 1931 film at 1 minute 38 seconds. Click it and the player opens seeked to that second. Drag along the strip under the player and the frame under your cursor changes in about a quarter of a second. Click Add and the clip goes into a set.

Now point an MCP client at clip-portal.eknuth.dev/mcp and call search_clips with the same words. MCP is the protocol that lets a model call a server’s tools. The answer is JSON: ten rows, each with a film id, a title, a year, a second, a score, a sprite sheet URL, a rectangle to crop from that sheet, and a deep link to the page. Under the rows is a judgement object that says whether the best score cleared the floor a real match has in this corpus.

Same search function. Same index. The person and the agent get different products.

What the person has

  • The frame. A card shows the matched frame in about 3.6 seconds on a throttled mobile link. The agent gets a URL and a crop rectangle. To look at the frame it needs an image tool, a fetch, and a crop, and most clients have none of the three.
  • Seek. The player opens at the second and the strip shows the seconds around it. The agent gets the deep link, which is a page, and can ask get_clip for one frame per call.
  • The set. A person picks clips into a set and opens Evaluate: film count, runtime, decade and duration histograms, how many are narrated, near-duplicate pairs above 0.92 similarity, a stratified sample, a manifest. That page is the reason to search at all. It is the licensing decision. There is no set tool. An agent asked “is this set worth buying” has no way to reach the answer.
  • Rate. A person searches a few times a minute. The tool caller gets ten searches a minute per IP, and sixty calls a minute across the other two tools. A sweep of a hundred queries takes ten minutes.

What the agent has

  • A floor. The judgement object names the floor, the top score, and whether it cleared. The page shows the same judgement as a sentence.
  • Search by frame. Send by: <filmId>:<seconds> instead of text. The tool reads that frame’s stored vector and runs the same search. The page has it too, as a “more like this” link on every card. The tool takes it as a parameter.
  • The exact policies. get_clip returns which sampling policies chose a frame and the transcript line under it. The page shows the transcript and offers policy as a filter.
  • A choice of store. store: lance answers out of the same vectors written as a Lance dataset on object storage, queried inside the model container. Same scores, same ranking, within two rows of a hundred on recall. On the policy-filtered path pgvector answers the nearest-neighbour step in 98 ms and Lance in 776. On the unfiltered path Lance wins by 135 ms. Two stores, one eval has the table.

The description is the interface

The person’s interface to search is a text box with a placeholder. The agent’s interface is the tool description. The search_clips description is 326 words. It has to explain the by form, what policy means on a result, that t on the vendor path is a clip start and will snap, and that judgement.cleared is meaningless on that path because no floor is calibrated there. Every one of those sentences is a place where the page uses a control and the tool uses prose. That prose gets no design review. It should.

Every call is traced. A span named mcp search_clips carries the tool name and a client tag, so agent traffic and page traffic separate in the same dashboard. Nothing separates them in the product yet.

What I would close first

Set tools. Add to a set, read its stats, list its duplicates, export its manifest. Four tools, all over routes the page already calls. After that, a tool that returns the matched frame as an image, so a client can look. After that, the description, rewritten as interface copy and tested the way the page’s copy is.

Three read-only tools, no auth, ten searches a minute. The corpus is 300 films, 66 hours. The gaps above are the ones I found by using it as an agent would. There are others I have not found.

END OF SHEET

More on the drawing board