BuildWithHQ exposes four distinct MCP surfaces: one for your BuildWithHQ account, one inside the isolated developer VM, one for a specific SaaS application, and one you can offer to your own end customers. Each surface has a different identity, a different authority boundary, and a different job.
MCP is not one unrestricted connection into BuildWithHQ. The platform exposes the capabilities appropriate to the person, application, and environment making the request.
Manage your BuildWithHQ account and SaaS portfolio: applications, domains, backups, API clients, integrations, marketplace products, capacity, security and account-level audit.
Build code inside an isolated development machine with Codex, DeepSeek Harness or another agent, local PostgreSQL, local services, testing and controlled BuildWithHQ development capabilities.
Build and operate one SaaS application as one logical system across its runtime data, compliance logs and AI/vector data—without giving an agent raw database selection.
Let your customers safely connect their preferred AI to your product, limited to the records, files, knowledge, workflows and actions that specific user is allowed to access.
The Builder Account MCP operates at the control-plane level. It is for the people building and owning SaaS products on BuildWithHQ—not for the users inside those SaaS products.
List applications, inspect configuration and capacity, create or manage environments, and resolve app-level administration without manually navigating every screen.
Add or verify domains, create backups, rotate scoped API credentials, and inspect integrations through the same permission-aware builder identity.
Find, install and manage approved templates, harnesses, integrations and custom-service packages across the builder's portfolio.
Search account audit activity, review capacity and security state, and answer operational questions across the SaaS products the builder actually owns.
builder.apps.listbuilder.domains.managebuilder.backups.createbuilder.api_clients.rotateThe authenticated builder account and user establish scope. The agent does not get to choose a different customer account simply by placing another ID in a tool call.
Each developer VM is an isolated workshop. Developers can write ordinary code, run AI coding agents, use their own local PostgreSQL database, launch local services and test aggressively. Crossing the VM boundary happens through controlled BuildWithHQ services.
Use Codex, DeepSeek Harness, local models or other approved developer agents against the source tree and BuildWithHQ development tools.
The VM includes developer-controlled PostgreSQL for custom application data, migrations, experiments, pgvector, queues and private services.
Compile .NET, Node or Python, run tests, start localhost services, create APIs, use Git, create branches, break the dev database and restore it.
AI models, package repositories, documentation, external integrations, deployment and BuildWithHQ services are reached through approved internal gateways instead of arbitrary internet access.
The agent works with application capabilities rather than database credentials. BuildWithHQ resolves the correct runtime database, compliance-log database and AI/vector database behind the tool call.
Describe modules and fields, create and update records, search authorized data, and work with the same record model used by the visual application.
Discover and traverse the graph around a record—customer to contacts to conversations to opportunities to projects—without requiring a bespoke API for every relationship.
Create or modify application structure, configure workflows, inspect permission rules, preview role-specific experiences and prepare a release for validation.
Search application activity, retrieve permission-aware knowledge, propose governed AI actions and inspect outcomes without exposing the physical data stores to the model.
app.schema.describeapp.records.searchapp.relationships.traverseapp.pages.updateapp.workflows.createapp.activity.searchapp.audit.searchapp.knowledge.searchapp.actions.proposeapp.validateA builder can turn on a customer-facing MCP surface for the product they sell. The end customer's preferred AI can search, reason and act through the SaaS—but only inside that customer's user, role, location, record and field permissions.
“Which customers have gone quiet?” “Show my overdue invoices.” “Find every file and conversation related to this project.”
Create a follow-up, start an approved workflow, update a permitted record or draft a response through actions the SaaS builder has explicitly exposed.
The product can work with compatible MCP clients instead of forcing every customer into one AI assistant or requiring the builder to create a new integration per model.
The MCP layer does not become a database backdoor. Hidden fields, unauthorized records and other customer accounts remain outside the caller's capability envelope.
You decide whether customer MCP is included, reserved for a higher plan, or sold as a monthly add-on. Because you own the SaaS relationship, MCP access can become another recurring line item in your customer's subscription.
An MCP connection exposes capabilities. A skill tells an AI how to combine those capabilities to perform a useful job in your product.
Instructions, permitted MCP tools, record and knowledge scope, workflow/action contracts, validation rules, approval expectations and domain-specific operating guidance.
Include skills with premium plans, sell industry-specific skill packs, create custom skills for larger customers, or use skills to differentiate a white-label SaaS offering.
A record update should not have one security implementation for the UI and a different one for AI. BuildWithHQ projects the same capability through whichever interface is calling it.
The same caller should receive the same authorization outcome whether they arrive through the visual UI, REST, workflow automation or MCP.
AI tool calls can carry the same correlation, identity and action evidence as normal application activity.
A business capability can be surfaced to UI buttons, REST clients, workflows, agents and MCP without reimplementing its business rules five times.
The model can request or propose an operation. BuildWithHQ still decides whether the authenticated caller has permission to execute it.
No. The VM can use local development tools, its own PostgreSQL instance and approved BuildWithHQ gateways for AI, packages, documentation, integrations and deployment while remaining isolated from arbitrary internet destinations.
No. The client requests application capabilities such as records, audit activity or knowledge. BuildWithHQ resolves the correct physical database behind that request.
Yes. Customer-facing MCP capabilities are selected by the SaaS builder and are further constrained by the authenticated end user's normal application permissions.
Yes. Customer MCP can be packaged as a paid add-on or premium plan feature, and builders can create specialized skills that use those MCP capabilities as additional customer value.
Build visually, extend with code, develop with AI, expose governed capabilities through MCP, and decide how much of that power reaches each customer.
Create the application first. The same records, relationships, permissions, workflows, knowledge and actions become the foundation for its MCP surface.
Get started freeExplore the platform