Slaunt MCP Developer Guide

This guide is for engineers integrating external clients with Slaunt via Model Context Protocol (MCP). Slaunt is proprietary software, and this documentation covers only stable public behavior—not internal implementation details.

This guide is intended for:

• Platform engineers building MCP integrations
• App developers connecting AI clients to Slaunt
• AI product engineers designing context-aware workflows
• Integration partners building third-party connectors

This guide covers:

• Authentication and authorization
• MCP connection and session management
• Tool discovery and invocation
• CCR event schemas and validation
• Error handling and recovery
• Operational expectations

This guide does NOT cover:

• Internal architecture or implementation details
• Source code or private infrastructure
• Undocumented behavior or response quirks

All integration contracts are defined by this documentation. Behavior not explicitly documented here may change without notice. If you discover behavior that seems useful but is not documented, request official support before depending on it.

Slaunt supports integration with any MCP-compatible client that follows authentication and protocol requirements:

• Desktop AI clients — Claude Desktop, Cursor, and similar applications
• CLI MCP clients — Command-line tools implementing MCP
• Server-side automation — Backend services invoking MCP tools programmatically
• Web app integrations — Browser-based applications with backend MCP proxy

Get connected to Slaunt in five steps:

{
  "mcpServers": {
    "slaunt": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-client", "https://mcp.slaunt.ai"]
    }
  }
}

This policy ensures users are properly authenticated and understand the operational scope before any data access occurs. Clients that bypass this requirement may be rate-limited or blocked.

Slaunt uses OAuth 2.0 for authentication with bearer token transport:

• Token acquisition: Obtain tokens via OAuth flow at slaunt.ai/auth
• Token transport: Include in all requests as Authorization: Bearer <token>
• Token expiry: Tokens expire after 1 hour; refresh before expiry
• Unauthenticated requests: Will receive 401 with login instructions

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

All requests are evaluated under tenant scope and optionally project scope:

• Identity claims must include organization context for scoped operations
• Missing scope will cause rejected operations with 403 responses
• Project-level scoping is optional but recommended for large organizations

The expected session sequence:

1. Connect — Establish transport to MCP endpoint
2. Initialize — Send initialize request, receive server capabilities
3. Read Instructions — Parse and follow server-provided guidance
4. List Tools — Discover available operations via tools/list
5. Call Tools — Execute operations as needed
6. Handle Continuity — Maintain session state across interactions
7. Reconnect — Re-establish session if connection drops

Not all internal capabilities are exposed to all surfaces. Developers should:

• Rely on tools/list for discoverable capabilities
• Never assume hidden or control-plane tools are callable from general MCP sessions
• Check tool availability on each session—capabilities may vary by user role

Slaunt enforces strict validation. Validate client-side before sending to reduce avoidable failures:

• Required IDs: Must be valid UUIDs
• Event types: Must match accepted enum values
• Summary length: Maximum 500 characters
• Tags: Maximum 10 tags, each max 50 characters
• Timestamps: ISO 8601 format required

CCR events should represent real state changes, not discussions or speculation:

Writing Guidelines

• Use short, canonical summaries
• Be factual—avoid "maybe", "probably", "might"
• Preserve event type semantics
• Include relevant actors when known
• Use consistent terminology across events

When querying CCR, interpret results as follows:

• Relevance first: Results are ordered by semantic relevance to query
• Scoped memory: Results are filtered to your tenant and optional project scope
• Recency considerations: More recent events may be weighted higher
• No results: An empty result set means no relevant context exists—this is valid, not an error

RCAC (Remote Context Access Control) provides a control-plane interface for:

• Viewing and managing allowed agent records
• Distinguishing between controllable managed agents and observed external telemetry
• Setting access policies for agent-to-CCR interactions

External platforms can submit agent activity through the public ingest contract:

• Auth: Server-to-server credentials required
• Required fields: agent_id, action_type, timestamp
• Ownership metadata: Must include source system identifier
• Lifecycle status: Use conventions: active, completed, failed

Data access is tenant-scoped by policy:

• All queries are filtered by authenticated tenant
• Cross-tenant visibility should be treated as a defect and escalated immediately
• Required claims for isolation: org_id, user_id

Safe retry behavior:

• Timeout: 30 seconds recommended for most operations
• Backoff: Exponential with jitter (100ms, 200ms, 400ms...)
• Max retries: 3 for transient errors
• Idempotency: Write operations may create duplicates if retried without idempotency keys

Log the following on your side for debugging and audit:

• Request IDs (from response headers)
• Session IDs
• Tool names invoked
• Latency measurements
• Error categories and codes

Environment variable ownership belongs to your deployment platform, not repository examples:

• Sample .env.example files are templates only
• Cloud dashboards are the authoritative source for runtime configuration
• Never commit real credentials to version control

API and tool changes are communicated as follows:

• Deprecation window: Minimum 90 days notice for breaking changes
• Migration guidance: Provided in changelog and this documentation
• Backward compatibility: Maintained within major versions

Recommended test stack:

1. Connection tests: Verify MCP endpoint reachability
2. Auth tests: Confirm token acquisition and refresh
3. Schema conformance: Validate payloads match expected shapes
4. Negative tests: Ensure proper error handling for invalid inputs
5. Scope enforcement: Verify tenant isolation works correctly

For support issues:

1. Check https://slaunt.ai/docs first
2. Search existing issues and troubleshooting playbook
3. If unresolved, submit a support ticket with:
   • Timestamp of the issue
   • Request ID (from response headers)
   • Tool name invoked
   • Endpoint URL
   • Sanitized error payload (no secrets)

By using the Slaunt API and MCP integration, you agree to comply with our Terms of Service and Acceptable Use Policy.