Higgsfield is an AI studio for making images, video, voiceover, and 3D. Open it for the first time and it can look like a wall of model names, presets, and buttons, with no obvious first move. This article is a map, not a tutorial: the single idea behind everything, the handful of building blocks, what avatars and workflows are actually for, and a short path so you know exactly where to start. ...
Higgsfield ships a bundled video-explainer workflow through its MCP server: hand it a script and it produces a narrated, animated video by generating one 10-second clip per line, voicing each line, and stitching the result into a single MP4. This guide runs that workflow from Claude Code, using a short made-up script so you can see exactly how a few lines of text become finished clips. Claude Code is a good fit here because the whole flow is text-driven. Every visual is generated from a written style description and per-block prompts, so there are no local files to upload — the terminal client never needs to render an upload widget. You paste a script, answer a few setup questions, and Claude Code orchestrates the Higgsfield tools for you. ...
Higgsfield exposes its image and video generation as an MCP server, so you can produce short-form video by chatting with an MCP client instead of clicking around a web app or wiring up an API. This guide uses its Shorts Studio flow: you hand it one source video, pick a visual style, and it returns a set of vertical, AI-restyled clips sized for YouTube Shorts. There is no code to write. The whole workflow is a conversation with an assistant that has the Higgsfield connector enabled; behind each message, the assistant calls a Higgsfield MCP tool. This article shows what to say, which tool runs, and what comes back, grounded in the live server. ...
The earlier MCP articles built servers that expose tools and a client that calls those tools by hand: you name the tool, you supply the arguments. An agent is the piece that makes those decisions for you. Given a question and a set of MCP tools, it asks a model which tool to call, runs it, feeds the result back, and repeats until the model has an answer. This article builds that agent with the Anthropic Python SDK and FastMCP, on macOS with uv, make, and pytest. The loop is the standard Anthropic tool-use loop; the only twist is that the tools come from an MCP server instead of being defined inline. ...
As an MCP deployment grows, one giant server file stops scaling. FastMCP offers two ways to build bigger servers from smaller ones: Composition mounts independently-developed sub-servers into one gateway, so a team can own a math server and another own a text server, and a client sees them as one. Proxying puts a FastMCP server in front of an existing MCP server (even a remote one), forwarding every request to it. That lets you add TLS, auth, or rate limiting in front of a server you do not control, or expose a remote server under your own address. This article builds both: a gateway composed from two sub-servers, and a proxy that fronts an existing HTTP server. The stack is Mac-native: uv and make. ...
Most tools take their inputs up front and return an answer. Two MCP capabilities turn that around and let a tool ask the client for something mid-run: Elicitation asks the user for structured input, so a tool can request a missing value or a confirmation instead of failing. Sampling asks the client’s LLM for a completion, so a tool can use the model the client already has rather than calling one itself. Both are server-to-client requests: the tool pauses, the client answers, and the tool continues. This article builds a FastMCP server that uses each, and a client that answers them. The final tool chains the two: it elicits who a bio is for, then samples the model to write it. The stack is Mac-native: uv and make. ...
A tool that returns in a few milliseconds needs no ceremony. A tool that runs for several seconds does: without feedback, the client looks frozen, and a user (or a model) cannot tell a slow success from a hang. MCP solves this with progress notifications and log messages that stream back to the client while the tool is still running. This article builds a FastMCP tool that reports progress as it works, and a client that renders a live progress bar from those notifications. ...
The tools in the earlier articles computed their answers locally. Most useful tools instead reach out to an external service: a weather API, a payments provider, an internal microservice. That introduces three problems a naive httpx.get ignores: where the API key lives, what happens when the call is slow, and how a failure reaches the user. This article builds a FastMCP tool that calls a real HTTP API and handles all three, the macOS way. ...
Every deployment article so far bound the server to 127.0.0.1 over plain HTTP. That is correct for local use and unusable for anything else: a client on another machine cannot reach loopback, and sending bearer tokens or OAuth codes over plain HTTP leaks them. The fix is a TLS reverse proxy. This article puts Caddy in front of a FastMCP server so it is reachable over HTTPS, with certificates Caddy obtains and renews on its own. ...
Gate a FastMCP Server to Paying Customers sold tiered access: Basic and Pro plans. Selling tiers only matters if the tiers actually differ, and the most common difference is how much a customer may call. This article adds per-plan rate limiting to a FastMCP server: a middleware reads each caller’s plan from their verified token and enforces that plan’s request quota, keyed on the caller’s identity. A Basic customer gets a small quota, a Pro customer a larger one, and over-limit calls are rejected cleanly. ...