Skip to content

mcp-data-platform-v1.63.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 18 May 16:43
· 102 commits to main since this release
v1.63.0
10e336c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Highlights

REST gateway shim for non-MCP HTTP clients (#427)

api_invoke_endpoint is now reachable over plain HTTP at:

POST /api/v1/gateway/{connection}/invoke

so callers that cannot speak MCP/JSON-RPC (Apache NiFi's InvokeHTTP, Airflow's HttpOperator, curl, internal pipelines) can drive the same kind: api connections that MCP callers use, without learning the MCP tools/call envelope.

Why this matters. Before this release the only non-MCP path to the API gateway was POST /api/v1/admin/tools/call. That endpoint is admin-only, double-wraps the response in an MCP content envelope, and forces external callers to know tool-name conventions. NiFi, Airflow, and similar HTTP pipelines could not reasonably integrate against it. The result: an enterprise with a fully-audited, persona-gated, OAuth-fronted API gateway still had to hand out raw vendor credentials to its data movement layer. This release closes that gap with a first-class REST surface.

No forked auth path

Every REST request is routed through an in-memory MCP session against the platform's already-assembled *mcp.Server. The existing MCPToolCallMiddleware chain (authenticator + persona authorizer + route policy + audit logger) governs REST callers identically to MCP callers. No auth, audit, or policy logic is reimplemented. If a persona is denied api_invoke_endpoint over MCP, the same persona is denied over REST. Audit events for REST calls appear in the same audit_logs table with the same field set as MCP calls.

Auth

The same headers other REST surfaces on the platform accept:

  • Authorization: Bearer <token>
  • X-API-Key: <key>

Both resolve through the platform's authenticator chain (OIDC bearers, OAuth 2.1 access tokens, configured API keys).

Request shape

{
  "method":          "GET",
  "path":            "/v1/things",
  "query_params":    { "limit": 50 },
  "headers":         { "X-Trace": "abc" },
  "body":            null,
  "timeout_seconds": 30
}

The connection is taken from the URL path and authoritatively overrides any connection field in the body.

Response shape

{
  "status":      200,
  "headers":     { "Content-Type": ["application/json"] },
  "body":        { "items": [ ... ] },
  "duration_ms": 245
}

Status-code contract

The platform's HTTP status is platform-level only. The upstream's HTTP status is surfaced inside the response body as InvokeOutput.status:

Platform status Meaning
200 The platform performed the upstream call. Read body.status for the upstream's response code.
400 Malformed request body (missing method/path, invalid JSON).
401 Missing or invalid credential.
403 Persona or route-policy denied the call.
404 Unregistered connection.
500 Internal failure.

This split keeps "the platform refused" distinguishable from "the upstream returned 4xx/5xx" for response-code routing in NiFi-like systems. A NiFi pipeline can route on the platform status and still inspect body.status inside the body for the upstream outcome.

The route is mounted only when at least one kind: api toolkit instance is loaded.

Apache NiFi recipe

Wire an InvokeHTTP processor to the gateway:

Property Value
HTTP Method POST
URL https://<platform-host>/api/v1/gateway/{connection}/invoke
Content-Type application/json

Set an X-API-Key (or Authorization) attribute on the FlowFile and reference it from an InvokeHTTP dynamic property mapped to the header name. The FlowFile content is the JSON body above; downstream processors can use EvaluateJsonPath to lift $.status and $.body into attributes for the response-code routing relationships.

Other clients

  • Airflow HttpOperator (or SimpleHttpOperator): set endpoint to the gateway URL, data to the request JSON, and pass the credential through extra_options.
  • curl: 
    curl -X POST \
  -H "X-API-Key: $PLATFORM_KEY" \
  -H "Content-Type: application/json" \
  -d '{"method":"GET","path":"/v1/things"}' \
  https://platform.example.com/api/v1/gateway/vendor/invoke
  • Generic HTTP clients in any language: the route accepts the JSON body shape above and returns the JSON response shape above. No MCP/JSON-RPC handshake.

What this release does NOT change

  • api_invoke_endpoint behavior over MCP: identical.
  • /api/v1/admin/tools/call behavior: identical.
  • Connection storage, OAuth refresh, static_headers, catalogs, route policy: all unchanged.
  • No new migrations, no new config keys, no new auth modes.
  • No breaking changes.

Upgrade notes

Drop-in upgrade from v1.62.x. No config edits required. The new route auto-mounts when an apigateway toolkit instance is present.

Other changes

  • ci: bump github/codeql-action from 4.35.4 to 4.35.5 (#426)

Installation

Homebrew (macOS)

brew install txn2/tap/mcp-data-platform

Claude Code CLI

claude mcp add mcp-data-platform -- mcp-data-platform

Docker

docker pull ghcr.io/txn2/mcp-data-platform:v1.63.0

Verification

All release artifacts are signed with Cosign. Verify with:

cosign verify-blob --bundle mcp-data-platform_1.63.0_linux_amd64.tar.gz.sigstore.json \
  mcp-data-platform_1.63.0_linux_amd64.tar.gz

Full changelog

v1.62.4...v1.63.0

Assets 25
Loading