STRyNG API & MCP

Connect to the service

MCP uses authenticated Streamable HTTP. REST and MCP call the same service and enforce the same permissions.

MCP endpoint and token audience

https://stryng-assistant-dev-75ebolw66a-uc.a.run.app/mcp

REST base and token audience

https://stryng-assistant-dev-75ebolw66a-uc.a.run.app/v1

Authorization-server metadata

OAuth discovery JSON ↗

Protected-resource metadata

MCP resource ↗ · REST resource ↗

Use OAuth authorization code with PKCE S256 and an exact registered callback. Client ID Metadata Documents and preregistered clients are supported; dynamic registration is disabled. Access requires an eligible STRyNG DEV account and an approved client. Coordinate pilot access with info@stryng.app.

Follow the discovery endpoints for authorization and token exchange. Request the appropriate resource audience and scopes. STRyNG handles first-party account sign-in and consent; assistants receive delegated bearer tokens, never Firebase credentials. Send tokens only in the Authorization header. No API key is required.

Access tokens last 10 minutes. Refresh tokens rotate with a 30-day inactivity limit. Account/grant eligibility and revocation are checked on each call. Disconnecting prevents further delegated access. Delegated access is independent of the short browser sign-in session.

Permissions and account access

The normal reminders profile requests reading, saved context, drafting, content saving and alerts. Each capability is disclosed at consent. Read-only integrations can request stryng.read. Sharing, lifecycle and phone-location access require separate consent.

Scopes never override record permissions. Hidden Directed content is excluded for recipients, inactive sections stay out of active content, and pending members cannot edit. A combined change needs every applicable scope from the same authorization session.

After an explicit permission upgrade, stryng_resume_draft can carry an eligible draft forward for a fresh review. It preserves the original expiration and never transfers approval. Account linking itself does not approve a draft.

Draft → review → save

1. Discover and resolve. Read capabilities and account identity. Resolve people and places to returned references; do not invent IDs or coordinates.
2. Prepare. Submit one or up to five units. A draft is blocked when required questions remain, or ready when valid. Display the returned review faithfully.
3. Review and approve. Explicitly label Quick Reminder, List (one entry per line), Note, audience and alert. Show inferences and material consequences. A verified user action approves the exact revision and review hash.
4. Save and inspect. Commit the approved revision or retrieve its already-reserved operation. Poll the operation for individual outcomes. A grouped request may partially succeed; never repeat completed units.

App/web review is the established fallback. A host-specific inline card is being tested with ChatGPT. Muse’s trusted in-chat approval mechanism remains to be integrated and verified. A model-generated confirmed: true, a spoken “yes” alone, or possession of a review link cannot authorize saving.

Small, explicit content edits can use stryng_apply_edits: rename, List additions/checks/text/reordering, an existing Quick Reminder edit, Note append, or exact partial Note-text replacement. Destructive changes, alerts, sharing, lifecycle, section activation and mixed requests require review.

Draft preparation, revision and recovery do not save canonical content, send invitations or activate alerts. A successful canonical save may trigger the existing STRyNG sharing and scheduling behavior. Saved is distinct from active on a phone. Device activation stays unknown until matching evidence is available.

Public tool reference

All 16 operations below share one contract. Expand a tool for its REST mapping, base scopes and required inputs. The downloads include full nested input/output definitions. Effect descriptions supplement MCP hints; the host determines its own final permission classification.

Private review-session and approval callbacks are host-adapter interfaces, not model-callable tools. Their approval material is never included in this public reference. Shared chat, Social, purchases, calendar writes, account administration and saved-place administration are outside this API.

Request examples

These tools/call parameter examples are checked against the current schemas. First resolve Home, then use the actual returned reference. The IDs below are placeholders, not usable credentials or approval. Replace UUIDs for new requests; reuse the same UUID for a retry of the same request.

stryng_resolve_context

{
  "name": "stryng_resolve_context",
  "arguments": {
    "kind": "home",
    "query": "Home"
  }
}

stryng_prepare

{
  "name": "stryng_prepare",
  "arguments": {
    "requestId": "11111111-1111-4111-8111-111111111111",
    "units": [
      {
        "kind": "create",
        "unitId": "keys",
        "proposal": {
          "name": "Bring spare keys",
          "content": {
            "quickReminder": "Bring spare keys"
          },
          "audience": {
            "kind": "personal"
          },
          "alert": {
            "kind": "leave",
            "target": {
              "kind": "place",
              "ref": "returned-home-ref"
            }
          }
        }
      }
    ],
    "assumptions": []
  }
}

stryng_revise

{
  "name": "stryng_revise",
  "arguments": {
    "id": "returned-draft-id",
    "requestId": "22222222-2222-4222-8222-222222222222",
    "expectedRevision": 1,
    "edits": [
      {
        "kind": "patch_creation",
        "unitId": "keys",
        "patch": {
          "content": {
            "quickReminder": "Bring the spare car keys"
          }
        }
      }
    ]
  }
}

For REST preparation, send units and assumptions as the JSON body to POST /v1/drafts; move requestId into the Idempotency-Key header. For REST revisions, the draft ID is in the path. The OpenAPI download specifies the equivalent mapping for every operation.

“Milk, cereal and bananas” should become a three-entry List, rather than comma-separated Quick Reminder text. A saved Note need not have an alert. Quick Reminder-only creation requires an alert. Explicit destinations override inferred categories.

Location context and phone activation

Home and custom places come from account-synced app settings. References include permitted labels, provenance and revision information. Resolve ambiguity before preparing a ready draft. Another member’s private Home is not exposed through collaboration; symbolic recipient-home targets remain distinct.

Near alerts can use categories, brands or concrete places. Arrive/leave require supported concrete or relative targets. An explicit timezone is needed for ambiguous time context. Revisions to a saved destination require renewed review where they materially change a pending operation.

Current location requires explicit opt-in, the separate phone-location scope and a designated source phone. The API asks the existing STRyNG phone service for a best-effort refresh; it does not operate its own GPS tracker. The request deadline is 20 seconds, with up to 15 seconds for capture. A fresh observation must be no more than two minutes old and accurate within 120 metres.

If capture fails, report the last-known location with its original time and ask whether to use it, or request a saved place/address. Never call an old observation “current.” The selected coordinates and observation time are frozen in a draft revision; late observations cannot change the reviewed destination.

Report invitation pending, activation unknown, setup needed, scheduled for later and device-reported active separately. A successful push or database save is not evidence of phone activation.

Limits, concurrency and retries

Request rates are currently constrained by existing account-discovery quotas, external provider limits and service capacity. There is no published universal requests-per-minute allowance or production availability guarantee for this DEV pilot. Handle rate_limited and temporarily_unavailable without rapid retry loops; follow returned retry guidance when present.

Use the same retry identifier only with the same payload. Changed payloads under an existing identifier fail. Existing-record changes require an expected resource version; draft changes require an expected revision. Conflicts need a fresh read/review rather than silent overwrite. Revisions and recovery do not extend draft expiration.

Canonical changes are atomic per stryng. Grouped results contain separate unit outcomes. Retry only unresolved work within the allowed approval window, and retrieve the original operation before retrying an uncertain save.

Responses, errors and status

REST returns typed JSON success bodies: normally 200, or 202 for pending/running work. MCP returns corresponding structuredContent and readable content. Domain failures set isError; authentication and permission-upgrade signals may also use the host’s authentication metadata.

{
  "error": {
    "code": "stale_revision",
    "message": "Refresh the draft before continuing.",
    "retryable": false
  }
}

The message above is illustrative; clients should branch on codes and structured state, not exact text.

A structurally valid incomplete proposal may return a blocked draft instead of an HTTP error. Recheck access before showing cached results. Deleted or inaccessible records may return only a minimal own-action receipt.

Pilot testing and support

Arrange an approved DEV client, exact OAuth callbacks and a dedicated reviewer account with representative test data through info@stryng.app. Reviewer credentials must be supplied securely, not placed in this page, prompts or a documentation URL. No production credentials are needed.

1. Connect and verify the returned account and capabilities.
2. Resolve a fictional saved Home; prepare “Bring spare keys when I leave Home.” Require a Personal / Quick Reminder / Leave review.
3. Correct the draft and verify the review changes. Test denied permissions and expired/revoked connections.
4. Approve through an established verified channel, save once and retrieve the outcome. In-Muse confirmation remains a platform acceptance item.
5. Verify phone activation and physical delivery separately using an appropriately configured DEV phone.

The contracts and shared service have automated local coverage. That does not establish end-to-end Muse compatibility or physical alert delivery. Public documentation does not grant API access. STRyNG app location settings remain app-controlled.

Privacy policy · Terms of Service · Integration support