1. Add the Trackly MCP server
Addhttps://mcp.tracklysms.com/mcp to your client’s remote MCP settings and select Streamable HTTP. Use this public endpoint for both new and existing Trackly accounts.
Follow your client’s authorization prompt to connect your account. A marketplace listing is not required to add the URL manually. Local stdio is a separate option that requires the Trackly service to be installed and launched on your machine.
2. Choose account connection or a private key
OAuth sign-in
In a compatible remote MCP client, choose its sign-in or authorization action for Trackly. The client opens Trackly, where an authorized account owner signs in or creates an account, completes email verification and any required second factor, and reviews the requested connection. General account connection does not require a Trackly umbrella organization and does not move an existing account. The owner consents in Trackly; the client handles the authorization code and tokens privately and returns control to the conversation. Never paste a password, verification code, authorization code, or access/refresh token into chat. Connection consent permits the assistant’s bounded tool access; it does not approve any message. The consent form defaults to a dedicated sandbox key, required send approval, and a daily live-send cap of 100. Review the limits before connecting: select specific sending lists or explicitly allow all current and future account lists. Owners can change the cap; live mode is offered only when enabled. The delegated API surface is limited to the agent workflow; it cannot mint keys, directly send messages, or administer the account. Message history is limited to the connection’s key. An owner can inspect and disconnect grants in Settings → Agent connections. Trackly requires authentication from the first MCP request, including tool discovery. Let the client’s OAuth flow handle the initial401 bearer challenge. For clients that do not support OAuth, use the private-key connection below.
Private-key fallback
An account owner opens Settings → API Keys and creates a dedicated key:
Copy the once-revealed key directly into your client’s private credential configuration. Never paste it into an assistant conversation, a tool argument, a shared configuration example, or source control. See API key management for rotation and pause controls.
3. Configure your MCP client
For a remote private-key connection, the client suppliesX-Api-Key. For local stdio, the Trackly service receives TRACKLY_API_KEY in its child-process environment. OAuth clients instead manage their bearer credential through sign-in; do not configure both credential headers. None of these methods requires the model to see the secret.
Each client has its own configuration format and environment-variable syntax. Use the instructions matching your installed client:
These are configuration references, not a claim of completed Trackly testing on every client. After changing a process environment, restart the client so it receives the new value; reconnecting an already running process may be insufficient.
Other clients, including Cline, Kilo, Goose, Amp, OpenClaw, Devin, and LM Studio/Bionic, have their own connection settings. Confirm the supported transport, private authentication, account identity, and dashboard-link behavior before using a new client. For Junie skills, install the complete reviewed Trackly skill directory, including its references, using Junie’s skill instructions.
For a custom agent without MCP, delegated OAuth for the API supports owner-approved registration preparation directly over REST after the app/API rollout. Request the API resource and
trackly.registration; optionally request trackly.agent for bounded approved SMS. Private, constrained API keys remain an option for the SMS v2 API, but do not authorize registration preparation. A delegated MCP token is audience-bound and must not be forwarded directly to the SMS API.
Building a compatible OAuth client
Use the server’s bearer challenge and protected-resource metadata to discover authorization. The MCP resource ishttps://mcp.tracklysms.com/mcp, with metadata at https://mcp.tracklysms.com/.well-known/oauth-protected-resource/mcp. Its authorization issuer is https://app.tracklysms.com, with metadata at https://app.tracklysms.com/.well-known/oauth-authorization-server.
The authorization server supports S256 PKCE authorization-code flow, client ID metadata documents, and dynamic client registration. trackly.agent authorizes the SMS workflow. The separate trackly.registration scope authorizes registration drafts and private previews where that extension is deployed; request both scopes if both workflows are needed. The separate trackly.offers scope authorizes offer and creative management. Existing connections require fresh consent to add registration or offers authority; neither token refresh nor private API-key headers grant it. The consent screen offers trackly.offers as an optional permission even when the client did not request it. The endpoint paths are /oauth/authorize, /oauth/token, /oauth/register, and /oauth/revoke. Use the exact registered redirect and resource identifier. Let the client’s OAuth implementation handle callbacks and private token storage; a copied token in a tool call is not an account connection.
Public clients use no client secret. Registration takes JSON; token and revocation requests use form encoding. Callbacks include state and the issuer’s iss value. Keep the consent flow in the browser where authorization began; it is bound to that browser and the signed-in session. Protocol endpoints allow non-cookie cross-origin clients, while human consent retains its Trackly origin and CSRF checks.
Complete an actual client sign-in before advertising compatibility. Keep the dashboard-link fallback for message review even if a client supports interactive URL requests.
Clients sharing a public network address can share admission limits; respect rejection and retry guidance instead of repeatedly starting sign-in or replaying token requests. Contact Trackly support if authorization remains unavailable.
4. Verify the account and sender
Ask the assistant to calltrackly_whoami with no arguments. Check that it reports the intended account, api_key.sandbox: true, and api_key.send_policy.require_confirmation: true. Use this response to determine mode; a key prefix does not reliably identify sandbox keys.
Next, call trackly_list_lists with {"status":"active","limit":50}. The selected list’s phone_number becomes the message’s list_number. Follow returned pagination if necessary. A list’s presence does not prove current send eligibility or recipient consent.
Call trackly_get_setup_status without arguments for read-only setup guidance. It reports stored connection, sender and billing evidence, a bounded recent-hold summary, and links to the next dashboard steps. These signals do not reserve a send, check funding with a payment provider, or prove compliance. Counts can be limited, and an absent recent hold does not prove no earlier message exists. The same guidance appears in Settings → Agent connections.
If there is no eligible sender, complete phone number and list setup in Trackly first. Sandbox also requires an eligible sender and may invoke your configured webhooks. It is not an accountless demonstration mode.
5. Run a reviewed sandbox send
Follow Send SMS with human approval. Verify the rendered content in Trackly, approve the hold, execute it, and read the sandbox result from that hold. Live use additionally requires live-enabled MCP access, a live key, sender readiness, billing eligibility, recipient consent, and an approved send. Switching a key or a prompt does not enable a sandbox-only MCP service to send live messages.Stop or repair a connection
Usetrackly_pause_key to stop the connected key, or pause it in Settings → API Keys. It will stop authenticating after a successful pause. An owner must inspect and resume it in the dashboard; the assistant cannot unpause itself.
For an authentication failure, inspect the key and account in Trackly rather than pasting a replacement credential into chat. Update the client’s private settings after a rotation, restart when necessary, and repeat trackly_whoami before continuing.
For OAuth, an owner can disconnect the grant in Settings → Agent connections and start a fresh connection from the client when needed. Disconnecting access does not recall already queued messages. Read back an uncertain send before reconnecting or attempting another message.
Connection requests expire after ten minutes. If signup or verification takes longer, keep the account you created and start a new connection from the client. A grant lasts at most seven days; clients refresh short-lived access tokens within that period, then need fresh authorization. Refresh credentials are one-use: replay can revoke the connection, so let the client handle recovery and never repeatedly submit an uncertain token exchange manually.