Connecting an AI Agent to AIOZ Stream Without an MCP Server

AIOZ Stream doesn't have an MCP server, covered directly in an earlier article that found Mux and Cloudinary both ship one. That's still true today, checked again while researching this piece. What's worth separating out, though: not having an MCP server doesn't mean an AI agent can't use AIOZ Stream on its own. Tool calling, the mechanism MCP itself is built on top of, already gets an agent there, and for a small, fixed set of endpoints it's arguably less setup than standing up an MCP server would be anyway.

TL;DR:

• MCP is a discovery-and-connection protocol standardizing how any agent finds any server's tools. Tool calling (function calling) is the underlying mechanism both MCP and a manual setup actually use to let a model request a function be run. MCP wraps tool calling in a standard transport; it doesn't replace it.
• For a small, fixed set of API calls, hand-defining tools is often genuinely simpler than deploying an MCP server, industry guidance is direct about this: "manually coding those three calls is faster than setting up an MCP connection" when the workflow is deterministic and small.
• A working example below defines three of AIOZ Stream's real endpoints, create a video, upload it, check its status, as Claude-compatible tool schemas using the exact field names from AIOZ's own API.
• The honest limit: this is per-integration code you write and maintain yourself, not something every MCP-compatible client picks up automatically. If usage grows, an official MCP server remains the more scalable answer, the same conclusion the earlier MCP-gap article reached.

MCP vs. tool calling: what's actually different

Tool calling (also called function calling) is the actual mechanism: you pass a model a list of tool definitions, name, description, and a JSON Schema describing its inputs, and the model decides when a user's request calls for one, returning a structured request for your code to execute. OpenAI shipped this in mid-2023, Anthropic's version reached general availability in mid-2024, and it's been the foundation of agentic tool use since. MCP doesn't replace this, it standardizes the discovery and transport layer around it: instead of every integration hand-defining its own tool list, an MCP server exposes a manifest any MCP-compatible client can query and connect to without custom glue code per client. That's a real, valuable standardization when many different agent hosts need to reach the same API. It's also genuine overhead, a server to deploy, a manifest to maintain, a transport to run, when the actual need is a single application calling a handful of known endpoints in a known order.

When manual tool calling is the right call

The deciding factor isn't preference, it's shape of the workflow. Direct REST calls or hand-defined tools make sense when an application controls a small number of internal or well-known APIs; a model reads the documented shape once, at setup, and calls it over plain HTTP with no protocol overhead beyond the request itself. Industry guidance on this tradeoff is direct: for simple, deterministic workflows where an application always calls the same handful of endpoints in the same order with the same logic, hand-coding those calls is genuinely faster than standing up an MCP connection, MCP earns its complexity when many different, unpredictable clients need to discover and call an evolving set of tools, not when one application needs three specific endpoints it already knows about. AIOZ Stream's core video pipeline, create an entry, upload the file, check on its status, is exactly that second, narrower shape.

A working example: three AIOZ Stream tools for Claude

Claude's tool-use feature expects each tool defined with a name, a description, and an input_schema in standard JSON Schema format. Here's a create_video tool built directly from AIOZ Stream's own documented CreateMediaRequest fields, not invented ones:

{
  "name": "create_aioz_video",
  "description": "Create a new video entry on AIOZ Stream before uploading a file to it.",
  "input_schema": {
    "type": "object",
    "properties": {
      "title": {
        "type": "string",
        "description": "Title of the video"
      },
      "description": {
        "type": "string",
        "description": "Description of the video"
      },
      "is_public": {
        "type": "boolean",
        "description": "Whether the video is publicly accessible"
      },
      "tags": {
        "type": "array",
        "items": { "type": "string" },
        "description": "Tags for the video, max 50 items"
      }
    },
    "required": ["title"]
  }
}

When a user asks something like "create a private video called Q3 Product Demo," Claude returns a tool_use block naming create_aioz_video with {"title": "Q3 Product Demo", "is_public": false} filled in. The application code, not Claude, actually executes the real POST /media/create call, then sends the resulting video ID back to Claude in a tool_result block so the conversation can continue. Two more tools complete the basic flow: an upload_aioz_video_part tool wrapping the documented upload-part endpoint, and a get_aioz_video_status tool wrapping the get-detail endpoint so the agent can report back once encoding finishes. None of this requires AIOZ Stream to expose anything it doesn't already expose today, it's the same REST API covered in the developer guide, wrapped in a schema a model can read directly.

What this doesn't solve

Worth being direct about the actual limitation here, since it's the same gap the earlier MCP article found, just from the other side. This pattern is per-integration code: every application that wants an agent to manage AIOZ Stream videos has to define its own copy of these tool schemas and write its own handler functions. There's no discovery step the way an MCP manifest provides, and no single install that lets a completely different AI product pick up AIOZ Stream tool access without writing this code itself. That's a real, meaningful gap compared to what an official MCP server would provide, and it's exactly why agent-friendly API design matters even without MCP: clear field names, predictable response shapes, and documented endpoints are what make hand-writing this kind of tool wrapper straightforward instead of a guessing exercise. Tool calling gets a single application talking to AIOZ Stream through an agent today. An MCP server would let any MCP-compatible agent do the same without writing any of this code first, which is still the better answer if and when demand for it grows enough to justify building one.

Frequently Asked Questions

Does AIOZ Stream have an MCP server?
No, confirmed directly against its current documentation. No MCP-related pages, tools, or references exist anywhere in AIOZ Stream's docs today.

Can an AI agent still use AIOZ Stream without an MCP server?
Yes, through standard tool calling (function calling), the same underlying mechanism MCP itself is built on. You define the endpoints as tools with a JSON Schema, and the model requests them by name when a user's request calls for it.

Is tool calling harder to set up than MCP?
For a small, fixed set of endpoints, generally no, it's less infrastructure than deploying and maintaining an MCP server. MCP's advantage shows up when many different, unpredictable clients need to discover the same tools without custom code per client.

What AIOZ Stream endpoints make good candidates for tool-calling?
The core video pipeline: create a video entry, upload the file, and check its encoding status. All three are documented, narrow in scope, and don't require exposing anything AIOZ Stream doesn't already document.

Will AIOZ Stream ever get an official MCP server?
Not documented as planned. If agent-driven usage grows enough to justify it, an MCP server remains the more scalable path since it removes the need for every integration to hand-write its own tool schemas.

Where do I find AIOZ Stream's exact API field names to build a tool schema?
The developer guide and the official Go client's generated model documentation both document exact field names directly, worth checking rather than guessing before writing a tool's input_schema.

Related Reading

• Does AIOZ Stream Have an MCP Server? Mux and Cloudinary Do: the gap this article's tool-calling workaround responds to directly
• What Actually Makes an API Agent-Friendly: the design qualities that make hand-writing a tool wrapper like this one straightforward
• Building a Video Upload Endpoint with Cursor or Claude Code: using an AI coding assistant to write the handler code these tool definitions call into
• AIOZ Stream Developer Guide: the full REST API surface these tool schemas are built from
• AIOZ Stream API Keys: the credential scope an agent's tool-execution code should actually run under

References

• Anthropic: Tool use with Claude: the input_schema structure and tool_use/tool_result round trip quoted above
• WorkOS: MCP vs. REST, what's the right way to connect AI agents to your API: the discovery-vs-mechanism distinction referenced above
• DEV Community: How to Build an AI Agent from Your Existing REST API, Without an MCP Server: a comparable manifest-and-tool-schema pattern referenced above