One Agent

One Agent gives AI assistants a bounded, audited interface to One. Use its native tools before opening One Admin in a browser whenever the requested capability is available.

Why use One Agent

Agent tokens are scoped to one workspace, optional allowed Apps, and explicit read/write domains.
Operational reads are bounded and redacted. Tools do not expose database access, raw SQL, credentials, password hashes, provider tokens, or unrestricted customer data.
Mutations start as saved dry-run action plans. Applying a plan is a separate, explicitly approved action and is recorded in the Agent audit log.
One resolves provider connections, App ownership, and environment boundaries server-side.

Chrome is appropriate only for a genuinely unsupported UI-only action. Do not use browser sessions, dashboard cookies, or direct database access to bypass a missing scope, App restriction, redaction, preview, or approval step.

Capability map

Workspace and Auth identity

one_get_context reads the token’s workspace, scopes, App restrictions, and visible Apps.
one_inspect_auth_identity reads one exact Auth identity by email and Test/Live environment. It requires auth:read and a workspace-wide token and returns only redacted health state.
one_plan_cleanup_test_orphan_auth_identity creates a Test-only dry-run deletion plan for an identity with no customer link, workspace-customer link, active session, or active challenge. It cannot target Live and does not apply the plan.

Customers, commerce, and App Store operations

one_query_app_data performs bounded allowlisted operational reads without SQL.
one_plan_revoke_customer_entitlement proposes an exact grant revocation while preserving the purchase ledger.
one_audit_app_store_catalog, one_preview_app_store_price_change, one_get_app_store_pricing_plan, one_plan_apply_app_store_price_change, and one_get_app_store_pricing_operation cover mapped App Store pricing audit, preview, approval, and verification.
one_list_product_offers, one_discover_product_offers, one_get_product_offer, one_plan_set_product_offer_distribution, one_preview_product_offer_operation, one_get_product_offer_operation_preview, one_plan_apply_product_offer_operation, and one_get_product_offer_operation cover redacted offer discovery and bounded operations.

Paywalls, surfaces, and campaigns

one_get_creative_contract, one_list_paywalls, one_get_paywall, one_list_in_app_surfaces, and one_get_in_app_surface inspect current creative contracts and records.
one_list_paywall_placements, one_plan_manage_paywall_1_1, one_plan_manage_in_app_surface_1_1, one_plan_update_placement_fallback, and one_plan_upsert_paywall_placement inspect or propose explicit creative routing and fallbacks.
one_list_campaigns, one_get_campaign, one_list_provider_events, and one_plan_replay_provider_events inspect campaign routing and bounded provider-event replay.

Diagnostics, reports, Apps, and integrations

one_get_ios_release_readiness, one_list_crash_groups, and one_get_crash_group provide bounded release and native crash diagnosis.
one_list_reports and one_run_report expose registered semantic reports without arbitrary queries.
one_plan_create_app, one_plan_update_app, one_plan_apns_credentials, and one_plan_configure_customer_auth create scoped dry-run configuration plans.
one_create_action_plan, one_get_action_plan, and one_apply_action_plan provide the generic audited plan lifecycle.

iOS Auth migration testing

The bundled one-ios-auth-migration-test skill validates historical-to-current OneSDK upgrades, Keychain namespace isolation, session restoration, and tenant-owned legacy bridges. It uses One Test data and a newly created disposable Device Hub simulator. It never reuses, erases, or resets an existing simulator, and it never moves tenant-specific migration behavior into the shared One API or SDK.

Auth identity safety

Auth inspection requires a workspace-wide token because the identity is workspace-scoped rather than owned by one App. It returns provider type, password-presence, verification, link counts, and aggregate session/challenge state, but no secrets or provider account identifiers.

Automated orphan cleanup is deliberately Test-only. Plan creation and apply both re-check the exact identity ID, normalized email, update timestamp, provider set, and related-row counts. Live identities and any identity with active or linked state are blocked.

Usage, errors, and refund inspection

Read Usage and diagnostics for the measurement and error model. The updated Agent source provides:

Task	Tool	Required scope
Read measurement revisions, categories, and available entitlements	`one_get_usage_definitions`	`apps:read`
Read customer summary or daily/session pages	`one_get_customer_usage`	`apps:read`, `reports:read`
Inspect saved refund requests and preview evidence	`one_get_refund_requests`	`apps:read`, `reports:read`
Propose a metric or category registration	`one_create_action_plan`	`apps:write`
Read a caught-error occurrence	`one_query_app_data` with exact event ID and `includeDebugMetadata: true`	`apps:read`
Diagnose a native crash	`one_list_crash_groups`, `one_get_crash_group`	`apps:read`

Registration plans use apps.register_usage_metric or apps.register_usage_category, an exact App and environment, and a request containing definition. The server records the current registry state. Apply only after the user approves the exact definition; if that state changes, make a new plan. Register categories before planning measurements that depend on them. Registration does not add instrumentation to an app or create historical usage.

Refund inspection only reads existing requests and snapshots. Follow nextCursor until it is null when a complete request list is required. The optional transactionId is One’s billing transaction ID. Consumption-response sending is disabled; these tools cannot enable it or change customer consent.

Caught errors expose bounded metadata.handledError, with startup or runtime phase. Native crashes retain their full crash-report path. Missing or expired error details mean unavailable evidence, not a successful operation.

The added registry/refund tools and registration actions need the updated API to be deployed and the local plugin reloaded. Check available tools and token scopes before using them; never bypass a missing capability with cookies or SQL.