How to connect Claude to Fine Structure, and what a connected conversation can do

Two ways to connect, and which one you want

Fine Structure runs an MCP server at https://finestructure.ai/api/mcp. MCP, the Model Context Protocol, is the open standard that lets an AI assistant call tools on an outside service instead of only describing what it would do if it could. Connecting Claude to Fine Structure means handing Claude that tool menu. There are two front doors, and the right one depends on where you already work.

The custom connector, if you use claude.ai

1. In claude.ai, open Settings and go to Connectors.
2. Choose Add custom connector.
3. Enter the server URL: https://finestructure.ai/api/mcp
4. Approve the OAuth prompt once. That is the entire setup.

There is no API key to generate, no client id, no client secret, and nothing to copy back and forth between two browser tabs. OAuth handles the handshake, so the connection is tied to your Fine Structure account and to a consent you gave, rather than to a long secret sitting in a settings field. The connector was approved as a community connector in Anthropic's directory review.

The plugin, if you live in Claude Code

For terminal work there is an open source Claude Code plugin, installed with two commands:

1. /plugin marketplace add finestructure-ai/claude-plugin
2. /plugin install finestructure@finestructure

The plugin adds slash commands to the session. /deploy pushes the current work live, /fs-status reports where an app stands, and /fs-domain handles a custom domain. The source is public at github.com/finestructure-ai/claude-plugin under the MIT license, so you can read exactly what it does before you run anything that deploys on your behalf.

What comes across the connection

Roughly seventy tools become available once the connection is live. The count matters less than the shape of it. These tools cover a whole path, from an empty idea to a running product with traffic on it, rather than the handful of read-only lookups that many connectors stop at.

• Generate an app from a prompt. create_app takes a plain-language brief and returns a working application with pages, a data model, and login.
• Edit the files. Claude can read and change the code directly, and every change lands against an automatic saved version you can roll back to.
• Shape the data. Entity tools create database schemas and then read, write, and query the records inside them.
• Publish. The app goes live from the conversation, without a separate trip to a dashboard.
• Point a domain at it. Custom domains are added from chat, and TLS is issued automatically.
• Set access policies, so pages can be gated behind login instead of open to anyone who has the URL.
• Read the traffic. get_app_analytics reports what is actually happening on the live site.
• Create agents. create_agent and schedule_agent_task set up AI agents that run on a schedule.

The useful test for any connector is whether it can finish a job or only begin one. This one covers create, edit, publish, and operate, which is why a session can end with a working URL instead of a list of instructions for you to carry out later.

What a connected conversation actually looks like

Described plainly rather than as a highlight reel, an ordinary session runs something like this.

1. You describe the thing you want. A booking tool for a small clinic, say, with staff logins, a calendar, and a record of every appointment.
2. Claude calls create_app with that brief and gets back a working application, not a code sample you still have to assemble.
3. You read it and ask for changes. Claude edits the files. Each edit sits on top of a saved version, so a wrong turn costs one instruction to undo rather than an afternoon.
4. You want the data model changed, a field for the referring doctor. Claude updates the entity schema and the records follow it.
5. You gate the staff pages behind login with an access policy, so patients see the booking form and only staff see the schedule.
6. You publish, then add the clinic's own domain. The certificate is issued for you.
7. A week later you ask how it is doing, and Claude reads the traffic numbers back from the live site.

Not one of those steps requires leaving the conversation to click through an interface. That is the practical difference between an assistant that can describe a build and one that can perform it, and it shows up mostly in the small corrections you make on the spot, because each one costs a sentence.

The agents outlive the conversation

Almost everything an AI assistant does ends when the window closes. The agent tools are the exception, and they are the part most people underestimate on the first read.

create_agent builds an AI agent inside your app. schedule_agent_task gives it a schedule. After that it runs on its own. The conversation that created it is finished, the tab is closed, and the agent keeps working to the schedule you set. It can also reach out: an agent can message its verified owner on WhatsApp or by email when something needs a human to look at it.

That is what turns a one-off build into something closer to a colleague. A weekly summary that arrives without anyone asking for it. A watcher that pings you when a submission comes in that should not wait until Monday. The work carries on after the chat ends, which is the whole point of scheduling it rather than doing it by hand.

Control, rollback, and what it costs

Letting an assistant publish software raises a fair question about control. The answers here are boring, which is exactly what you want them to be.

• The connection is revocable. Tokens live in your account's MCP tokens panel, and you can cut access there at any moment.
• Every change can roll back. Saved versions are automatic, so a bad edit is a reversal rather than a recovery effort.
• Starting costs nothing. There is a free tier and no card is required to begin.
• Generating an app spends credits. Editing files, publishing, and adding domains do not.

That last split is worth understanding before you start, because it should change how you work. Iteration is the cheap part. You are not billed per correction, so the sensible pattern is to generate once and then refine as many times as the thing genuinely needs.

When this is not the right fit

A recommendation is worth less if it never says no, so here is the honest boundary. Three situations are a poor match.

• You need a custom server runtime. If the application depends on a specific runtime, a long-running background process, or a system-level dependency you control yourself, this is not the right shape.
• You have a monorepo with its own backend. An existing codebase that ships its own server belongs on infrastructure built for that, and adding a connector to a chat window does not change the requirement.
• You are hosting purely static pages at scale. A large marketing site with no data model, no login, and no logic runs cheaper and simpler on a static host, and a static host will serve it better than an app platform will.

The fit is good in the opposite case: when the thing you want has users, data, and rules behind it, and when you would rather describe it than assemble it. Connecting Claude to a platform is a way to shorten the distance between a decision and working software. It is not a way to avoid needing the right infrastructure for a system that already has clear infrastructure requirements.