Outborn Agent Platform · Technical reference

External developer quickstart

Connect an MCP client, discover the tools available to your identity, and make a first read-only request.

Applied guidance

Best practices for external developer quickstart

Recommended

  • Use the protected-resource metadata on your deployment's public origin to discover authorization.
  • Make a read-only tools/list or agents.list call before invoking an agent or presenting a Space mutation.
  • Keep the token, organization, and request ID together in your client context while redacting secrets from diagnostics.

Avoid

  • Do not substitute a provider API key or a token for another resource for an Outborn Account MCP access token.

01

What you need

Use the public HTTPS origin supplied for your Outborn Agent Platform deployment, an Outborn Account identity in the intended organization, and an OAuth-capable MCP client. To invoke an agent, that identity must own an agent it can access. The examples use placeholders rather than a fixed production hostname or an invented client-registration flow.

  • — Ask your organization administrator which public MCP origin and Account authorization flow are enabled.
  • — Keep the organization selected in Outborn Account consistent with the resources you intend to read.
  • — Start with a read-only request before trying any Space mutation.

02

Discover authentication

Request the protected-resource metadata from the same public origin as /mcp/v1. It advertises the authorization server and the resource identifier your access token must target. An unauthenticated MCP request also returns a WWW-Authenticate challenge pointing to that metadata.

Protected-resource metadataBASH
curl -i "${OUTBORN_AI_ORIGIN}/.well-known/oauth-protected-resource/mcp/v1"

03

Authorize your client

Complete the authorization flow advertised by the protected-resource metadata through Outborn Account. The resulting bearer token must be for the advertised MCP resource and include openid and organizations scopes. The platform validates its signature, issuer, audience, expiry, user, client, and organization claims; an arbitrary API key or provider token is not interchangeable.

  • — Use the OAuth client registration and consent process configured for your deployment.
  • — Treat an HTTP 401 as a signal to inspect the WWW-Authenticate challenge and token state.
  • — Treat an HTTP 403 as an authorization or scope problem, not a reason to switch identities silently.

04

List available tools

Send JSON-RPC 2.0 to POST /mcp/v1. Discover the current tool schemas with tools/list; the server decides which Spaces and agents are visible in the authenticated organization.

First authenticated requestBASH
curl -sS "${OUTBORN_AI_ORIGIN}/mcp/v1" \  -H "Authorization: Bearer ${OUTBORN_MCP_TOKEN}" \  -H "Content-Type: application/json" \  --data '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

05

Make a first read

Call spaces.list or agents.list with an empty arguments object. Read result.structuredContent.items when present; result.content is also supplied as text. A successful list only proves access to those returned resources, not permission to modify them.

List visible agentsJSON
{  "jsonrpc": "2.0",  "id": 2,  "method": "tools/call",  "params": {    "name": "agents.list",    "arguments": {}  }}

06

Continue to agent invocation

After you have an agent ID from the visible list, use agents.invoke for a governed read-only chat request. Read the MCP reference for the exact argument shape and the error guide before adding retries or mutations.

Related documentation

Open Outborn Agent Platform ↗Outborn Agent Platform overviewContact Outborn