Guest Machines

Documentation over MCP

Use the public documentation MCP server, and manage remote MCP connectors through the Guest Machines API.

Guest Machines publishes its documentation as a remote Model Context Protocol server. Point any MCP client at it and your assistant can read these pages directly instead of guessing or scraping rendered HTML.

The server is public, unauthenticated, and read-only.

https://guestmachines.com/api/mcp

It speaks Streamable HTTP. No authentication or configuration beyond the URL is needed.

You can attach this same URL to a Guest Machines agent as a remote MCP connector. Use Streamable HTTP and no authentication. Your workspace's outbound access policy still applies. The exception covers this exact endpoint; other platform URLs and hosting IPs remain protected.

Connect a client

For Claude Code:

claude mcp add --transport http gm-docs https://guestmachines.com/api/mcp

For clients configured through JSON, such as Claude Desktop, Cursor, or VS Code:

{
  "mcpServers": {
    "gm-docs": {
      "type": "http",
      "url": "https://guestmachines.com/api/mcp"
    }
  }
}

Tools

ToolPurpose
list_docsEvery page with its path, title, and summary
get_docOne page as Markdown, by path (developers/webhooks) or URL
search_docsFull-text search returning matching pages with excerpts

The documentation is small enough to browse. Listing the pages and reading the ones that look relevant generally beats searching, and the tool descriptions say so — expect an assistant to start with list_docs.

Without MCP

The same content is available over plain HTTP, which is often enough:

URLContents
/llms.txtAn index of every page, for AI agents
/llms-full.txtThe entire documentation as one Markdown file
/docs/<page>.mdA single page as Markdown

Any documentation URL also returns Markdown when the request sends Accept: text/markdown:

curl -H 'Accept: text/markdown' https://guestmachines.com/docs/developers/webhooks

Manage agent connectors through the API

The documentation server above is separate from the remote MCP connectors you register for agents. Delegated applications can list connectors, create a connector, and update a connector through the public API. Use a delegated token with only the mcp_servers:list, mcp_servers:read, mcp_servers:create, mcp_servers:edit, mcp_servers:delete, and mcp_servers:publish scopes it needs.

Connector registration and runtime availability are independent:

  1. Register or update a connector with /api/v1/mcp-servers.
  2. Optionally call /api/v1/mcp-servers/test to check the connection and list its tools.
  3. Read /api/v1/capabilities and the selected model in /api/v1/models.
  4. Attach the connector only when that model is available, returns supports_mcp: true, and lists the connector's require_approval value in mcp_approval_policies.

The test is advisory: it verifies that Guest Machines can connect and list tools. During a run, the selected model provider connects to the MCP server, so a successful test does not guarantee that the provider can reach it.

Credentials and trust boundary

Guest Machines encrypts connector tokens at rest and never returns the plaintext; read responses contain only a masked auth_hint. A saved token can be reused only with the connector's saved URL. Re-enter it when testing or saving a different URL. A delegated application testing an organization-library connector with its saved credential needs both mcp_servers:edit and mcp_servers:publish, and its user must currently be an organization admin or owner.

The connector URL itself is metadata and may be visible to organization-library readers. Query strings and fragments are rejected, and you must not embed a credential in the URL path; use the encrypted token field instead.

oauth_token is currently a stored bearer-token mode, not a Guest Machines-managed OAuth refresh flow. Your integration must obtain, rotate, and explicitly update the token before it expires.

Provider-hosted MCP gives the selected model provider the server URL, bearer credential, tool definitions, arguments, and results needed to execute the call. Register only servers and credentials you trust for that provider, limit each connector to the tools the agent needs, and assume the server can change the tools it advertises.

Anthropic currently documents its hosted MCP connector as a beta feature that uses standard provider retention and is not covered by Zero Data Retention arrangements. Consider those terms before attaching a connector to an Anthropic model.

OpenAI models support both per-call approval and autonomous execution. Anthropic models support autonomous execution only, so their connectors must use require_approval: "never". Service-principal and unattended trigger starts cannot answer approval requests; integrations that use approval should handle them through the run interaction API.

Manage the organization library

Delegated applications can publish or unpublish a connector through the connector API when they carry the exact mcp_servers:publish scope and represent a current organization admin or owner. Creating a connector directly as org_shared requires both mcp_servers:create and mcp_servers:publish.

The mcp_servers:* wildcard deliberately excludes publishing, so existing broad grants cannot begin sharing credentials without a new consent decision. Service principals cannot manage connector records. They can invoke an organization-shared agent that already has an organization-library connector attached; use require_approval: "never" because a service-principal run cannot answer a provider approval request.

Connectors execute through agents. The public API does not expose a standalone endpoint that calls an arbitrary MCP tool.

Model support and limits

Do not infer hosted MCP support or approval behavior from a provider name. supports_mcp and mcp_approval_policies on each /api/v1/models entry are authoritative; /api/v1/capabilities reports whether any currently available model supports hosted MCP.

All currently offered OpenAI and Anthropic models report hosted MCP support. Clients should still read the catalog instead of hard-coding a model list, because availability and capabilities can change.

Keep connector tool filters narrow. A run can be rejected if the combined tool set exceeds the selected model's or provider's limits; Guest Machines does not silently remove tools to make a request fit.

Anthropic does not guarantee a hard cap on MCP calls before Guest Machines can stop a run that exceeds its limits. A remote server may already have performed a side effect. Use autonomous execution only with trusted servers, make side-effecting tools idempotent where possible, and set appropriate run limits.

Every currently offered OpenAI model advertises always and never; every currently offered Anthropic model advertises never only. Other models may not support MCP. Always negotiate the catalog fields for the selected model.

On this page