Skip to main content

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.

This guide walks you through the Armature onboarding flow from sign-up to your first passing workflow run. By the end, you will have a connected MCP server, at least one tool monitor running on a schedule, and a workflow that exercises your server and grades the results automatically.
1

Create your account and workspace

Go to armature.tech and sign up with your email address or Google account. After verifying your email, the onboarding wizard opens.Name your workspace. Enter a display name for your organization — for example, Acme Engineering. Armature auto-generates a URL-safe slug from the name. You can change the slug before continuing, but not after the workspace is created.
Your workspace is where your MCP servers, workflows, monitors, alert rules, and team invitations all live. If your company already has a workspace, ask an admin to send you an invitation link instead of creating a new one.
2

Choose a plan

Select a billing plan. All paid plans include the full feature set — workflows, tool monitors, coverage reports, and the MCP repair API. You can choose monthly, quarterly (10% savings), or annual (20% savings) billing.If you want to evaluate Armature before committing, select Skip for now. Your workspace starts in read-only mode: you can browse the dashboard but cannot create MCP servers, monitors, workflows, or API keys until you subscribe.
3

Connect your first MCP server

The Connect step is where you tell Armature how to reach your MCP server. Fill in the following fields:
FieldWhat to enter
Server nameA display name for this server, such as production-mcp.
TransportChoose streamable_http (default) or sse, matching your server’s transport mode.
Base URLThe full HTTP(S) URL of your MCP endpoint, for example https://mcp.example.com.
AuthenticationChoose the auth type your server requires (see below).
Authentication types
  • Bearer token — Armature sends Authorization: Bearer <your-token> on every request. Paste your token in the Secret value field.
  • API key header — Armature sends the token in a custom header. The default header name is x-api-key, but you can change it to any header name your server expects. Paste your key in the Secret value field.
  • Custom headers — Paste a JSON object of additional headers, for example {"X-Workspace": "prod"}. Use this when your server needs headers beyond standard auth.
  • None — No authentication required.
Auth tokens are stored encrypted in AWS Secrets Manager and are never written to the Armature database. The token value is shown only once — during entry. Store a copy somewhere safe before continuing.
Once you click Test connection, Armature saves the server record and immediately calls your server’s initialize and listTools endpoints. If the probe succeeds, the wizard advances to the monitor step. If it fails, you will see an error message with troubleshooting hints — check that your transport type matches and that the URL is publicly reachable.
If you do not have an MCP server URL ready, click I do not have an MCP URL handy for links to hosted MCP servers and starter frameworks you can deploy in minutes.
4

Set up tool monitors

After a successful probe, Armature shows you the tools it discovered on your server and lets you select which ones to monitor.How monitors work. A tool monitor pings a single tool on a fixed interval — 1 minute, 5 minutes, 15 minutes, or 1 hour — and records whether it passed (returned without error), failed (returned isError: true), or errored (transport failure). Monitors give you uptime visibility for individual tools without running a full agent workflow every time.Selecting tools. Armature pre-selects up to three read-only tools (names starting with get_, search_, list_, or read_) because they are safe to call repeatedly. Mutating tools (names starting with create_, delete_, update_, send_, etc.) are listed but not pre-checked — review them carefully and provide the required JSON arguments before enabling them.For tools that require arguments, fill in the argument fields before saving. Armature validates the arguments against each tool’s input schema.Click Save monitors when you are done. Armature creates the monitor records, runs the first check immediately, and takes you to the completion screen.
You can always add more monitors later from the MCP Servers page. Click any server card, then click Live probe to rediscover tools and open the monitor wizard again.
5

View your first monitor result

The completion screen polls for the result of the first check. Within a few seconds you will see one of two outcomes:
  • Green check — The tool responded without error. The response time is shown. Your monitor is live and will keep running on schedule.
  • Red alert — The tool returned an error on the first check. The monitor is still active and will keep running. Review the error message and fix your server or argument configuration.
After 10 seconds the dashboard redirects automatically. From there you can proceed to Set up alerts (so failures page you on Slack) or Invite teammates.
6

Create your first workflow

Tool monitors check uptime. Workflows check behavior. A workflow dispatches an AI agent against your MCP server with a prompt, then grades the result against criteria you define.Navigate to Workflows in the sidebar and click New workflow. Fill in the form:Identity
  • Name — A short label teammates will see in the run list, for example Create order and verify ID.
  • Description — Optional summary to help teammates understand the test’s purpose.
Connection
  • MCP server — Select the server you just connected.
  • Auth profile — Leave as “Use server default” unless you have multiple auth profiles for this server.
Models
  • Select one or more tester models. Each selected model runs the same workflow on the same schedule with staggered start times, which helps you detect model-specific regressions.
PromptWrite the instruction the agent should carry out. Be explicit about what the agent should do and which tools it should call. For example:
Create a new order for customer ID "test-cust-001" with quantity 1 of SKU "WIDGET-42".
Report the order ID returned by the server.
ScheduleChoose a preset (Manual, Every 15m, Every 30m, Hourly, Daily 09:00) or enter a custom cron expression. Start with Manual while you tune the criteria, then switch to a schedule once the workflow is stable.Success criteria (on the Success criteria tab)Write one criterion per line. Each line is a plain-English statement that must be true after the agent acts. The evaluator model checks each criterion independently. For example:
The agent calls create_order exactly once.
The response includes an order_id field.
No delete_order tool is called during the run.
Write criteria as observable, externally verifiable outcomes. Avoid vague criteria like “works correctly”. Prefer specific criteria like “The agent reports the order ID returned by create_order”. See workflow authoring guidelines for more examples.
Click Create to save the workflow. Then click Run now to trigger a manual run immediately.
7

View run results

After the agent finishes, open the run from the Workflows page run history tab or from Run history in the sidebar.Each run shows:
  • Overall status — pass (all required criteria met), partial (some criteria met), fail (required criteria not met), or error (the agent itself errored out).
  • Criteria results — Each criterion is evaluated individually with a pass, partial, or fail verdict and an explanation from the evaluator model.
  • Tool call trace — A full list of every tool the agent called, including inputs, outputs, and whether each call succeeded or returned an error.
If the run failed, inspect the criteria that did not pass and the tool calls that correspond to them. You can adjust the prompt or criteria and run again manually until the workflow is stable.
Once a workflow is saved, you cannot edit the prompt or criteria in place — edits create a new immutable version. The version history is preserved so you can always see what changed between runs.

​
What to do next

Set up Slack alerts

Connect Slack so your team gets notified the moment a workflow fails or a monitor fires.

Understand key concepts

Learn how workflows, runs, criteria, monitors, and coverage fit together.

Connect more MCP servers

Add additional servers to expand your test coverage across environments.

Use the MCP repair API

Point your AI coding assistant at Armature to triage and repair failing workflows from your editor.