---
title: Add the Context.dev MCP
description: Search the web and read the pages issues link to. Claims about the live web get read from the page itself instead of guessed at.
type: guide
summary: One CLI command, one Connect connector, a five-tool allowlist, and the per-user OAuth limit that decides which runs can use it.
related:
  - /docs/tools
  - /docs/trust-model
  - /docs/stations
---

# Add the Context.dev MCP



<CopyPrompt
  className="block"
  text={`Help me customize the eve Software Factory template. I want to add Context.dev so the agent can search the live web and read the pages issues link to.

Ground truth first: read AGENTS.md in the repository root, read agent/connections/linear.ts as the in-repo example of a connection, and read https://eve.dev/integrations/context plus https://docs.context.dev/install-mcp before writing code. Do not hand-write the connection if the registry provides it.

1. Run: eve add connection/context
 This writes agent/connections/context.ts using defineMcpClientConnection with url https://mcp.context.dev/mcp and auth connect("context") from @vercel/connect/eve. Show me the generated file rather than editing it blind.
2. Filter the tools before anything else. The server also exposes a monitors suite (create-monitor, delete-monitor, run-monitor-now, rotate-monitor-webhook-secret, and more) that creates and mutates account state, and every call spends my Context.dev credits. Set tools.allow to exactly these five: web-search, web-scrape-markdown, web-extract, web-screenshot, parse-document. Use allow, not block, so tools the server adds later stay undiscovered too.
3. Tell me the setup commands I need to run myself, and do not run them:
 vercel link, vercel connect create mcp.context.dev --name context, vercel env pull.
4. Important: connect("context") is per-user OAuth, so each person authorizes in their own browser before their first tool call. Unattended factory runs (the factory label and the red-CI fix loop) have nobody to complete that flow. Confirm this in the eve connections docs, then tell me plainly which of Foreman's surfaces can and cannot use Context.dev.
5. Do not mount this connection under agent/subagents/. Stations run in task mode and cannot park for a sign-in. If I ask for it later, explain the failure mode before doing it.
6. Consider whether the connection needs an approval predicate. Read the one in agent/connections/linear.ts, which denies unattended runs via isAutonomous from agent/lib/trust.ts. With the allowlist applied the remaining tools only read, but what they read is the open web, so weigh whether fetched pages steering an attended session is a risk worth a gate here, and explain your reasoning instead of copying by reflex.

Finish by running pnpm validate and confirming 0 errors and 0 warnings, then run npx eve info and show me that the context connection appears with only the five allowed tools. Do not deploy.

Full recipe, with the reasoning behind each step: https://ask-foreman.dev/recipes/add-the-context-mcp`}
/>

Context.dev's hosted Model Context Protocol (MCP) server lets Foreman search the live web, read the pages an issue links to, and check what a deployed site actually serves.

## When to use it

Reach for this when work arrives pointing outside the repository. Bug reports describe what a live page does, issues link to external docs or examples, and the repository alone cannot confirm any of it. Foreman can then read the page in question rather than reasoning from the code and hoping the two match.

The limit decides whether it is worth it for you. `connect("context")` is per-user OAuth, so Context.dev works from mentions, Linear sessions, and the dev TUI, and never from the unattended pipeline. If your factory runs mostly on labeled issues, this buys you less than it looks.

The connection mounts five read tools:

| Tool                  | What Foreman uses it for                                                            |
| --------------------- | ----------------------------------------------------------------------------------- |
| `web-search`          | Search the live web when an issue references something the repository cannot answer |
| `web-scrape-markdown` | Read the page an issue links to, as markdown                                        |
| `web-extract`         | Pull structured data out of a page instead of quoting it whole                      |
| `web-screenshot`      | Capture what a live page renders, for reports about visual breakage                 |
| `parse-document`      | Read a linked PDF or document                                                       |

## What it touches

| File                           | Change                                                                                       |
| ------------------------------ | -------------------------------------------------------------------------------------------- |
| `agent/connections/context.ts` | Created by `eve add connection/context`, then filtered to five tools                         |
| Vercel Connect                 | The `context` connector, created with `vercel connect create mcp.context.dev --name context` |
| `package.json`                 | The auth dependency, if not already installed                                                |

## Before you run it

Authorization is per person, not per deployment. Every teammate who wants Foreman to use Context.dev authorizes once in their own browser, and nobody can do it on another person's behalf.

There is a running cost too. Vercel Connect bills per token request, every call spends your Context.dev credits the same way the equivalent API operation would, and each connection widens the tool surface the model searches through on the turns that use it.

Everything these tools return is text from the open web, and a page can carry instructions aimed at the model. The allowlist keeps this connection read-only, so a hostile page cannot reach a write tool through it, but treat scraped content the way the [trust model](/docs/trust-model) treats issue bodies: as input, not instruction.

## What the connection looks like

```ts title="agent/connections/context.ts"
import { connect } from "@vercel/connect/eve";
import { defineMcpClientConnection } from "eve/connections";

export default defineMcpClientConnection({
  url: "https://mcp.context.dev/mcp",
  description: "Context.dev: search, scrape, and extract live web pages.",
  auth: connect("context"),
  tools: {
    allow: [
      "web-search",
      "web-scrape-markdown",
      "web-extract",
      "web-screenshot",
      "parse-document",
    ],
  },
});
```

Context.dev is not a first-class connector type, so the connector is created from the server's domain and named through the `--name` flag:

```bash
vercel link
vercel connect create mcp.context.dev --name context
vercel env pull
```

<Callout type="warn" title="This is per-user OAuth, so unattended runs cannot use it">
  `connect("context")` authorizes each end user in their own browser before their first tool call. Neither the factory-label run nor the red-CI fix run has anybody at a browser, so neither can complete that flow. Context.dev is usable from mentions, Linear sessions, and the dev TUI, but not from the unattended pipeline.
</Callout>

That constraint differs from the Linear connection already in the template, which uses app-scoped auth through `linearAuth` and therefore works without a person present.

## What stays out

Context.dev's MCP serves far more than the five tools above. The monitors suite (`create-monitor`, `delete-monitor`, `run-monitor-now`, `rotate-monitor-webhook-secret`, and more) creates persistent state in your account, and the brand-intelligence and industry-classification tools have no role in a software factory.

The connection lists what it wants through `tools: { allow: [...] }`, so none of that is discovered and the model cannot call it. Listing the allowed tools rather than blocking the unwanted ones also covers whatever the server adds later.

## Verify

```bash
pnpm validate
npx eve info
```

`npx eve info` should list the `context` connection with only the five allowed tools. If any monitor tool shows up, the filter is not applied.

Then run `pnpm dev` and ask something that needs a live page. The first tool call triggers the OAuth sign-in in your own browser.

## What to expect

Web reads earn their place when the work points outside the repository. On a refactor or a repository-internal bug, Foreman leaves these tools alone and no credits are spent.

## FAQ

<Accordions type="single">
  <Accordion title="Can the unattended pipeline use Context.dev?">
    No. `connect("context")` is per-user OAuth, and each person authorizes in their own browser before their first tool call. Neither the factory-label run nor the red-CI fix run has a person present, so neither can complete that flow.

    Mentions, Linear Agent Sessions, and the dev TUI are all attended, so Context.dev works there. If an unattended run needs something from the live web, the practical route today is to have an attended session record the durable finding in the [factory brain](/docs/memory), which every run reads.
  </Accordion>

  <Accordion title="Can I give it to the Analyst or another station?">
    No, and mounting it at the root would not do that anyway. Stations inherit nothing from the orchestrator, including connections, so giving one a Context.dev connection means putting a connection file in that station's own directory.

    That mount fails in practice. Stations run in task mode, which cannot pause for a person or an OAuth sign-in, so the first unauthorized call fails rather than waiting. The orchestrator can read the page itself and weave what it found into the delegation message instead.
  </Accordion>

  <Accordion title="Why keep the monitor tools out?">
    Monitors are persistent account state. Once created, one runs on its own schedule, spends your credits while nobody is watching, and delivers results by webhook to wherever it was pointed. `rotate-monitor-webhook-secret` can also silently break an integration you already rely on.

    If you want the factory to watch pages for changes, that is its own recipe, gated behind approval the way merging is. It should not arrive as a side effect of adding search.
  </Accordion>

  <Accordion title="Can I allow more of the scraping tools?">
    Yes. The server also exposes `web-scrape-html`, `web-scrape-images`, `web-scrape-sitemap`, and `web-crawl`, and adding one to the allowlist is the whole change.

    Weigh `web-crawl` before adding it. One crawl call fans out into many fetches, so it multiplies credit spend in a way the single-page tools do not.
  </Accordion>

  <Accordion title="What does adding a connection cost?">
    Three things. Vercel Connect bills per token request, each tool call spends your Context.dev credits the same way the equivalent API operation would, and every connection widens the tool surface the model has to search through with `connection_search`, which costs context on each turn that uses it.
  </Accordion>
</Accordions>


---

For a semantic overview of all documentation, see [/sitemap.md](/sitemap.md)

For an index of all available documentation, see [/llms.txt](/llms.txt)

For agent-facing discovery, including API and MCP surfaces, see [/agents.md](/agents.md)