MCP Tools and Agent Workflows

Use this page when the question is how an external agent can move from discovery into authenticated action inside SyncReserve.

Where MCP fits in the platform

SyncReserve uses two different agent-facing layers:

llms.txt is the public discovery surface
POST /api/v1/platform/mcp is the authenticated interactive tool surface

That means an external agent can first discover the platform and then switch into a structured tool workflow once it has the correct credential.

What MCP is good for

MCP is the right fit when an agent needs structured tool access rather than page scraping.

For evaluators, the key value is that SyncReserve does not force an agent to reverse-engineer the UI. It provides a tenant-scoped tool surface designed for:

reading stable tenant profile data
reading analytics summaries
checking export job status
performing selected premium operational actions

Current tool surface

The current MCP surface includes a mix of stable read tools and narrower action-oriented tools.

Current tool names:

get_tenant_profile
search_sessions
get_analytics_summary
get_export_status
create_booking_hold

Publicly, the important pattern is:

tenant-aware reads come first
reporting and export workflows are available through tools as well as routes
more operational actions are exposed more cautiously than basic reads

That is useful for buyers and agents because it shows a deliberate pattern: safe reads first, then narrower action tooling where entitlement and safety requirements are stronger.

Auth and tenant boundaries

MCP is authenticated with a platform API key and remains tenant-scoped for every request.

That matters because:

the agent can only see the tenant tied to the supplied credential
scopes still gate which tools are available
more operational tools require stronger entitlement and scope checks than read tools

Recommended agent progression

External agent workflows should usually follow this order:

discover the tenant and public surface through llms.txt
authenticate with the correct platform credential
prefer stable read tools before any write-capable action
use narrower scopes for task-specific integrations
treat action-oriented tools as explicit automation decisions, not casual browsing tools

MCP versus the admin AI workspace

These two surfaces solve different problems.

MCP is for external agents working through the platform contract
the admin AI workspace is for tenant operators configuring, testing, and reviewing their own AI assistant behavior

A buyer should read both areas, but not confuse them with each other.

What this page is not

This page is a workflow-level explanation.

It is not:

a JSON-RPC transport tutorial
a full tool schema dump
a description of internal orchestration or admin AI internals

/docs/platform-api/public-discovery-and-agent-entrypoints
/docs/platform-api/platform-auth-and-scopes
/docs/ai-agents/ai-workspace