Connecting an AI Agent to AIOZ Stream: MCP Server or Tool Calling

AIOZ Stream now has an MCP server, covered in the article on what it exposes and how it compares with Mux and Cloudinary. It documents nine tools, so the practical question for anyone connecting an AI agent is which route fits the task: the MCP server, or standard tool calling, the mechanism MCP itself is built on. For a small, fixed set of endpoints that the MCP server does not cover, defining the tools yourself is often less setup than it sounds.

TL;DR:

• AIOZ Stream's MCP server documents nine tools: media counts, video lookup by name, video listing, livestream key creation, analytics, aggregated and breakdown metrics, balance and data consumed. Creating a video entry, uploading a file and checking encoding status are not among them.
• 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: tool definitions are per-integration code you write and maintain yourself, not something every MCP-compatible client picks up automatically. Use the MCP server for the account-level questions it covers and your own tools for the pipeline operations it does not.

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, one of the operations the documented MCP tools do not cover, 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.

Choosing between the two

The two routes are not exclusive, and the documented tool lists make the split fairly clear. The MCP server covers nine operations: count the media in an account, look up playback URLs by video name, list the videos, create a livestream key, and read analytics, aggregated and breakdown metrics, balance and data consumed. If that is what an agent needs, connecting a client to the hosted endpoint is the quicker path, because there is no code to write. The MCP server article has the endpoint, the Cursor configuration and the open questions the docs leave, including which API key role it needs.

Hand-defined tools make sense when the agent has to do something the MCP tools do not offer, such as creating a video entry, uploading parts or reading encoding status, or when your application needs control over exactly how credentials are stored and calls are made. The cost is the one named earlier: every application that wants this has to define its own copy of the tool schemas and write its own handlers, with no discovery step. That is also why agent-friendly API design matters whichever route you pick: clear field names, predictable response shapes and documented endpoints are what make hand-writing a tool wrapper straightforward instead of a guessing exercise.

One caution applies to both. An agent that can create stream keys or upload content is acting with your account's credentials, so give it the narrowest API key role that works, and keep the key out of prompts and shared files.

A quick decision checklist

Five questions settle most cases:

1. What does the agent need to do? If it is counting media, finding playback URLs by name, listing videos, creating a livestream key, or reading analytics, usage and balance, the MCP server covers it. If it needs to create a video entry, upload parts or read encoding status, you need your own tools.
2. How many clients need access? If several different clients, such as Cursor, ChatGPT or VS Code, should reach AIOZ Stream without custom code in each, that is what MCP is designed for.
3. Is it one application with a fixed sequence? A single application that always creates, uploads and checks status in the same order is the shape where hand-defined tools are simplest.
4. Where should the key live? The documented MCP setup places your public and secret keys, base64url-encoded, in a URL inside the client's configuration file. With your own tool handlers, the key stays in your server code or environment, and the model never sees it.
5. Who maintains it? The MCP server is maintained by AIOZ. Tool schemas you write are yours to update whenever the API changes, so keep them small.

Frequently Asked Questions

Does AIOZ Stream have an MCP server?
Yes. The docs describe a hosted server at mcp.aiozstream.network with nine tools, including count-total-media, get-video-urls, get-list-video, create-livestream-key, get-analytics-data and get-balance.

Can an AI agent use AIOZ Stream without the 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.

Should I use the MCP server or define my own tools?
Use the MCP server when the nine documented tools cover what the agent needs. Define your own tools for operations they do not cover, such as creating a video entry, uploading a file or checking encoding status.

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? Yes, and What It Exposes: the nine documented tools, the setup and the gaps
• 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

• AIOZ Stream Docs: AIOZ MCP Server: the documented tools referenced above
• 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