Skip to main content
Glama

Link a page of the site to a new article

apply_inbound_link

Add the ready sentence that links one existing page of the brand's site to a newly published article (the links of a get_action_plan item whose id starts with links:), on the connected WordPress only. links.pages[].link_on says how: « existing_words » = the link is put on words already in the page's paragraph (anchor), no text added; « new_sentence » = one paragraph is inserted right after the chosen paragraph. Nothing else on the page changes. Reported as applied only once the live page shows the link. mode revert removes what Howseen added (the link only, the words stay; or the added sentence); mode verify re-reads the live page. Pages on other sites or editors are refused with the sentence to paste by hand. Preview first; confirm: true writes on the live site.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "article_id": "<article_id>",
      "page_url": "<page_url>"
    },
    "name": "apply_inbound_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoapply (default), revert (remove what Howseen added: the link on existing words, or the added sentence) or verify (re-read the live page).
brandNoBrand id, name or domain (from list_brands). Optional when the account has a single brand.
confirmNoLeave out (or false) to get a preview: nothing changes. Set true ONLY after the user approved that exact preview.
page_urlYeslinks.pages[].page_url: the page to add the link on.
article_idYeslinks.article_id of the get_action_plan item.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / mode / description
      Previous value: -"apply (default), revert (remove the added sentence) or verify (re-read the live page)."New value: +"apply (default), revert (remove what Howseen added: the link on existing words, or the added sentence) or verify (re-read the live page)."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it explains exactly what is mutated on the live page (an anchor on existing words, or one inserted paragraph), that nothing else on the page changes, and that success is reported only once the live page shows the link. It also discloses revert semantics (link removed, words kept; added sentence removed), a re-read verify mode, and the manual-paste fallback for unsupported editors — consistent with destructiveHint=false since every change is removable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense and mostly earns its place, but it is delivered as one unbroken run-on block with stacked parentheticals, a guillemet-quoted enum inline, and three modes described mid-paragraph. Key operational facts (preview/confirm gate, revert, verify) are not front-loaded or separated, making it slow to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a live-site mutation with three modes and no output schema, the description covers scope, side effects, reversibility, verification and unsupported cases well. It omits what the preview actually returns, how refusals are surfaced in the response, and any permission/connection prerequisites for the WordPress site.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines mode, confirm, page_url and article_id; the description largely restates the mode meanings and the preview gate. It does add cross-reference context by tying page_url to links.pages[].page_url and explaining that links.pages[].link_on determines whether an anchor or a new sentence is produced, which the schema itself does not define.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: add a link from an existing site page to a newly published article, sourced from a get_action_plan item whose id starts with links:. It also draws a hard scope boundary ('on the connected WordPress only') and names what it will not touch ('Pages on other sites or editors are refused'), which no sibling tool overlaps with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear operating workflow ('Preview first; confirm: true writes on the live site') and explains which mode to reach for (apply / revert / verify), plus a refusal case for unsupported sites. It never explicitly routes the agent away from alternatives (e.g. publish_article, request_indexing, mark_action_done) or says when this action should be skipped.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.