Integrations

MCP tool reference

The Packagento MCP server exposes 53 tools. Composite tools wrap multi-step outcomes; individual tools cover one operation each. Tools are filtered per session by the caller's buyer / vendor role, so a buyer never sees vendor-only tools (and vice versa).

Composite outcome tools

Prefer these when the user goal matches - they save 2-5 round-trips compared to chaining individual tools.

  • get_my_dashboard: identity + active org + every org + counts (projects, licences, orders, pending invites). The best first call in any session.
  • get_vendor_dashboard: per-vendor: packages + recent orders + Stripe Connect readiness, in one call.
  • set_active_org: switch the active-org context; subsequent tool calls see the new org as active. Cart, projects, licences, orders, and webhooks are all org-scoped.
  • setup_project: create a buyer project AND mint its first Composer credential pair, returning a ready-to-paste auth.json snippet in one call.
  • publish_packages_from_repos: ingest one or many packages from Git URLs; per-repo, returns oauth_url if the Git integration is not yet connected, otherwise package_id + composer_name. Plural in / plural out.
  • purchase_and_install_packages: add to cart → off-session charge → attach each licence to a project → return auth.json. Plural in / plural out; falls back to a checkout URL when no saved payment method is supplied.
  • bootstrap_vendor: full vendor onboarding in one call: apply_as_vendor + start_stripe_connect_onboarding + start_git_integration, with a unified status response.

Read tools

Idempotent, read-only. Most accept limit / offset and a response_format flag - "concise" (default; trims internal columns), "detailed" (raw row), or "csv" (tabular list_*) / "yaml" (composites).

  • whoami: the authenticated customer + the active-org block.
  • list_orgs / list_org_members: org membership across every org the caller belongs to + per-org roster with roles + joined_at.
  • list_vendors / list_packages: the caller's vendors + each vendor's package catalogue (vendor-side).
  • list_licenses / list_projects: buyer-side entitlements + buyer projects (with their Composer credential pairs inline - public_key + private_key, re-readable any time).
  • list_orders / get_invoice: purchase history with currency_code + PDF invoice URL.
  • search_packages / get_package: public catalogue search + per-package metadata (is_purchasable + purchase_blocker tell you why a package can't be bought right now).
  • list_billing_addresses / list_payment_methods: saved billing addresses + saved Stripe payment methods on the active org.
  • list_git_integrations: connected Git providers + status (per-customer, NOT per-org).
  • get_stripe_connect_status: vendor's Stripe Connect onboarding state: charges_enabled, payouts_enabled, requirements summary.

Cart & checkout

  • view_cart: current active-org cart with line-item totals, per-vendor breakdown (subtotal + tax), and discounts.
  • add_to_cart / remove_from_cart: manage cart contents on the active-org cart.
  • place_order_with_saved_method: off-session charge against a saved payment method; returns order_id + invoice_id immediately, licences mint asynchronously via Stripe webhooks (discover via list_licenses).

Projects, credentials, licences, invites

  • create_project / update_project / delete_project: manage buyer projects on the active org.
  • rotate_credentials: mint a new Composer auth.json pair for a project; the prior pair is revoked atomically. Output carries the new public_key + private_key inline.
  • manage_license: attach or detach a licence to / from a project, or cancel a subscription. Single tool, action selector.
  • respond_to_invite: accept or decline a pending org-membership invite (action selector).

Billing & payment methods

  • add_billing_address / delete_billing_address / set_default_billing_address: manage saved billing addresses on the active org. Address book + default selection.
  • set_default_payment_method: choose which saved Stripe payment method off-session charges default to.

Org administration

  • create_org / update_org: team-org lifecycle (personal orgs are auto-created on signup and can't be recreated through MCP).
  • leave_org: remove yourself from an org. Owner protection applies - the last owner can't leave.
  • manage_org_member: one tool covers the full membership-admin surface: invite, revoke invite, remove member, change role (owner / admin / developer / billing / viewer).

Vendor identity & Stripe Connect

  • apply_as_vendor: register a new vendor under the active org; vendor moderation happens admin-side.
  • update_vendor_profile: edit display name, public profile copy, support email.
  • start_stripe_connect_onboarding: returns a Stripe-hosted onboarding URL; on completion Stripe webhooks flip the org's onboarding flags.

Package management (vendor)

  • add_package_from_repo: register a single package from a Git repo URL; for many at once prefer publish_packages_from_repos.
  • set_package_pricing: set or change list price + currency + subscription cadence; mirrors the storefront add-package wizard.
  • set_package_status: flip a package between enabled / disabled. Returns the new state.

Outbound webhooks (vendor)

  • add_webhook_endpoint / update_webhook_endpoint / delete_webhook_endpoint: outbound webhook lifecycle (Packagento → your service).
  • rotate_webhook_token: rotate the HMAC signing secret on an endpoint; the new secret is returned inline.

Git integrations

Git integrations are per-customer, not per-org - one GitHub or GitLab token covers every org you belong to.

  • start_git_integration: returns an OAuth URL for GitHub or GitLab; on completion the provider can be used by every vendor you own / belong to.
  • wait_for_git_integration: poll until the integration completes (or times out); avoids a busy-loop in the calling agent.
  • revoke_integration: disconnect a Git provider; revokes the stored OAuth token at the provider end.

Conventions

  • All input field names are snake_case (project_id, license_id, customer_id, …). Output fields follow the same convention.
  • Mutation tools accept an optional idempotency_key so retries are safe.
  • Destructive tools (delete_*, rotate_*, revoke_*, place_order_with_saved_method, etc.) accept dry_run=true to preview the action without committing.
  • Org-scoped operations read the active org from set_active_org; switch contexts explicitly rather than passing org_id on every call.
  • Project credentials (public_key + private_key) are retrievable any time via list_projects - they are NOT one-shot reveal credentials.
  • Every MCP request runs as you: same role checks, same org gates, same audit log. The assistant cannot perform anything you could not do yourself in the customer area.
  • Tools propagate W3C traceparent metadata; correlate Worker activity with Magento audit-log rows via the trace ID surfaced under /activity in the customer area.