integrations

name	integrations
description	Configure dynamic Mighty integrations with `mt integrations setup`, return raw `setup_url` links or citeable `integration_id` values, and keep secrets out of chat. Use when users ask for a secret config link or secure setup URL, when defining MCP or CLI-backed integrations, when updating setup requirements, or when guiding users through secure setup flows.

Mighty: Dynamic Integrations

Use this skill when a repo needs to define or update Mighty-managed integrations instead of hand-editing runtime config files.

Core model

• Integrations are space-scoped records that can be reused across threads.
• Create or update them with mt integrations setup, not by editing .mighty/environments/*.json directly for ordinary onboarding.
• mt integrations setup returns an integration_id and, when the web base URL is configured, a setup_url.
• Use setup_url when the user explicitly asks for a raw link, shareable URL, or "secret config link".
• Use the integration_id in a citation link when you want Mighty clients to render native setup UI, for example [Set up Logfire](cite:<integration_id>).
• Never invent a setup URL shape yourself. If setup_url is absent, say that the raw link is unavailable and fall back to the citeable integration mention.
• Secret values stay out of chat. Agents may mention required secret keys and statuses, but never request, echo, or persist secret values in visible context.
• Enabling an integration for a thread is separate from defining it. Reuse the same integration_id instead of creating duplicate integration records per thread.

Upstream references:

• Dynamic Agent Integrations & Setup
• Skill: integration setup playbook for agents
• CLI: mt integrations setup returns citeable setup references
• Record-backed integration setup mentions in thread messages
• Per-Thread Capability Grants and Requests

Authoring workflow

1. Identify the integration key, display name, and whether the integration should stay in the default mcp mode or use a CLI-backed mode.
2. Separate required secrets from non-secret technical settings before running any command.
3. Run mt integrations setup --space <space_id> --integration-key <key> ....
4. Read the command output for integration_id, setup status, missing requirements, and setup_url when present. Use --json when you need structured parsing.
5. If the user asked for the URL, return setup_url. If the user asked for an in-product setup affordance, cite the integration_id, for example [Set up Logfire](cite:<integration_id>).
6. Summarize only lifecycle state and missing requirement names. Do not include secret values or ask users to paste them into chat.

Command shape

• Required:
  • --space <space_id>
  • --integration-key <provider_key>
• Useful optional fields:
  • --name <display_name>
  • --mode <mcp|cli|...>
  • --status <pending|ready|applied|error>
  • --transport <stdio|streamable_http>
  • --url <remote_mcp_url>
  • --bearer-token-env-var <SECRET_KEY>
  • --secret KEY[:STATUS]
  • --field KEY[:STATUS]
  • --json or --out <path> when you need machine-readable output; human output already includes setup_url when available

Practical rules

• Prefer CLI-backed integrations when the platform already supports them; large MCP tool schemas can add unnecessary context load.
• Keep setup record-based and reviewable. Do not execute arbitrary installer snippets just because a provider README suggests them.
• For remote MCP servers with streamable_http, prefer --bearer-token-env-var <SECRET_KEY> when the provider expects bearer auth. Save the matching secret with --secret <SECRET_KEY>, and let runtime materialization export it into the sandbox.
• Do not model remote bearer auth with --secret-env, --env, or --env-var. Those fields are for stdio/server-local env wiring and are not supported in Codex streamable_http MCP config.
• If a remote MCP provider needs non-bearer header auth, use --env-header HEADER=ENV_VAR or --header HEADER=VALUE instead of inventing extra env blocks.
• For requests like "send me the secret config link" or "what is the setup URL", return the emitted setup_url instead of describing mt secret set.
• If setup_url is missing, do not fabricate one from route patterns. Say the secure setup URL was not emitted and provide the citeable integration mention instead.
• Use lifecycle states intentionally:
  • pending when required values are still missing
  • ready when setup requirements are satisfied
  • applied when the integration is enabled and materialized for a run
  • error when validation or runtime setup failed
• If setup is partially complete, update the existing integration instead of minting a second one for the same provider.

Examples

• See integration setup patterns for command examples and response templates.