> ## 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. # Get started with Armature: your first workflow and monitor > Connect your first MCP server, create a tool monitor, write your first workflow, and view the results — end to end in a few minutes. 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. Go to [armature.tech](https://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. 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. The **Connect** step is where you tell Armature how to reach your MCP server. Fill in the following fields: | Field | What to enter | | ------------------ | ----------------------------------------------------------------------------------- | | **Server name** | A display name for this server, such as `production-mcp`. | | **Transport** | Choose `streamable_http` (default) or `sse`, matching your server's transport mode. | | **Base URL** | The full HTTP(S) URL of your MCP endpoint, for example `https://mcp.example.com`. | | **Authentication** | Choose the auth type your server requires (see below). | **Authentication types** * **Bearer token** — Armature sends `Authorization: Bearer ` 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. 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. 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**. 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. **Prompt** Write the instruction the agent should carry out. Be explicit about what the agent should do and which tools it should call. For example: ```text theme={null} 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. ``` **Schedule** Choose 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: ```text theme={null} 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](/workflows/authoring) for more examples. Click **Create** to save the workflow. Then click **Run now** to trigger a manual run immediately. 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 Connect Slack so your team gets notified the moment a workflow fails or a monitor fires. Learn how workflows, runs, criteria, monitors, and coverage fit together. Add additional servers to expand your test coverage across environments. Point your AI coding assistant at Armature to triage and repair failing workflows from your editor.