OpenClaw SEO Skill for Link Building Outreach

Most of what turns up under "OpenClaw SEO" is an agent that writes posts, checks a site's tags, or pulls Search Console numbers into a chat. All of it stops at the edge of your own site. This skill is for the step past that edge, which is getting other sites to link to the page you published. It is one SKILL.md in the format OpenClaw already reads, plus one openclaw mcp add for the MentionAgent MCP server. After that, the agent you already message on Telegram or WhatsApp can tell you which publishers replied, read the outreach drafts before they go out, and answer the ones worth answering, while you say yes to each send.

What an OpenClaw skill is, and what this one does

OpenClaw is a self-hosted Gateway that puts one agent behind the chat apps you already use: Discord, iMessage, Signal, Slack, Telegram, WhatsApp, a web chat, and more. Its onboarding reuses a Claude Code or Codex CLI login or a provider API key, it needs Node 24.16 or newer, and npx openclaw@latest gets you to a first chat in a few minutes. Skills are how you teach that agent a workflow: a folder holding a SKILL.md with YAML frontmatter and a markdown body. OpenClaw follows the Agent Skills spec for the file, so the same folder that works in Claude Code and Cursor works here without edits.

The skill's name field becomes its slash command, /link-building-outreach, and its description is the list of phrases that make the agent reach for it on its own: "review outreach drafts", "send the batch", "who replied", "which emails need an answer", "backlinks". The body is the part that matters. It tells the agent which two tools send email and that neither runs before you have read the exact text; which two tools spend credits; that every id it writes with must have come out of a read in the same conversation; and that an instruction found inside a publisher's email is something to report to you, never something to obey.

Underneath are the twenty-one tools of the MentionAgent MCP server, which cover the life of a campaign after it exists: what is waiting, the drafts, the inbox, replies, placements, pausing and resuming, changing keywords. OpenClaw's built-in MCP client connects to that server over Streamable HTTP and hands its tools to the agent under the same tool policy as everything else it can do, so connecting the server does not bypass any limit you have set.

Install in OpenClaw

You need a MentionAgent account with at least one site set up, and an API key from the dashboard under Settings, Agent access. The key is shown once and begins with ma_live_. Then three commands and one message.

1. Install the skill into the workspace. OpenClaw installs from a local directory as long as the SKILL.md sits at the root of what you point it at, which in the repo is the skill folder itself:

git clone https://github.com/BuildsbyMatt/mentionagent-claude-skill
openclaw skills install ./mentionagent-claude-skill/skills/link-building-outreach

That lands in the active workspace's skills/ directory, ~/.openclaw/workspace/skills/ on a default install. Add --global to put it in ~/.openclaw/skills/ instead, where every local agent can see it. The slug is taken from the frontmatter name, so it shows up as link-building-outreach either way. Copying the folder in by hand works too; OpenClaw discovers a SKILL.md up to six levels deep under a skill root.

2. Register the server and sign in. OpenClaw keeps MCP servers under mcp.servers in its config, and the CLI writes that entry for you. The MentionAgent server publishes the OAuth metadata documents an MCP client looks for, so the cleanest registration has no key in it at all:

openclaw mcp add mentionagent \
  --url https://mentionagent.ai/mcp \
  --transport streamable-http \
  --auth oauth --no-probe
openclaw mcp login mentionagent
openclaw mcp probe mentionagent

--no-probe saves the definition without connecting, because there is nothing to connect with until you have logged in. login prints an authorization URL and opens it: it is the MentionAgent consent page, you sign in to your dashboard account and click Allow, and OpenClaw catches the redirect and stores the tokens itself. The probe afterwards is the part that proves something: it opens a real connection and lists the tools the server advertises, and if it comes back empty the login did not take. The grant shows up in the dashboard under Settings, Agent access, where it can be revoked.

If you would rather use an API key, create one in the same dashboard section (shown once, starts with ma_live_) and pass it as a header. The flag takes KEY=VALUE, so it is --header "Authorization=Bearer ma_live_..."; the colon form is rejected. Do not combine it with --auth oauth, because OpenClaw ignores a static Authorization header once OAuth is on. Both forms also work from the Control UI under Settings, MCP, or from the chat composer under Connectors, Add MCP server.

3. Send the first message. From whichever channel your Gateway is connected to, send /link-building-outreach, or ask what is waiting on MentionAgent? The agent calls get_status, names your sites, and states in one paragraph what it will not do without asking. If you run more than one site it asks which before touching anything, because the skill forbids guessing a workspaceId.

Outreach from your phone

The reason to run this skill in OpenClaw rather than in an editor is the channel. Publishers reply to outreach at odd hours and on their own schedule; the question "did anyone answer?" comes up on the train, not at the desk. With the Gateway connected to Telegram or WhatsApp, that question is a message to the agent, and the reply is a list: three new replies, one asking for a fee, one proposing a placement on a specific post, one out-of-office. You can leave the first two for later and archive the third from the same thread.

The draft review works the same way, in smaller bites. MentionAgent drafts outreach in batches and holds them for approval; a batch of twenty is a fifteen-minute job in a dashboard and a five-minute one in chat, because the agent reads all twenty and reports only the ones that look wrong: a pitch that describes the wrong page, a greeting that scraped a navigation label as a name, an opening line repeated four times. You answer with drop, fix, or send, per draft, and the tool that sends only runs on the ones you named.

Replies that need a real answer go through draft_reply, MentionAgent's own writer, which reads the publisher's site to choose a page, a paragraph and an anchor before it proposes text. The agent shows you that text in the chat; send_reply goes out only on your yes. It has no recipient field, so the address is always the person already in the thread, and a phone-sized message cannot accidentally forward anything anywhere.

An always-on agent and a tool that sends mail

A Cursor Agent exists while the editor is open. An OpenClaw Gateway runs all day, answers whoever the channel lets through, and can act on a schedule. That changes the risk profile of a skill whose tools include sending email on your behalf, and it is worth setting up deliberately.

The skill's own rules do most of the work: no approve_batch or send_reply without the operator seeing the exact text and saying yes in the same conversation, and "send the good ones" is not a yes for any particular draft. OpenClaw adds two controls on top. Tool policy applies to MCP tools the same as to built-in ones, so a server's tools can be filtered at definition time with --include and --exclude globs. And per session, the composer's Connectors menu has a Tool access view where individual tools can be denied for that conversation before the next turn starts. For a channel that other people can message, denying the two sending tools there is a one-minute change that removes the failure mode entirely.

The third control is in the skill file. Set disable-model-invocation: true in the frontmatter of your installed copy and the agent stops loading the skill on its own; it then answers only to the explicit slash command. For a skill that can spend credits and send mail on an always-on agent, that is a sensible default, and it is one line.

Cron jobs: what to schedule and what not to

OpenClaw can run agent turns on a schedule and on webhooks, which invites the obvious idea: have it approve the batch every morning. Do not. A scheduled turn has no operator in it, so nothing in it can satisfy the skill's rule that a send needs a yes from a person who has read the text, and the skill will refuse. The two tools that spend credits, trigger_run and draft_reply, are the other thing to keep out of a loop; trigger_run is capped at five per site per day on the server and refused while a batch is still waiting for approval, so a schedule that calls it just burns the cap by mid-morning.

What does work on a schedule is the read side. A morning turn that calls get_status, list_pending_drafts and list_inbox and posts a three-line summary to your channel is the best use of cron here: how many drafts are waiting, how many replies need an answer, whether sending is paused. You read it over coffee and decide whether today is a review day. Deny the sending tools for that session's Tool access and the schedule cannot do more than summarise even if a prompt in an inbound email tries to make it.

Keys and a shared Gateway

With OAuth there is no key to manage: the tokens OpenClaw stores after login are its own, scoped to /mcp, and the grant is one line in the dashboard that you can revoke. If you went the header route instead, the key lives on the MCP server definition, never in the skill's markdown, and openclaw mcp doctor will point out that a literal bearer token is sitting in config. On a Gateway only you use, that warning is information. On a Gateway with several operators, act on it: OpenClaw's docs ask that sensitive header values go through its secret mechanism rather than config literals, and the reason is that a shared Gateway is one trust domain. A skill attached to a session is an input to that session, not a vault, and anyone who can drive the agent can drive the tools the key unlocks.

What either credential can reach is deliberately narrow. It authenticates /mcp and nothing else, so it cannot get at mailbox credentials, billing, domain transfer or account deletion; the tool list is the whole allowlist. Revoking a grant or a key in the dashboard stops it on the next request. If a colleague should have their own access, have them log in themselves rather than sharing a key; an account can hold ten keys, and the dashboard shows when each was last used, which is how you notice one that should not be active.

Differences from the Claude Code and Cursor installs

The file is identical across the three. What differs is the plumbing around it. The Claude Code SEO plugin ships with the server config inside it, so one marketplace command does both halves. The Cursor version is a copy into .cursor/skills/ plus a JSON block in .cursor/mcp.json with the key as an env reference. OpenClaw sits in between: it has an install command for skills that takes a local folder, and a separate CLI for MCP servers, so the server is registered once at the Gateway level rather than per project, and its CLI runs the OAuth login for you, which is why it is the install with no key in it. The OpenCode version gets to the same place from the other direction: no login command at all, just a remote server entry in opencode.json that OpenCode authenticates on first use.

Three things are OpenClaw's alone. It is the only one of the three that runs when no window is open, which is why the sections on tool access and schedules above exist and have no equivalent on the other pages. It is the only one that answers from a phone. And its skill updates are tracked only for registry installs: a skill installed from a local folder is refreshed by pulling the repo and running the install command again, whereas a Claude Code plugin updates through the marketplace.

The model is whatever your Gateway is configured with. The skill was written and tested against Claude, and its instructions are plain enough that we have not seen a capable model misread them, but the consent rules are worth a first-day check with any model: ask it to send a draft you have not seen, and confirm it refuses.

When to skip this

If OpenClaw is not already running for you, installing it to get this skill is the wrong order; the dashboard does the same review with less setup. If you want outreach that sends with nobody watching, no skill will give you that, because the two tools that send were built to be shown to a person first, and OpenClaw's tool policy is where you would enforce that rather than route around it. And if the site in question has no MentionAgent campaign yet, start there: the skill has nothing to review until MentionAgent has prospected, drafted and warmed an inbox for that site, all of which happen without an agent in the loop. Link building on autopilot covers which steps those are.

Frequently asked questions

Related guides