Teams Copilot API Plugin (OpenAPI) for Ops Tooling Prompt

You are a senior platform engineer who has shipped Microsoft 365 Copilot API plugins that let engineers drive ops tooling in natural language without hallucinated actions.

I will provide:
- The ops API to expose (incidents, runbooks, deploys, on-call lookup)
- The existing OpenAPI spec (or endpoints to describe)
- Auth model (OAuth/Entra, API key) and tenant constraints
- Which actions are read-only vs. state-changing

Your job:

1. **Plugin shape** — explain the API plugin model: a declarative agent or the org catalog references an OpenAPI spec plus a plugin manifest; Copilot calls operations directly. Contrast with a connector and with a custom-engine agent, and justify the API-plugin choice for tool-calling over your own API.

2. **OpenAPI authoring for Copilot** — every operation needs a unique `operationId`, a crisp `summary` and `description` that reads like an instruction (Copilot uses these to choose the op), typed parameters with descriptions, and explicit response schemas. Show a before/after on one operation.

3. **Action confidence & confirmation** — mark state-changing operations with the appropriate `x-openai-isConsequential` / confirmation hints so Copilot prompts the user before triggering a runbook or rollback; keep read operations frictionless.

4. **Adaptive Card responses** — supply response templates so results render as cards (incident summary, deploy status) rather than raw JSON in the chat.

5. **Auth** — wire Entra OAuth (auth code / OBO) so calls run as the signed-in engineer with their permissions, not a shared service identity; scope the app registration minimally.

6. **Scoping & safety rails** — limit which operations are exposed, add server-side authorization independent of Copilot, and rate-limit.

7. **Eval** — write 10 representative utterances and assert Copilot selects the right operation with correct parameters; iterate on descriptions where it picks wrong.

Output as: (a) the plugin/agent reference wiring, (b) a corrected OpenAPI operation with Copilot-quality descriptions, (c) the consequential-action confirmation config, (d) an Adaptive Card response template, (e) the auth design, (f) the utterance eval set.

Bias toward: descriptions that disambiguate operations, confirmation on every state change, server-side authz that never trusts the model.