Project setup

A Metabind project is the tenant boundary for your MCP App. Every tool, component, package, and asset belongs to a project, and the project owns the production and draft MCP server endpoints. Before you build tools, set up the project so the platform serves the right thing to the right callers.

Project type

Every project has a type field that drives the Metabind Studio experience:

Type	What it surfaces	When to use
`mcp`	Tool management, testing, MCP server endpoints. Per-Type publish, status badges, production and draft URLs on the Server page.	You’re building an MCP App — Interactive Tools, Data Tools, the Assistant SDK embed. The default for new MCP App projects.
`content`	Content editing, visual preview, streamlined publishing. Headless-CMS workflow centered on Types and Content entries.	You need a managed content store that an MCP App’s Data Tool can query — a product catalog, a help-center corpus, an editorial inventory. The Data Tool wraps the Content REST API and surfaces entries to the agent.

Both types have access to the same API capabilities — the field controls the UI experience, not the API surface. A common pattern is two projects working together: a content project for the catalog (managed by a content team), and an mcp project whose Data Tool queries the content project’s REST API to answer questions. If you’re building an MCP App, start with type: "mcp". You can switch later, but the Metabind Studio sidebar and prompts assume the type is set correctly.

Project visibility

By default, projects are private: both the production and draft MCP endpoints require an API key or OAuth SSO. Use private for internal tools, staff assistants, and any project where tool input or output is sensitive. For projects built for end-user consumption — a retail assistant any customer can add to Claude, a public demo — set the project to public:

{
  "settings": {
    "mcp": {
      "visibility": "public",
      "publicRateLimit": {
        "requestsPerHour": 60,
        "burst": 10
      }
    }
  }
}

Public visibility only applies to projects where type: "mcp".

	Private (default)	Public
Production endpoint	API key or OAuth required	Anonymous access allowed
Draft endpoint	API key or OAuth required	API key or OAuth required (draft never opens up)
Tools registered	Published Types + the `search_assets` platform tool	Published Types only
Sampling / elicitation	Not offered	Not offered
Rate limit	Per-client	Per-session, per-address, and per-project (configurable)

A few safeguards worth knowing about:

The draft endpoint never opens up to anonymous callers, regardless of visibility. Unpublished Types stay behind auth.
Platform tools such as search_assets are left out of anonymous sessions of public projects. Anonymous callers see only your published tools.
Anonymous traffic is rate-limited per session, per address, and per project. The per-session default is 60 tool calls an hour with a burst of 10. Override per project via settings.mcp.publicRateLimit. See Rate limiting.
A kill switch lets organization admins flip a project back to private at any time via Metabind Studio or the /disable-public endpoint.

For full operational detail (kill-switch playbook, audit-log entries, the API), see Public and private projects. For when to choose public vs. private, see When to use public visibility below.

Server instructions

The Instructions block on the Server tab holds your MCP server instructions. Every host receives them when it connects, and hosts that read them pass them to the model as guidance alongside their own system prompt. With the Agent Proxy, in your own apps, they’re sent on every turn, before your system prompt. This is where you tell the model:

What the project’s purpose is.
What the project is and isn’t for. For your agent’s voice, tone, and rules in your own apps, use the system prompt.
Routing rules — “if the user wants to compare products, use product_comparison. If the user wants a single product, use product_detail, always with a video if available.”

Instructions matter more than most teams expect. They’re the difference between a model that calls the right tool for the right user goal and one that picks tools at random or describes things in text. Spend time on them.

Use these tools to help the user design an interior. You are an expert interior designer.
Our company is called Oak&Ivory.

Always use these tools when the user wants help to design a new lounge room or kitchen
or bedroom.

- If the user wants a very basic list of products viewed, use product_carousel
- If the user wants to compare some inspiration, use product_card_stack plus data
- If the user wants to compare products, use product_comparison
- If the user wants to see a single product, use product_detail, always try and serve
  it up with a video if there is one.
- If the user wants to reimagine / design their space with chosen products use
  interior_designer

Instructions become the MCP InitializeResult.instructions field, which hosts that support it pass to the model.

Server metadata

A few project-level fields shape the MCP server’s serverInfo:

Field	Maps to	Purpose
`slug`	`serverInfo.name`	The MCP server’s identifier (auto-generated)
`name`	`serverInfo.title`	Human-readable project title
`description`	`serverInfo.description`	One-sentence description for client display
`settings.mcp.version`	`serverInfo.version`	Your project’s version string (default: `"1.0.0"`)
`settings.mcp.icons`	`serverInfo.icons`	Sized icons for client UIs
`settings.mcp.websiteUrl`	`serverInfo.websiteUrl`	Link to your project’s site or docs

These show up in the MCP host UI when a user adds your server. Treat them like app store metadata — they’re how someone evaluating whether to install your MCP App will recognize it.

When to use public visibility

Good fit:

Retail product research or shopping assistants any customer can add to Claude.
Documentation-style tools over publicly published content.
Public demos of an MCP server.
Marketing tools where the data and UI are already public.

Poor fit:

Tools that proxy private data (customer records, internal inventory, transaction history).
Tools whose data components carry API keys with broad scopes — anonymous callers will be able to invoke them.
Internal staff assistants. Use a private project with the MCP User role instead — see Team management.

Flipping a project to public opens a confirmation dialog; click I understand the impact to confirm.

The General page of Project Settings in Metabind Studio, with the Change menu in the Access section open, showing Public and Private, with Private checked

Build an Interactive Tool

Define your first tool that returns rendered UI.

Build a Data Tool

Wrap an API as an MCP tool with sandboxed execution.

Metabind Studio

The UI surface where project setup happens.

Team management

Roles for private projects: MCP User, MCP Developer, and more.

Getting Started

Core Concepts

Building Your MCP App

Publishing

Connecting to MCP Hosts

Assistant SDK

Operations

Sample Apps

Project type

Project visibility

Server instructions

Server metadata

When to use public visibility

What to read next

Build an Interactive Tool

Build a Data Tool

Metabind Studio

Team management

​Project type

​Project visibility

​Server instructions

​Server metadata

​When to use public visibility

​What to read next

Build an Interactive Tool

Build a Data Tool

Metabind Studio

Team management

Project type

Project visibility

Server instructions

Server metadata

When to use public visibility

What to read next