@mindstudio-ai/remy 0.1.201 → 0.1.202

package/dist/headless.js

@@ -313,6 +313,10 @@ Current date: ${now}
   {{compiled/agent-interfaces.md}}
   </building_agent_interfaces>
 
+  <building_mcp_interfaces>
+  {{compiled/mcp-interfaces.md}}
+  </building_mcp_interfaces>
+
   <media_cdn>
   {{compiled/media-cdn.md}}
   </media_cdn>
@@ -4693,7 +4697,7 @@ This is a capable, stable platform used in production by 100k+ users. Build with
 - Full-stack web apps \u2014 social platforms, membership sites, marketplaces, booking systems, community hubs \u2014 multi-user apps with auth, data, UI
 - Automations with no UI \u2014 cron jobs, webhook handlers, email processors, data sync pipelines
 - Marketing & launch pages \u2014 landing pages, waitlist pages with referral mechanics, product sites with scroll animations
-- Bots \u2014 Discord slash-command bots, Telegram bots, MCP tool servers for AI assistants
+- Agent tools \u2014 MCP tool servers for AI assistants
 - Creative/interactive projects \u2014 browser games with p5.js or Three.js, interactive visualizations, generative art, portfolio sites
 - API services \u2014 backend logic exposed as REST endpoints
 - Simple static sites \u2014 no backend needed, just a web interface with a build step
@@ -4708,8 +4712,6 @@ Each interface type invokes the same backend methods. Methods don't know which i
 - API \u2014 auto-generated REST endpoints for every method
 - Cron \u2014 scheduled jobs on a configurable interval
 - Webhook \u2014 HTTP endpoints that trigger methods
-- Discord \u2014 slash-command bots
-- Telegram \u2014 message-handling bots
 - Email \u2014 inbound email processing
 - MCP \u2014 tool servers for AI assistants
 - Agent \u2014 conversational LLM interface with tool access to backend methods

package/dist/index.js

@@ -1967,6 +1967,10 @@ Current date: ${now}
   {{compiled/agent-interfaces.md}}
   </building_agent_interfaces>
 
+  <building_mcp_interfaces>
+  {{compiled/mcp-interfaces.md}}
+  </building_mcp_interfaces>
+
   <media_cdn>
   {{compiled/media-cdn.md}}
   </media_cdn>
@@ -5474,7 +5478,7 @@ This is a capable, stable platform used in production by 100k+ users. Build with
 - Full-stack web apps \u2014 social platforms, membership sites, marketplaces, booking systems, community hubs \u2014 multi-user apps with auth, data, UI
 - Automations with no UI \u2014 cron jobs, webhook handlers, email processors, data sync pipelines
 - Marketing & launch pages \u2014 landing pages, waitlist pages with referral mechanics, product sites with scroll animations
-- Bots \u2014 Discord slash-command bots, Telegram bots, MCP tool servers for AI assistants
+- Agent tools \u2014 MCP tool servers for AI assistants
 - Creative/interactive projects \u2014 browser games with p5.js or Three.js, interactive visualizations, generative art, portfolio sites
 - API services \u2014 backend logic exposed as REST endpoints
 - Simple static sites \u2014 no backend needed, just a web interface with a build step
@@ -5489,8 +5493,6 @@ Each interface type invokes the same backend methods. Methods don't know which i
 - API \u2014 auto-generated REST endpoints for every method
 - Cron \u2014 scheduled jobs on a configurable interval
 - Webhook \u2014 HTTP endpoints that trigger methods
-- Discord \u2014 slash-command bots
-- Telegram \u2014 message-handling bots
 - Email \u2014 inbound email processing
 - MCP \u2014 tool servers for AI assistants
 - Agent \u2014 conversational LLM interface with tool access to backend methods

package/dist/prompt/compiled/auth.md

@@ -228,7 +228,7 @@ Returns an array of user IDs with the specified role.
 
 ### System Role (Platform Triggers)
 
-When the platform invokes a method on behalf of the app (cron, webhook, email, Discord, Telegram), the execution runs as a system user with `auth.roles: ['system']`. Use `auth.requireRole('system')` to restrict methods to platform triggers only:
+When the platform invokes a method on behalf of the app (cron, webhook, email), the execution runs as a system user with `auth.roles: ['system']`. Use `auth.requireRole('system')` to restrict methods to platform triggers only:
 
 ```typescript
 export async function regenerateCache(input: {}) {

package/dist/prompt/compiled/dev-and-deploy.md

@@ -35,7 +35,7 @@ The platform builds and deploys automatically:
 
 1. **Parse manifest** — read `mindstudio.json` from the commit
 2. **Compile methods** — esbuild bundles each method into a single JS file
-3. **Compile interfaces** — build web SPA (`npm install && npm run build`), generate configs for API/Discord/Telegram/cron/etc.
+3. **Compile interfaces** — build web SPA (`npm install && npm run build`), generate configs for API/cron/webhook/etc.
 4. **Parse table schemas** — TypeScript AST to column definitions, diff against live database
 5. **Compute effects** — roles diff, cron diff, bot command diffs, table DDL
 6. **Apply** — create/update roles, sync bot commands, apply DDL to a staging database copy, swap the live pointer

package/dist/prompt/compiled/interfaces.md

@@ -2,7 +2,7 @@
 
 Interfaces are projections of the backend contract into different modalities. The same methods power all of them. An interface can be as complex and polished as you want, but it's always safe — the backend contract is where anything real happens. The interface can't break business logic or corrupt data.
 
-All external service connections (Discord bot tokens, Telegram bot setup, webhook secrets, email addresses) are configured at the project level by the user through the Remy platform. The agent's job is to write the config files and the methods that handle the requests — not to manage API keys, OAuth flows, or service registration.
+All external service connections (webhook secrets, email addresses) are configured at the project level by the user through the Remy platform. The agent's job is to write the config files and the methods that handle the requests — not to manage API keys, OAuth flows, or service registration.
 
 ## Web Interface
 
@@ -243,53 +243,7 @@ Routes are mounted at `/_/api{path}` (e.g. `DELETE /_/api/vendors/abc123`).
 
 ## Platform-Triggered Interfaces
 
-Discord, Telegram, Cron, Webhook, and Email interfaces are invoked by the platform, not by a user session. Methods called through these interfaces run with `auth.roles: ['system']`. Use `auth.requireRole('system')` to restrict a method to platform triggers only.
-
-## Discord Bot
-
-Slash commands that invoke methods.
-
-### Config (`interface.json`)
-
-```json
-{
-  "discord": {
-    "commands": [
-      {
-        "name": "submit-vendor",
-        "description": "Request a new vendor",
-        "method": "submit-vendor-request"
-      }
-    ],
-    "loadingMessage": "Processing your request..."
-  }
-}
-```
-
-Commands are synced to Discord on deploy.
-
-## Telegram Bot
-
-Bot commands and message handling.
-
-### Config (`interface.json`)
-
-```json
-{
-  "telegram": {
-    "commands": [
-      {
-        "command": "/submit",
-        "description": "Submit a vendor request",
-        "method": "submit-vendor-request"
-      }
-    ],
-    "defaultMethod": "handle-message"
-  }
-}
-```
-
-`defaultMethod` handles free-text messages that don't match a command.
+Cron, Webhook, and Email interfaces are invoked by the platform, not by a user session. Methods called through these interfaces run with `auth.roles: ['system']`. Use `auth.requireRole('system')` to restrict a method to platform triggers only.
 
 ## Cron
 
@@ -422,19 +376,156 @@ Methods invoked through this interface run with `auth.roles: ['system']` (see th
 
 ## MCP (Model Context Protocol)
 
-Expose methods as AI tools.
+Expose the app to *external* AI agents — Claude Desktop, Cursor, other people's agents, anything that speaks MCP. Unlike the agent interface (which *is* an agent — its own LLM, personality, and chat UI), MCP has no model of its own; it's the app projected as an MCP server for an outside AI to drive.
+
+It supports the full MCP surface:
+- **Tools** — methods the agent can call (rich descriptions + machine-readable annotations).
+- **Resources** — read-only app data the agent can pull into context, addressable by URI.
+- **Prompts** — reusable, parameterized prompt templates the server offers.
+- **Instructions** — server-level guidance shown to the calling agent (the toolset's "system prompt").
+
+The platform hosts the server, handles auth like the API interface (optional — keyed or anonymous), and derives every tool's input schema from the method contract. Because the consumer is an external agent with no knowledge of your app, **the descriptions are the product** — see "Building MCP Interfaces" for how to write them.
+
+### Spec: `src/interfaces/mcp.md`
+
+Frontmatter declares the server. The body's intro prose becomes the server `instructions`; `## Tools`, `## Resources`, and `## Prompts` sections declare the rest.
+
+```yaml
+---
+name: Vendor Management
+description: Tools and data for managing vendors and purchase orders.
+type: interface/mcp
+---
+```
+
+```markdown
+This server manages vendors and purchase orders. Read a vendor before updating it; submitted
+requests go through approval before they become active.
+
+## Tools
+
+### Submit a vendor request
+method: submit-vendor-request
+~~~
+Submit a new vendor for approval. Use when the caller wants to add a vendor.
+Do NOT use to modify an existing vendor — that's update-vendor.
+- name: the vendor's legal name
+- contactEmail: billing contact; required for approval routing
+Returns the created vendor's id and its initial "pending" status.
+~~~
+
+### List vendors
+method: list-vendors
+annotations: readOnly
+~~~
+List all vendors, newest first. Read-only.
+~~~
+
+## Resources
+
+- list-vendors → app://vendors — "Vendors" — all vendors (application/json)
+- get-vendor → app://vendors/{id} — "Vendor" — a single vendor by id (application/json)
+
+## Prompts
+
+### draft_vendor_email
+description: Draft an outreach email to a vendor.
+arguments: vendorId (required) — the vendor to contact
+~~~
+Write a warm outreach email to vendor {{vendorId}} introducing our procurement process.
+~~~
+```
+
+Don't hand-author input schemas — the platform derives them. For a resource template, `{param}` in the URI maps to the backing method's input.
+
+### Compiled Output: `dist/interfaces/mcp/`
+
+```
+dist/interfaces/mcp/
+├── interface.json      ← config the platform reads
+├── instructions.md     ← server-level guidance (returned in `initialize`)
+├── tools/
+│   ├── submitVendorRequest.md   ← rich description, one per tool
+│   └── listVendors.md
+└── prompts/
+    └── draftVendorEmail.md      ← prompt template body, one per prompt
+```
+
+Resources carry inline metadata only — no per-resource file.
 
 ### Config (`interface.json`)
 
 ```json
 {
   "mcp": {
-    "methods": ["submit-vendor-request", "list-vendors"]
+    "name": "Vendor Management",
+    "description": "Tools and data for managing vendors and purchase orders.",
+    "instructions": "instructions.md",
+    "tools": [
+      {
+        "method": "submit-vendor-request",
+        "name": "submit_vendor_request",
+        "title": "Submit Vendor Request",
+        "description": "tools/submitVendorRequest.md",
+        "annotations": { "readOnly": false, "destructive": false, "idempotent": false, "openWorld": false }
+      },
+      {
+        "method": "list-vendors",
+        "title": "List Vendors",
+        "description": "tools/listVendors.md",
+        "annotations": { "readOnly": true }
+      }
+    ],
+    "resources": [
+      { "method": "list-vendors", "uri": "app://vendors", "name": "Vendors", "description": "All vendors.", "mimeType": "application/json" },
+      { "method": "get-vendor", "uriTemplate": "app://vendors/{id}", "name": "Vendor", "description": "A single vendor by id.", "mimeType": "application/json" }
+    ],
+    "prompts": [
+      {
+        "name": "draft_vendor_email",
+        "title": "Draft vendor email",
+        "description": "Draft an outreach email to a vendor.",
+        "arguments": [ { "name": "vendorId", "description": "The vendor to contact", "required": true } ],
+        "template": "prompts/draftVendorEmail.md"
+      }
+    ]
   }
 }
 ```
 
-Each listed method becomes an MCP tool. Method names and descriptions from the manifest are used as tool names and descriptions.
+| Field | Description |
+|-------|-------------|
+| `name`, `description` | Server display name + registry metadata (not shown to the calling agent) |
+| `instructions` | Relative path to the server-level guidance returned in `initialize` |
+| `tools[].method` | Method `id` from the manifest (kebab-case) |
+| `tools[].name` | Tool name exposed to clients. Optional — defaults to the method `id`. Must match `[a-zA-Z0-9_-]` and be unique within the server |
+| `tools[].title` | Optional human-friendly display name |
+| `tools[].description` | Relative path to the tool's markdown description |
+| `tools[].annotations` | Optional client hints (auto-call vs. confirm): `readOnly`, `destructive`, `idempotent`, `openWorld` — map to MCP's `readOnlyHint` etc. |
+| `resources[].method` | The read method invoked when the resource is read |
+| `resources[].uri` / `uriTemplate` | A static URI, or a template whose `{param}` maps to the method's input |
+| `resources[].name`, `description`, `mimeType` | Resource metadata |
+| `prompts[].name`, `title`, `description` | Prompt identity + metadata |
+| `prompts[].arguments` | `[{ name, description?, required? }]` |
+| `prompts[].template` | Relative path to the template body (`{{arg}}` placeholders) |
+
+There is no `inputSchema` field — the platform derives each tool's schema from the method's input contract.
+
+### Platform Behavior
+
+- The platform hosts the MCP server and exposes it to external clients. Clients connect at `POST https://{app-host}/_/mcp`.
+- **Auth is optional**, identical to the API interface: a `Bearer` key resolves to a user with full RBAC; with no key, calls run anonymously (no user, no roles). The method is the boundary — gate sensitive tools with `auth.requireRole`/`requireUser`; a public (keyless) server exposes only the un-gated tools.
+- Input schemas are derived automatically from each method's input contract.
+- `tools/list` is static; access is enforced per-method at call time (a gated tool is listed but rejects an unauthorized call).
+- A resource read invokes the backing method (template `{param}`s come from the URI) and returns its output as the resource contents.
+- `prompts/get` fills the template with the provided arguments.
+- `instructions` is returned in the `initialize` response.
+
+### Manifest
+
+```json
+{ "type": "mcp", "path": "dist/interfaces/mcp/interface.json" }
+```
 
 ## Agent (Conversational Interface)
 
@@ -514,8 +605,6 @@ Each interface is declared in `mindstudio.json`:
     { "type": "web", "path": "dist/interfaces/web/web.json" },
     { "type": "api" },
     { "type": "cron", "path": "dist/interfaces/cron/interface.json" },
-    { "type": "discord", "path": "dist/interfaces/discord/interface.json" },
-    { "type": "telegram", "path": "dist/interfaces/telegram/interface.json" },
     { "type": "webhook", "path": "dist/interfaces/webhook/interface.json" },
     { "type": "email", "path": "dist/interfaces/email/interface.json" },
     { "type": "mcp", "path": "dist/interfaces/mcp/interface.json" },

package/dist/prompt/compiled/manifest.md

@@ -111,7 +111,7 @@
 
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
-| `type` | `string` | Yes | One of: `web`, `api`, `discord`, `telegram`, `cron`, `webhook`, `email`, `mcp`, `agent` |
+| `type` | `string` | Yes | One of: `web`, `api`, `cron`, `webhook`, `email`, `mcp`, `agent` |
 | `path` | `string` | No | Path to the interface config file |
 | `config` | `object` | No | Inline config (alternative to a file) |
 | `enabled` | `boolean` | No | Default `true`. Set `false` to skip during build. |

package/dist/prompt/compiled/mcp-interfaces.md

@@ -0,0 +1,34 @@
+# Building MCP Interfaces
+
+Guidance for exposing an app as an MCP server — a tool / resource / prompt surface for *external* AI agents (Claude Desktop, Cursor, anyone's agent). The contract (spec format, compiled output, `interface.json`) is in the Interfaces doc; this is how to author one well. Unlike the agent interface, there's no LLM, personality, or UI to design — the entire product is the descriptions and the shape of what you expose.
+
+## The descriptions are the product
+
+The calling agent is a stranger with no knowledge of your app. It decides what to invoke entirely from the names, descriptions, and annotations you ship. Follow the same principles as the agent interface's tool descriptions (see "Building Agent Interfaces" — when to use and when not, parameter guidance beyond the schema, what the tool returns) — but write them **self-contained**. An in-app agent tool can lean on the app's framing; an MCP tool can't, because the caller has no context. Spell out what an outsider wouldn't know.
+
+## Curate — not every method is a tool
+
+Expose what an outside agent would actually use. Skip internal helpers, admin-only methods, and batch operations. A focused set of well-described tools beats a large set of thin ones. Note role restrictions in the description — gated tools are listed but reject unauthorized calls at runtime, so set expectations rather than surfacing a raw error.
+
+## Annotations
+
+Annotations are machine-readable hints clients use to decide whether to auto-call a tool or ask the user first. Set them honestly:
+
+- `readOnly` — the tool only reads, never mutates. The highest-value hint: clients auto-call reads without prompting, so set it on every pure read.
+- `destructive` — the tool can delete or overwrite. Clients gate these behind confirmation.
+- `idempotent` — calling twice with the same arguments has the same effect as calling once.
+- `openWorld` — the tool reaches outside the app (external web/services) rather than operating only on app data.
+
+## Tools vs. resources
+
+A **tool** is an action the agent *invokes*; a **resource** is data the agent *reads into context*. A read-only method can be either — expose it as a tool if the agent will call it as a step, as a resource if it's reference data the agent should pull in, and as both when both fit.
+
+Resources are method-backed: a read invokes the method. Use a static `uri` for a fixed collection (`app://vendors`) and a `uriTemplate` when the read takes parameters (`app://vendors/{id}`, where `{id}` maps to the method's input). Keep URIs stable and human-legible.
+
+## Prompts
+
+Prompts are reusable, parameterized templates the server offers to clients — e.g. a "draft a vendor email" starter. Author the template body with `{{arg}}` placeholders and declare its arguments. Offer a prompt when there's a recurring task worth packaging; skip it if a tool already covers the need.
+
+## Server instructions
+
+The spec's intro prose becomes the server `instructions` — toolset-level guidance returned to the calling agent at connect time (its "system prompt"). Put *cross-cutting* guidance here: how the tools fit together, ordering or prerequisites ("read a vendor before updating it"), and norms that apply across the whole toolset. Keep per-tool specifics in the tool descriptions; instructions are for the toolset as a whole.

package/dist/prompt/compiled/methods.md

@@ -1,6 +1,6 @@
 # Methods
 
-A method is a named async function that runs on the platform. It's the universal unit of backend logic — every interface (web, API, Discord, cron, webhook) invokes methods. One file per method, one named export.
+A method is a named async function that runs on the platform. It's the universal unit of backend logic — every interface (web, API, cron, webhook) invokes methods. One file per method, one named export.
 
 ## Writing a Method
 

package/dist/prompt/compiled/platform.md

@@ -41,12 +41,14 @@ my-app/
         package.json
         src/
       api/api.json                       REST API config
-      discord/interface.json             Discord bot config
-      telegram/interface.json            Telegram bot config
       cron/interface.json                cron config
       webhook/interface.json             webhook config
       email/interface.json               email config
-      mcp/interface.json                 MCP config
+      mcp/                               MCP interface
+        interface.json                     MCP config
+        instructions.md                    server instructions
+        tools/                             tool descriptions (one .md per method)
+        prompts/                           prompt templates (one .md per prompt)
       agent/                             agent interface
         agent.json                         agent config
         system.md                          compiled system prompt
@@ -93,7 +95,7 @@ const { vendor } = await api.approveVendor({ vendorId: '...' });
 
 - **Managed databases.** SQLite with typed schemas. Push a schema change and the platform diffs, migrates, and promotes atomically.
 - **Built-in auth.** Opt-in via manifest. Developer builds login UI, platform handles verification codes (email/SMS), cookie sessions, and role enforcement. Backend methods use `auth.requireRole('admin')` for access control.
-- **Multiple interfaces, one codebase.** Web, API, Discord, Telegram, Cron, Webhook, Email, MCP — all invoke the same methods. Methods don't know which interface called them.
+- **Multiple interfaces, one codebase.** Web, API, Cron, Webhook, Email, MCP — all invoke the same methods. Methods don't know which interface called them.
 - **Sandboxed execution.** Each method invocation runs in its own isolated execution context with npm packages pre-installed.
 - **Git-native deployment.** Push to default branch to deploy. Push to feature branch for preview. Rollback is a git revert.
 - **Secrets.** Encrypted environment variables with separate dev/prod values. Injected as `process.env` in methods. For third-party service credentials not covered by the SDK.

package/dist/prompt/static/intake.md

@@ -11,7 +11,7 @@ Remy apps are full-stack TypeScript projects. You have a lot to work with:
 - **Backend (Methods):** TypeScript in a sandboxed runtime. Any npm package. Managed SQLite database with typed schemas and automatic migrations. Built-in app-managed auth with email/SMS verification, cookie sessions, and role enforcement. None of these are required — use what the app needs.
 - **Frontend (Web Interface):** Starts as Vite + React, but any TypeScript project with a build command works. Any framework, any library, or no framework at all.
 - **AI & integrations:** The `@mindstudio-ai/agent` SDK gives access to 200+ AI models (OpenAI, Anthropic, Google, Meta, Mistral, and more) and 1000+ integrations (email, SMS, Slack, HubSpot, Google Workspace, web scraping, image/video generation, media processing) with zero configuration — credentials are handled automatically. No API keys needed. Beyond individual actions, `runTask()` lets you spin up lightweight autonomous task agents that chain these actions together with judgment — e.g., a user types a restaurant name and the backend autonomously researches it in the background, finds the address, and generates a custom illustration. Think about where this kind of enrichment would make a feature go from functional to magical.
-- **Interfaces:** Web UI, REST API, cron jobs, webhooks, Discord bots, Telegram bots, MCP tool servers, email processors, conversational AI agents — all backed by the same methods. An app can use any combination.
+- **Interfaces:** Web UI, REST API, cron jobs, webhooks, MCP tool servers, email processors, conversational AI agents — all backed by the same methods. An app can use any combination.
 
 This is a capable, stable platform. Build with confidence; you're building production-grade apps, not fragile prototypes.
 
@@ -24,7 +24,7 @@ Don't recite this list to users. Use it to calibrate your sense of what's possib
 - **Full-stack web apps** — social platforms, membership sites, marketplaces, booking systems, community hubs — multi-user apps with auth, data, UI
 - **Automations** — cron jobs that monitor competitors and send alerts, webhook handlers that sync data between services, email processors that triage support requests — no UI needed
 - **Conversational AI agents** — custom chat UIs backed by any model, with tool access to the app's methods. Full control over what the agent can do and who can use it
-- **Bots & agent tools** — Discord slash-command bots, Telegram bots, MCP tool servers for AI assistants
+- **Agent tools** — MCP tool servers for AI assistants
 - **Creative projects** — browser games with p5.js or Three.js, interactive visualizations, 3D things, generative art, portfolio sites with dynamic backends
 - **Marketing & launch pages** — landing pages, waitlist pages with referral mechanics, product sites with scroll animations — visual polish is a strength here
 - **API services** — backend logic exposed as REST endpoints

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindstudio-ai/remy",
-  "version": "0.1.201",
+  "version": "0.1.202",
   "description": "Remy coding agent",
   "repository": {
     "type": "git",