# Reading an SEO workspace from an agent

> netweft exposes an MCP server and an OpenAPI document, so an agent can read audits, keywords, rankings and project context, and reading stored data is free.

Source: https://netweft.com/blog/reading-a-workspace-from-an-agent
Updated: 2026-03-03

**netweft exposes MCP at POST /mcp under an API key, alongside an OpenAPI 3.1 document for the whole HTTP API. An agent reads a workspace's stored audits, keywords, rankings and project overview, and reading costs no credits because the credits were spent when the observation was made.**

Most SEO tools are built for a person with a browser. The data underneath them
is perfectly readable by something else, and the something else is increasingly
the thing asking.

## Two surfaces, one product

netweft publishes both.

The HTTP API is described by an OpenAPI 3.1 document at `/openapi.json`.
Everything the dashboard does goes through it, so a generated client is a real
client rather than a partial one.

The MCP server sits at `POST /mcp`, authenticated by API key. It exposes a
workspace's audits, keywords, rankings and project overview as tools an agent
can call directly, without you writing the glue.

Neither is a side project bolted on after launch. The API is what the dashboard
talks to; MCP is the same data under a protocol an agent already speaks.

## Reading is free, because looking was not

The credit model makes this cleaner than it usually is.

When netweft [checks a keyword's position](/features/rank-tracking), it pays a
vendor for a [SERP](/glossary/serp) fetch and charges the workspace for it. That is the moment money changes hands. The
observation is then stored.

Reading that stored observation later — from the dashboard, from the API, or
from an agent — costs nothing. There is no second invoice, so there is no
reason to meter the read. An agent can pull a project's entire ranking history
every hour and the balance does not move — which works only because that
history is [stored rather than
recomputed](/blog/snapshots-not-recomputation).

The corollary matters too: an agent *cannot* run up a bill by reading. The
operations that spend credits are the ones that go to a vendor, and they are
the same operations, at the same prices, whichever surface asks for them.

## What the assistant is allowed to say

netweft also ships its own AI: a per-project chat and an onboarding strategist.
Both are restricted to figures read back through tools.

That constraint is not a disclaimer, it is an implementation. The model cannot
answer "what is my average position for this cluster" from its own weights,
because the number is not in its weights — it has to call a tool, and the tool
returns what is stored. If the tool has nothing, the answer says so.

An SEO assistant that invents a plausible number is worse than no assistant,
because a plausible number is exactly the kind of thing nobody checks.

## A practical shape

The pattern that works, in our experience of building it:

- Give the agent an API key scoped to one workspace.
- Let it read rankings, audits and the project brief. These are cheap, stored,
  and safe to poll.
- Keep the operations that spend money — a fresh SERP fetch, a new
  [crawl](/features/site-audit), a [backlink pull](/features/backlinks) —
  behind an explicit decision, whether that decision is a human
  pressing something or an agent with a budget you set.

The [credit ledger](/pricing) is what makes the second half tractable. Every spend has a
line, a reservation and a settlement, so an agent's behaviour is auditable in
the same units as everything else.