Postback MCP for agents
Connect an MCP-compatible agent through a browser-approved OAuth flow. Each connection is restricted to one Postback app. See the MCP overview for use cases and the security model.
Connect
Add the remote server URL
https://api.postback.sh/mcp
Your client must support remote Streamable HTTP MCP and OAuth with PKCE, Resource Indicators, and Dynamic Client Registration as the compatibility registration path used during private preview.
Review the browser prompt
Sign in to Postback. Check the requesting client and redirect hostname, choose one app, and review every permission before approving it. Read scopes are non-destructive. Apple Ads and TikTok Ads write scopes are shown separately when requested.
Ask a revenue question
Try: “Which acquisition sources create paying users, where does the onboarding funnel lose the most people, and what should I investigate next?”
Available tools
| Tool | Purpose | Access |
|---|---|---|
| list_apps | List the app visible to this connection | Read |
| diagnose_app | Check ingestion, attribution, and integration health | Read |
| get_analytics_overview | Compare acquisition performance and revenue | Read |
| get_funnel_performance | Find onboarding and conversion drop-offs | Read |
| get_tiktok_ad_performance | Compare individual TikTok ads before a status change | Read |
| get_integration_status | Check connected and verified integrations | Read |
| list_recent_events | Read event metadata without raw parameters | Read |
| explain_attribution | Explain the evidence behind one install | Read |
| propose_ad_change | Create a plan from live Apple Ads or TikTok Ads state | Plan |
| list_ad_changes | List recent plans and their status | Read |
| get_ad_change | Read exact values, approval, and execution state | Read |
| execute_approved_ad_change | Execute and verify a separately approved plan | Write |
Read tools are non-destructive. Planning does not touch an ad account. The execution tool requires a provider-specific write scope and a separate dashboard approval for the exact plan.
Human approval for ad changes
- The client reads revenue and funnel evidence.
- It calls
propose_ad_changewith one bounded change and a reason. - You review current and proposed values in the Postback dashboard.
- The client can execute only after you approve that exact plan.
- Postback checks live provider state, applies the change once, and verifies the result.
The MCP credential cannot approve a plan. Plans expire after 30 minutes, and an ambiguous provider failure is not replayed automatically.
OAuth security
Short-lived and rotating
Access tokens last one hour. Refresh tokens rotate, expire after 30 days, and trigger full revocation if reused.
Bound to one resource
Tokens are valid only for the Postback MCP URL, one organization member, and one selected app.
- Redirect URIs must match the registered client exactly.
- Authorization codes are one-time and protected by PKCE S256.
- Bearer tokens are never accepted in URL query strings.
- Organization membership removal invalidates access.
- Requests are rate-limited and metadata-audited.
- Ad changes require an explicit provider scope and a separate dashboard decision.
For shell automation, see the Agent CLI guide.