One publish. App + API + AI + Data.
Describe the application you need. MiniUp chooses the smallest supporting architecture and builds a static, no-build UI on existing services.
| Application intent | Supporting resources |
|---|---|
| Landing page or simple content | Site |
| Read-only dashboard from Excel or other uploaded data | Site + hosted dataset |
| Customer tracker or editable records | Site + Table |
| Form collecting submissions | Site + Table |
| Server-side business logic or protected API integration | Function with the Site |
| Team portal | Existing Site access and membership + required resources |
| Asset map | Site + hosted geospatial dataset where appropriate |
Updates should reuse the app’s resources. An app does not need a backend merely because one is available. Secrets belong in Functions, never in browser files.
App discovery
Every active published app reserves these paths on its MiniUp host and active custom domain:
/.well-known/miniup.json: available Tables, intentionally exposed Functions, hosted datasets and AI capabilities./openapi.json: an OpenAPI 3.1 document built from current Table schemas, enabled operations and intentionally exposed Function actions./use-with-ai: connection guidance and actions available to the current visitor.
Discovery follows the app’s current access rules. Protected apps require access before returning resource metadata. Responses are private and not cached. Private resource definitions, keys, storage locations and internal ownership metadata are not included. The document describes operations visible to the current caller, so a visitor and a Site editor can see different operations. API keys are not accepted as credentials for discovery; use an authorized Site session to inspect protected apps.
Public Functions use their canonical Function endpoint. Site-member Functions use the existing same-origin gateway. Functions with only MiniUp User access can still be available through approved Agent Actions, but are not advertised as Site gateway REST endpoints.
The Site workspace
The Site workspace groups existing capabilities into App, API, AI, and Data. Owners and admins can inspect configured operations, Table and dataset counts, current access, custom domain and latest revision. Detailed configuration stays in existing pages.
Effective Access is a derived, read-only summary. It does not grant permissions. Human access follows Site and resource access; API calls still enforce resource scopes, origin policies and quotas. WebMCP and remote MCP reuse the same Agent Action registry. AI mutations require an owner, admin or editor and the existing risk checks.
Use with AI
WebMCP requires a supporting browser and an authorized app session. Remote MCP uses the app’s existing Streamable HTTP endpoint on the MiniUp account host. Copy its URL from Use with AI into a compatible client.
Public read actions may work anonymously. Protected apps need a client that supports OAuth authorization with PKCE. Sign in with an account that has app access. Granted scopes and membership determine the available tools; a browser password or session does not authenticate a remote client. This does not add tools to the account-level MiniUp MCP server.
Disabled actions remain disabled. Consequential Function actions still require intentional approval in Agent Actions. Hosted dataset actions remain bounded and read-only; a dataset can support hosted reads even when it exceeds the AI query limits.