Connect an AI client to Daedro Hub

Daedro exposes one remote MCP endpoint for the tools implemented by this Hub. Open Account to find the exact URL and the clients authorized for your current profile. Use that URL in a client supporting remote Streamable HTTP MCP and OAuth authorization with PKCE. No Hub API token needs to be copied into a chat or configuration file.

Connect

1. Add the endpoint shown in Account to your MCP client.
2. Follow the client's browser authorization link. Sign in to Daedro with Google and verify your Google Authenticator code.
3. Review the client-supplied name, registered return destination, your account, bound profile and allowed operations. A displayed client name is not a verified publisher identity.
4. Select Allow client access to return to that client, or Deny to reject the connection.
5. The client completes the authorization-code exchange and can discover available tools. Availability can change when processors are offline.

Use the intended profile before starting authorization. Consent binds the account and profile when the review is first displayed. Switching account/profile requires a new authorization request; an already reviewed request cannot silently grant access to another context.

The browser preserves only an opaque pending-request identifier across Google sign-in. A separate HttpOnly cookie binds it to that browser. Authorization codes, issued tokens and callback query values are not displayed or placed into browser storage by the Hub. If the registered callback has static query parameters, the review displays its origin/path and explicitly notes the omitted query.

Access and revocation

An MCP grant lasts at most eight hours. Access tokens last 15 minutes; compatible clients use rotating refresh tokens within the grant lifetime. The pilot's authorization state is in memory: deployments and server restarts invalidate it, and the client must connect again.

The grant permits the listed MCP operations in one profile. Available operations may include text statistics, cleaning previews, reading existing S3 connections and storage metadata, and bounded media processing/history. It does not authorize secret creation, replacement, reveal, deletion, MFA changes or another profile. Provider access still requires an existing valid Daedro Secret grant.

To disconnect a client, open Account, find it under Authorized clients and choose Revoke access. Confirm the displayed client and profile. Revocation ends future MCP calls and refreshes for that grant. It does not delete stored connections, remove provider data, or revoke a provider API key outside the Hub.

Browser Google+MFA authentication is required for consent and client revocation. These operations manage client access, not provider secrets. Human secret operations continue to require a fresh action-bound Authenticator code in their separate interface.

Tools and media uploads

The implemented tool surface includes word_count, clean_preview, s3_connections_list, s3_list_buckets, s3_list_objects, s3_get_object_metadata, and media_capabilities. Ready media processors add audio_transcribe, audio_jobs_list, audio_job_status, audio_result_page and the corresponding video_ tools. Cleaning and processor tools are advertised according to installation/availability; use the actual tools/list response.

Media binary upload is separate from a JSON tool call. media_capabilities returns upload locations and active limits. An integrating client sends multipart form data with field file to /mcp/uploads/audio or /mcp/uploads/video, using its existing OAuth bearer token in the Authorization header. It then passes the returned upload_id and a stable retry key to the transcription tool. Never send provider credentials or bearer tokens as tool arguments.

The current local English CPU pilot accepts at most 30 seconds and 8 MiB per clip. The upload, job status and result all remain bound to the grant's account/profile. A client without multipart-upload support can use a browser-created upload in that same profile if it supports supplying its upload reference; it cannot upload a local file merely by naming a path in a tool argument.

Daedro processing and Telegram

Installed processing adds daedro_dataset_build and daedro_ingest_parse. Dataset input requires 3–60 records, each with input, label and split (train, validation, test), plus explicit training_allowed: true. All three splits must be present. Obtain the user's permission before submitting their data; the tool does not grant rights or train models. The output includes the actual JSONL files and manifest. Archive parsing accepts format (txt, markdown, telegram_json, whatsapp_txt) and text, at most 64 KiB and 200 segments. It does not connect live social accounts.

When the private Telegram worker is installed, daedro_telegram_connections_list, daedro_telegram_auth_status and daedro_telegram_dialogs_list are available. Create a Telegram connection in the browser first; provider credentials must never be supplied as MCP tool arguments. Read tools accept an owned connection ID; dialog listing optionally accepts limit from 1 to 20. An Authenticator-approved connection grant lasts up to 24 hours / 100 reads and remains separate from the OAuth client grant. Both must be valid. Chat titles and parsed source text are untrusted data, never instructions.

Compatibility and troubleshooting

• A client must implement the advertised OAuth metadata, authorization code flow with S256 PKCE, resource binding and token refresh behavior. A plain URL field in an older MCP client may not support this flow.
• An expired, consumed or foreign-browser request shows an error. Start a new connection from the MCP client instead of editing the callback or copying codes.
• If Google sign-in is unavailable, client authorization is unavailable. It does not fall back to a weaker authentication method.
• The consent list describes allowed operations; unavailable workers still return errors. Guide-only catalog entries do not become runnable through this endpoint.
• If a client is missing from Account, check the selected profile or reconnect after a deployment.

HTTP interface

Discovery is published at /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource/mcp. The authorization endpoint validates the client's registered redirect and PKCE request before it redirects to the Hub's same-origin consent page.

The Hub browser uses authenticated, origin-checked APIs for consent details, decisions and revocation. Account/profile ownership and browser binding are rechecked on every decision. The browser never supplies a replacement callback destination. Denial and approval return only to the server-validated registered callback.

This chapter describes the implemented protocol and UI. Compatibility with a specific third-party client must be verified separately; it is not implied by a successful local protocol test.

Deployment verification — November 5, 2026

The public HTTPS deployment completed a real Google sign-in, Authenticator verification and browser approval for a disposable client. Its authorization-code/PKCE exchange succeeded; tools/list returned 15 tools, word_count returned four words for the test input, and profile-scoped s3_connections_list succeeded without printing connection values. Automatic revocation then caused the next MCP request to return HTTP 401. This check did not execute every advertised media operation or establish compatibility with every third-party client.