Product surfaces

MCP

Canonical projection through the same dispatcher as REST and SDK. Capability-grant filtered.

This page is the documentation contract for the MCP surface in Vadyl's final form. It is not a marketing summary: it names the authorities, projections, runtime behavior, examples, limits, errors, and observability expectations that every product implementation must honor.

What this surface owns

  • MCP owns the canonical product-facing contract described here; provider-specific machinery stays behind capability declarations.
  • Canonical projection through the same dispatcher as REST and SDK. Capability-grant filtered.
  • The final docs treat this as complete: REST, GraphQL, gRPC, SDK, CLI, MCP, dashboard, observability, limits, errors, and explainability are all covered as projections of one authority.

Canonical authorities

AuthorityRole
ExposureBindingDescriptorDefines how MCP appears through REST, OpenAPI, GraphQL, gRPC, SDK, CLI, MCP, dashboard, webhooks, realtime, and events.
IApiOperationDispatcherCanonical owner for MCP; downstream surfaces derive from this rather than inventing their own truth.
ContractProjectionDescriptorProjects MCP from canonical project state into every caller-visible contract.
ProjectCapabilitySurfaceManifestPlaces MCP inside the UCSA taxonomy and enforces binding, grants, conformance, and consumption.

Projection coverage

Surface kindsWireSurface, OperationProjectionSurface, SdkSurface, CommandSurface, ToolSurface, UiProjectionSurface
Projection facetsOperations, Cli, ExposureBindings
ProtocolsRest, OpenApi, GraphQL, Grpc, Sdk, Cli, Mcp, Dashboard
Public projectionsREST; OpenAPI; GraphQL; gRPC; SDK; CLI; MCP; dashboard actions; webhooks; realtime

Project-scope parity

    Publish, install, consume

      Consumption evidence

        Runtime behavior

        • thin controller dispatch
        • operation projection
        • descriptor hash validation
        • grant-set enforcement

        REST and controller surface

        Code-backed controllers are listed here so the docs menu does not hide the real endpoint surface. The complete route-by-route table remains in the REST controller atlas.

        ControllerBase routeEndpoint countExamples
        Operation/api/Operation2
        POST Execute
        POST Plan
        ContractProjection/api/ContractProjection4
        GET descriptor
        GET {language}/declarations
        GET cli
        GET events
        Sdk/api/Sdk3
        POST generate
        GET languages
        GET versioning
        Agent/api/Agent1
        POST {agentId}/run
        AgentRun/api/AgentRun6
        GET /
        GET {runId}
        POST {runId}/cancel
        GET {runId}/steps
        AgentMemory/api/AgentMemory7
        GET namespaces
        POST namespaces
        GET namespaces/{namespaceId}
        POST apply

        SDK and CLI surface

        ProjectionNamespace / groupCoverage
        SDKplatformprovider health/capabilities, runtime fabric scaling, distribution, version governance, data portability. Rendered methods: 12.
        SDKmcptoken issuance, exposure descriptors, tool invocation, resources, prompts. Rendered methods: 6.
        SDKagentsdefinitions, runs, plans, memory, skills, model bindings, token accounting, MCP exposure. Rendered methods: 6.
        SDKentities.<Entity>list, read, create, update, upsert, delete, count, exists, alternate-key, batch, subscribe. Rendered methods: 10.
        CLIvadyl sdkGenerate / inspect language SDKs. Rendered commands: 3.
        CLIvadyl statusHealth and version. Rendered commands: 3.
        CLIvadyl agentList, inspect, run agents. Rendered commands: 7.

        Input request and output

        POST /api/Operation/Execute HTTP/1.1
        Host: api.vadyl.app
        Authorization: Bearer $VADYL_TOKEN
        X-Vadyl-Tenant: acme
        X-Vadyl-Project: billing
        Content-Type: application/json
        
        {
          "surface": "mcp",
          "publicationVersion": 412,
          "explain": true
        }

        Limits and quotas

          Error model

          ErrorMeaning

          Observability and explainability

            Related references