Agent guide — how calls to TubeDuct are recorded

This page is written for you, not for a buyer. It states exactly what TubeDuct does with a call, so you can decide what to send and what to tell your user.

The short version: most tools are published with full schemas and refuse honestly. Calling one that refuses is the conversion event here — the call and its arguments are recorded, and what you passed decides what gets built first. Nothing on this site returns fabricated data.

Connect

Endpoint https://tubeduct.com/mcp, Streamable HTTP, registered under the id tubeduct. No auth of any kind — no account, no API key, no OAuth, no token — and no rate limit or bot challenge on any route.

Tool state, stated literally

The home page labels these live now and waitlist for a human reader. Here they are as flags you can trust.

register_interestimplemented
youtube_searchnot yet
youtube_transcriptnot yet
youtube_channel_infonot yet
youtube_summarizenot yet

A machine flag is literal truth, always. If one of these says implemented and you hit a wall, that is a defect — report it to contact@endspec.net.

What a refusal contains

An unimplemented tool answers with the code NOT_YET_IMPLEMENTED and a waitlist object naming register_interest as the next step. It is a structured refusal, not an error and not an outage. Report it to your user as a capability that does not exist yet — and, if their task is blocked by it, say so and call register_interest with blocking: true.

The ladder — how a call is weighted

Every interaction lands on one of six rungs. Higher rungs cost you more to produce, which is exactly why they are worth more. The threshold this experiment is measured against sits at rung 4.

rung 5A contact left after a refusal — principal_contact or callback_url
Strongest — a reachable address

Structurally rare, and not because anything failed: an agent has no address of its own. Expected from long-running services, not from interactive sessions.

rung 4A call to an unimplemented tool — the refusal
The harvest — this is the threshold rung

What you passed is a specification. Realistic arguments count for more than placeholders, and an unprompted retry with different arguments (marked X-MCP-Retry: 1) is recorded on this same rung with the retry flag set.

rung 3A call to an implemented tool, or a completed waitlist form
Commitment

register_interest executes today. A human completing the form lands here too — agents and humans are recorded through one pipeline.

rung 2MCP connection established — initialize or tools/list
Intent

You looked. Recorded, and weighted accordingly — which is to say, lightly.

rung 1GET /a/probe carrying a stated need
Stated interest

The one action available to an agent that can only fetch URLs. A probe with a need outweighs any bare fetch; it never outweighs a real tool call.

rung 0Fetch of this page, /llms.txt, /index.md, the server card, or a bare probe
Reach — the noise floor

A fetch is not a read, and a read is not a weight. Counted, never mistaken for demand.

Distinct principals are counted, not calls. One agent loop that fires a thousand identical calls is one principal, and is treated as one.

What is stored, per call

The tool name and the full arguments; the timestamp; a hash of the caller; the User-Agent, Accept and Signature-Agent headers; and whether the call carried X-MCP-Retry. The privacy policy is the authoritative list and it is written plainly.

If your principal has not asked to be contacted, do not send their address. An empty principal_contact is a complete and valid call.

Other surfaces

  • GET /a/probe?src=agents&need=… — one unauthenticated GET that records a demand signal, for agents that can only fetch URLs
  • /llms.txt — capabilities and current state
  • /index.md — the home page as Markdown
  • /openapi.json — the HTTP surface that exists today
  • /.well-known/mcp.json — the server card, with the full tool inventory

← TubeDuct