> ## Documentation Index > Fetch the complete documentation index at: https://docs.armature.tech/llms.txt > Use this file to discover all available pages before exploring further. # Changelog > Product updates and improvements to Armature. Follow along with the latest changes to Armature. For documentation, see the [Introduction](/introduction). ## Week of June 5, 2026 ### New features * **Surface and restore archived workflows, benchmarks, and runs.** Archived items are no longer hidden out of reach — every archive surface now has a way to see what's in it and bring something back. [Runs](/workflows/runs) get a **Show archived** toggle that reveals archived rows with an **Archived** badge and an **Unarchive** action. Benchmark batches pick up the same **Show archived** toggle on **Past batches**, with an **Archived** pill and a **Restore** action wired to the existing un-archive endpoint. The [Workflows](/workflows/overview) page gets a new **Archived** tab listing every workflow set inactive (whether paused or deleted), each with a **Restore** action — this replaces the previously dead **Paused** tab, which never showed anything because pausing and deleting both flagged a workflow inactive and the active-only list hid it. Restoring an item now also clears it from the optimistic-hide set, so a just-restored row stays visible when you toggle **Show archived** back off. No action required. ### Bug fixes * **More accurate workflow pass rates.** Queued and in-flight [workflow runs](/workflows/runs) are no longer counted against a workflow's pass rate. Previously, an active run dragged the rate down for its entire duration (for example, 2 passed + 1 running showed 67% instead of 100%). Pass rates now only reflect finalized runs, while in-flight work continues to surface separately on the workflow detail page. ### Updates * **Product MCP setup forces an explicit API docs path.** Step 2 of the [Product MCP](/mcp-servers/connecting) create flow now requires you to pick **Upload OpenAPI now** or **Connect CI** rather than leaving the spec blank. Upload accepts paste plus `.json`, `.yaml`, and `.yml` file picker; CI mode surfaces the upload endpoint, source slug, environment, key purpose, and last successful or failed sync, with raw implementation details tucked behind a drawer. The setup recap reads either **OpenAPI uploaded** or **CI sync connected/waiting**, so there's no ambiguous "leave blank" state. No action required. * **Product MCP API connection step now reads as security-critical.** Step 3 of the create flow has been rewritten to make explicit that the validation mode you pick (validate before tools or presence only) governs whether fake or invalid caller credentials can see the tool catalog or run code — the credential is then forwarded upstream as configured. The heading, label, and supporting copy now lead with that contract instead of reading like generic configuration. No action required. * **Dedicated upload-key flow for Product MCP CI sync.** The `managed_mcp_upload` API key needed for the CI sync path is now mintable directly from the [Product MCP](/mcp-servers/connecting) setup, instead of being buried in generic [Settings → API keys](/settings/api-keys). The UI clearly separates **upload keys** from the caller/product API key used at runtime, so it's obvious which secret goes where. No action required. * **Explicit auth validation states on Product MCPs.** The detail view now distinguishes **no auth validation configured**, **validation failing**, and **validation passing** as separate states, and tool exposure depends on the validation actually passing — not just the presence of a config. A Product MCP can no longer present as ready while its auth path is unverified or broken. No action required. * **Activation guard on Product MCPs.** The **Activate** action is now disabled in the UI and rejected by the API unless the OpenAPI docs, generated tool catalog, auth configuration, and runtime/domain readiness are all complete. A partially set up [Product MCP](/mcp-servers/connecting) can no longer be flipped live by accident. No action required. * **Automatic domain provisioning for Armature-hosted Product MCPs.** Creating or activating a [Product MCP](/mcp-servers/connecting) now provisions the `mcp..armature.tech/` hostname end-to-end — DNS and the hosting project are configured automatically, and the detail view reports the domain as `provisioning`, `ready`, or `failed` so you can tell at a glance whether the public URL actually resolves. No more manual DNS work to bring a new Product MCP online. No action required. * **Denser Product MCP detail page.** The top of the [Product MCP](/mcp-servers/connecting) detail page now shows only what you need to triage the endpoint: name, status, the public MCP URL with a one-tap copy, setup readiness, and the primary actions. Metrics, diagnostics, the parsed API docs, and connection internals move into collapsed sections lower on the page. The page now immediately answers "What is the URL, is it live, what is missing?" The redundant **ENDPOINTS** eyebrow on the index page has also been removed, and the `mcp..armature.tech/` URL now appears prominently on every card with the same one-tap copy. No action required. ### New features * **Managed Code Mode MCP — host a Code Mode MCP from your OpenAPI spec.** Point Armature at your product's OpenAPI spec and we host a Code Mode [MCP server](/mcp-servers/connecting) for it at `mcp.armature.tech/mcp/product-mcp/`, with the same two-tool shape (`search_sdk` and `execute_script`) the bare [Armature MCP](/mcp-api/overview) already exposes — so coding agents call your API as a typed SDK in a sandbox instead of juggling a flat tool catalog. Uploads go through a signed `POST /api/openapi-artifacts/upload` from CI (editor role or higher, with `X-Armature-Timestamp` and `X-Armature-Signature` headers), and Armature compiles the spec into a generated client, SDK docs, and a search index per environment so search hits stay fast and scripts run against a stable shape. Sources are scoped per organization with a unique `clientName`, and only the source's owning org can reach its MCP — so every customer's managed MCP stays isolated. Per-call telemetry (request ID, tool name, status, duration, JSDoc `@intent`) flows into the same Session Analytics surface as bare Armature MCP, so you can see how agents actually use your API. Contact us to enable Managed Code Mode for your organization. ### Updates * **Armature [MCP API](/mcp-api/overview) tools now accept an optional `telemetry.intent` argument.** Every tool exposed by the Armature MCP endpoint (`/api/mcp`, including the public host at `mcp.armature.tech/mcp`) now advertises an optional `telemetry` object with a single string field, `intent` — a one-sentence description of what the user is trying to accomplish with the call. Armature uses the intent to attribute tool calls to user goals on the Session Analytics dashboard; the field is stripped before the tool handler runs and is never forwarded to your workflow logic. Existing clients keep working unchanged — calls without `telemetry.intent` succeed and still record a tool-call event, just with the intent recorded as `null`. The instrumented endpoint at `mcp-instrumented.armature.tech` and its `report_intent` / `report_blocker` / `report_frustration` tools are unaffected. See the [overview](/mcp-api/overview#optional-telemetryintent-on-every-tool-call) for an example. No action required. ### Bug fixes * **Clearer recovery from partial Product MCP setup failures.** When the docs upload step fails after the [Product MCP](/mcp-servers/connecting) source has already been created, the flow now lands on the new source's detail page with the real upload error shown inline under **API docs**, a **Retry upload** action next to it, and status held at **Needs setup** — instead of stranding you with a vague "Created, but docs upload failed" toast. You can see exactly what failed and fix it in place. No action required. * **OpenAPI uploads no longer fail with "Bucket not found".** The private bundle storage that backs [Product MCP](/mcp-servers/connecting) OpenAPI uploads is now provisioned in every environment before the feature is enabled, so the upload step in the create flow can no longer fail with a missing-bucket error on a fresh workspace. No action required. ## Week of June 4, 2026 ### New features * **Self-serve Product MCPs.** You can now turn your product API into an Armature-hosted [MCP server](/mcp-servers/connecting) from the dashboard — without standing up your own gateway. A new **Product MCPs** sidebar entry lists your endpoints as cards and steps you through a four-part create flow: name and base URL, upload an OpenAPI spec to derive the tool catalog, configure how the caller's product API credential is presented (bearer header, custom header, or query param), and publish. Once activated, the MCP is reachable at `https://mcp..armature.tech/` and a compliant MCP client signs in with the caller's own product API credential — there is no second end-user credential and Armature never sees the raw value. The detail view shows setup readiness, runtime health, the parsed API docs, and the API connection summary, and individual modals let you update settings, rotate the connection, or re-upload the spec. Two validation modes are supported: **validate before tools** (the default, which checks the credential against your upstream before each session) and **presence only** (faster, but requires explicitly confirming the security tradeoff). Rolling out behind a feature flag — the **Product MCPs** sidebar entry, the dashboard APIs, the public `mcp..armature.tech/` endpoint, and the OpenAPI upload path stay hidden until your workspace is opted in. Contact us if you'd like your workspace turned on — see [Connecting an MCP server](/mcp-servers/connecting) and the [MCP API overview](/mcp-api/overview). ### Updates * **Product MCP setup tightened across API docs, auth, activation, and the public hostname.** Follow-up polish on the [Self-serve Product MCPs feature](#week-of-june-4-2026) above, all behind the same `product_mcp` feature flag. The API docs step now forces an explicit choice between **Upload OpenAPI now** (paste or pick a `.json`, `.yaml`, or `.yml` file) and **Connect CI** (which shows the upload endpoint, source slug, environment, key purpose, and waiting-vs-synced status), instead of treating it as a vague optional field. The CI path has its own guided action for creating a dedicated `managed_mcp_upload` API key from inside the Product MCP setup flow, so you no longer have to hunt for it in generic **[Settings → API keys](/settings/api-keys)** — upload keys are visually distinguished from caller and product API keys. The API Connection step is now framed as a security gate: the heading makes clear it validates caller credentials before tools are exposed and forwards the same credential upstream, and auth readiness is shown as one of three explicit states — **no validation configured**, **validation failing**, or **validation passing** — with tool exposure tied to the passing state rather than just the presence of config. **Activate** is now disabled (and rejected by the API) until docs, generated capabilities, auth config, and runtime/domain readiness are all complete, so a partially set-up Product MCP can no longer go live. The Armature-owned hostname `https://mcp..armature.tech/` is now auto-provisioned end-to-end on create and activate — Armature ensures both the Cloudflare DNS `CNAME` to `cname.vercel-dns.com` and the Vercel project domain exist, with status tracked as `provisioning`, `ready`, or `failed` — so the public URL resolves and serves the MCP without manual DNS work. The detail page has also been thinned: the top section shows only name, status, public MCP URL, setup readiness, and primary actions, with metrics and diagnostics moved into collapsed sections lower on the page; the public URL itself is now prominent on cards and detail pages with a one-click copy button. If something fails partway through create — for example, an OpenAPI upload error — you now land on the created Product MCP's detail page with the real error inline in **API docs**, a **Retry upload** action, and status held at **Needs setup**, instead of being stranded by a vague "Created, but docs upload failed" toast. No action required — existing opted-in Product MCPs pick up the new states, guardrails, and provisioning on the next save. * **`armature.tech` testing tile rewritten for the analytics-first framing.** Following last week's [landing-page rebuild around Agent Experience](#week-of-june-3-2026), the `03 · Testing` feature tile on [`armature.tech`](/workflows/overview) now reads **"Tests and benchmarks on every harness."** with a one-line body about running complex workflows across every model and harness and benchmarking your agent experience against competitors. The supporting harness × workflow pass/fail matrix visualization is unchanged. No action required. ## Week of June 3, 2026 ### New features * **Analytics ingest API keys for self-hosted MCPs.** Self-hosted customer MCPs using `@armature-tech/mcp-analytics` `^0.3.0` can now authenticate ingest pushes with a bearer API key minted from **[Settings → API keys](/settings/api-keys) → Analytics ingestion keys**, instead of wiring up the previous HMAC path. Naming the key registers a matching MCP source under the same name in one step; the token is shown once with a copy button and a "won't be shown again" warning, then **Rotate** and **Revoke** are available from the list. The verifier resolves both the workspace and the MCP source from the key itself, so the SDK no longer needs an `X-Armature-MCP-Server-Id` header or `mcp_server_id` event field. Available to owners and admins on workspaces with **Session Analytics** enabled. Existing HMAC-authenticated gateways keep working unchanged — see [Authenticating with the Armature MCP API](/mcp-api/authentication). No action required. * **Public REST API for sources, workflows, runs, and insights.** Armature now exposes an API-key authenticated REST surface at `/api/armature/v1/*`, so agents and back-office tools can read and drive your workspace without going through the dashboard or the MCP transport. Endpoints cover organization context (`/org`), MCP sources (`/mcp-servers`, including create), workflows and manual dispatch (`/workflows`, `/workflows/{id}/runs`), [run](/workflows/runs) evidence, traces, evaluations, and tool calls (`/runs`, `/runs/{id}`, `/runs/{id}/trace`, `/runs/{id}/evaluation`, `/runs/{id}/tool-calls`), and the Session Analytics rollups (`/insights/overview`, `/insights/topics`, `/insights/searches`, `/insights/sessions`). The full machine-readable spec is served at `/api/armature/v1/openapi`. Authentication and role scoping reuse the same Armature API keys as the [MCP API](/mcp-api/overview) — see [Authenticating with the Armature MCP API](/mcp-api/authentication) and the [role table](/mcp-api/roles). Insights endpoints require **Session Analytics** to be enabled for the workspace. No action required. * **Managed Code Mode `execute_script` now runs in an isolated per-call sandbox.** Every `execute_script` turn on an Armature-managed [Code Mode MCP](/mcp-api/overview) — the bundled SDK surface paired with `search_sdk` and `execute_script` — now runs in a fresh, non-persistent Vercel Sandbox with a `deny-all` network policy, signed request authentication, and a SIGKILL-enforced per-turn timeout. Only the user's script, the public SDK bundle, and the replay history for the current turn enter the sandbox — no backend secrets, no other tenants' state, and no carry-over between calls. The sandbox shape and limits (runtime, vCPU, memory, log cap) are uniform across customers, so a misbehaving script can't starve a neighboring workspace. No action required — managed Code Mode endpoints pick up the isolated runtime automatically. ### Updates * **`armature.tech` landing page rebuilt around Agent Experience.** The marketing site has been reframed from synthetic MCP and CLI testing to the analytics product — *"PostHog for agent sessions"* — keeping the existing brutalist styling and section structure. The hero rolls between PostHog, Amplitude, and Mixpanel as the analogy and pairs with a new UI-era → agent-era illustration; the **Problem** section now resolves to capturing the real agent session rather than running synthetic tests; the **Features** strip leads with **Session Analytics**, the auto-generated hosted Code Mode MCP, and an expanded "and more" grid, with **Testing & Benchmarks** demoted to a secondary tile. **Get started** now presents two setup paths — the recommended hosted Code Mode MCP, or wrapping your existing MCP with the Armature SDK. A new **FAQ** (with matching JSON-LD for search) contrasts Armature against PostHog/Amplitude and against LLM observability, and the final CTA and footer tagline both lead with the analytics framing. The Armature app at `app.armature.tech` is unaffected. No action required. * **Search and pagination on the public reviews directory.** The [public reviews directory](/mcp-api/overview) at `/reviews` now paginates 12 targets per page with **Previous** / **Next** controls and a `Showing X–Y of N` counter, replacing the previous "View all" expand affordance. The search box now queries the server so a search like "github" surfaces every matching target across all pages — not just the ones currently rendered — and resets to page 1 on each keystroke. Searching shows a `N targets matching \"…\"` summary, and an unrecognized query renders an empty state instead of an empty grid. Cards still rank by overall score. No action required. * **MCP OAuth consent screen no longer endorses the client's self-asserted name.** Because the [Armature MCP API](/mcp-api/overview) supports open dynamic client registration, any MCP client can register under a familiar name (for example, *Claude* or *Cursor*) with its own redirect URI. The consent screen previously led with that self-asserted name as the headline (*"Authorize Cursor"*), which made an attacker-controlled app look legitimate enough to phish a workspace-scoped consent. The consent screen now leads with a neutral headline — *"Authorize access to your workspace"* — and surfaces the redirect destination host (*"Sends approval to …"*) as the primary trust signal, the one field an attacker cannot forge. The claimed client name still appears as a quoted, self-reported label so legitimate connections remain recognizable. Review the destination host before approving — see [Authenticating with the Armature MCP API](/mcp-api/authentication). Existing grants and previously approved clients are unaffected. No action required. * **Public Leaderboard renamed to Benchmarks at `/benchmarks`.** The public benchmark surface is now called **Benchmarks** (plural) and lives at [`armature.tech/benchmarks`](/workflows/overview), reflecting that the catalog spans multiple categories — observability, CRM, database, cloud deploy, and more — rather than a single board. The footer, sitemap, marketing-site nav, and announcement bar all point at the new path. The previous `/leaderboard` URL still resolves so the app's own deep links and existing per-category paths (for example, `/leaderboard/observability/datadog`) keep working. No action required. * **Permanent announcement bar on `armature.tech` links to Benchmarks and Reviews.** The marketing homepage and About us page now carry a slim, permanent bar above the topbar with direct links to **Benchmarks** and **Reviews**, so visitors who land on the marketing site can reach the two public surfaces without scrolling or hunting through the nav. The existing topbar links and CTAs are unchanged. No action required. * **Public reviews directory is paginated and curated.** The [public reviews directory](/changelog/overview#week-of-may-31-2026) at `/reviews` now loads in pages instead of streaming the entire catalog on first paint, so the grid stays responsive as more reviewed targets land. The directory default is 12 cards per page (up to 48), with the score-ranked ordering and the name/vendor search box unchanged — the search query, page, and page size travel as `?q=`, `?page=`, and `?limit=` so visitors can deep-link to a specific result page. The response now carries a `meta` block alongside `targets` with `count`, `page`, `pageSize`, `totalPages`, `hasPreviousPage`, and `hasNextPage` for the surrounding UI. Targets that haven't been cleared for the public directory — for example, internal-only subjects under audit — are also filtered out of both the directory and per-target detail pages, so `/reviews` only lists subjects that pass the public-review allow rules. No action required.\n\n- **Unified chrome across Benchmarks, Reviews, and the marketing site.** Every page in the public Benchmarks and [Reviews](/mcp-api/overview) sections — landing, per-category benchmark pages, vendor detail pages, the methodology page, the reviews directory, and per-target review pages — now uses the same header, footer, width (1200/1144), and 15px body type as [`armature.tech`](/workflows/overview), so moving between the marketing site, Benchmarks, and Reviews reads as one continuous surface instead of three differently-styled apps. Every benchmark and reviews page also picks up a consistent clickable breadcrumb bar with a one-click cross-section toggle between **Benchmarks** and **Reviews**, so jumping from a benchmark category to the reviews directory (or back) no longer requires going through the topbar. The methodology page hero is now on the light background to match the rest of the site, the Benchmarks landing leads with the agent marquee above a refreshed **How it works** band with a **Read the full methodology** link, and the OpenCode logo has been retouched to match the home page. No action required. ### Bug fixes * **Public reviews directory search now treats `%`, `_`, and `!` as literal characters.** The search box on the [public reviews directory](/mcp-api/overview) at `/reviews` previously interpreted `%` and `_` as SQL wildcards — so a query like `100%` matched every target instead of only ones whose name or vendor actually contained `100%`, and `_cli` matched any three-or-more-character substring instead of the literal underscore-cli. Searches containing those characters (and the `!` escape character) are now matched literally, so the `N targets matching "…"` count reflects what you typed. Cards still rank by overall score and pagination behavior is unchanged. No action required. * **XSS-shaped Agent Review submissions are quarantined before they reach the public directory.** The moderation gate on the public [Agent Review intake](/mcp-api/overview) — the `/mcp/agent-review` MCP endpoint and matching HTTP API — now flags submissions that carry XSS-shaped payloads in any free-text field and routes them into the same quarantine path as secret-pattern, raw-log, and stack-trace hits, so the offending text never surfaces on the [public reviews directory](/mcp-api/overview) at `/reviews` or a per-target detail page. The detector covers HTML tags (open, close, and self-closing), `javascript:` URLs, event-handler attributes (`onclick=…`, `onerror=…`, `onmouseover=…`, and the long tail), `alert(`, and normalized `document.domain` probes — including spaced, hyphenated, and underscored variants — so common evasions still match. Submissions that name an XSS pattern when describing a real product issue ("the API returns `