Skip to main content
Glama

Get the site's editor link

get_editor_link

Return a link to the site owner's own visual editor, optionally opening straight to one page or collection item. Give this to the person whenever the next step is theirs rather than yours:

  • They want to use THEIR OWN image. Pass image_target naming the spot and they get a one-time photo link instead of the editor: one page, one drop, placed on that spot in the draft, no sign-in. Without a spot they get the editor. This is the dividing line for every image on the site, sections and collection items alike: you source pictures with find_images, replace_images_from_search and upload_image (with url) and place them yourself, but a file that exists only on their device — their logo, their team photo, their product shots — comes in through the editor. Point them at the exact page or item (page_slug takes 'blog/my-post' as happily as 'about') rather than the site root.

  • They want to make a change themselves, or asked where to edit something.

  • They asked to see their site, or seem unaware there is a visual builder at all — many people who connect this connector never find out.

The link opens their editor signed in as them. Do not promise they are already signed in: the session cookie may not exist on the device they open it from, in which case they are sent to sign in first and land in the editor afterwards. share_with_user is worded for that.

The editor link is nothing secret — an ordinary product URL, authenticated by the person's own account. A photo link is a one-time capability for that one spot (30 minutes, one upload, draft only): give it to the person and to no one else.

Input Schema

NameRequiredDescriptionDefault
altNoWith image_target: alt text for the photo, if they told you what it shows. Omit to keep the spot's current alt text.
taskNoWhat the person is going there to do, so the instructions match the actual UI. 'image' — they are supplying their own photo; the steps differ between a standalone image and a background and neither is guessable. 'edit' — any other change they make themselves. Omit only if you genuinely don't know.
site_idYesThe site UUID whose editor link should be returned.
page_slugNoOptional path to open directly. A page slug ('about'), or a collection item's full path ('blog/my-first-post', 'projects/harbour-house') — nested paths are fine. Omit for the home page. Send them to the exact thing they need to change; 'it's in the editor somewhere' is how people give up.
image_targetNoThe ONE spot their own photo goes: { node_id } for an image or a section's background photo, or { content_type, item_slug, field } for a collection item's photo. With this, the person gets a one-time link to a page that does only that: they drop the file and it is placed on that spot in the draft. No sign-in, no editor, nothing to save. Use it whenever they have their own photo for a spot you can name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description goes well beyond the annotations by explaining that the editor link opens signed in as the user but may still route to sign-in depending on session cookies. It also discloses the photo link's security model: one-time capability, 30 minutes, one upload, draft only, and not to be shared beyond the intended person.

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

Conciseness4/5

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

The description is front-loaded and uses bullet structure effectively for the main usage cases. It is somewhat long and occasionally conversational, but most content earns its place by clarifying routing, auth behavior, and link sensitivity.

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

Completeness5/5

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

For a link-returning tool with no output schema, the description explains both possible link modes and their important constraints. It also covers the prerequisites and caveats an agent needs before handing the link to a person.

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 carries most parameter meaning. The description still adds useful selection semantics by explaining that image_target should be passed only when the person is supplying their own photo for a named spot, and that omitting it returns the editor instead.

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?

The description states a specific verb and resource: returning a link to the site owner's visual editor, optionally opened to a page or collection item. It clearly distinguishes this from image-sourcing and placement tools like find_images, replace_images_from_search, and upload_image.

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

Usage Guidelines5/5

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

It gives explicit when-to-use cases: when the next step belongs to the person, when they want to make edits themselves, or when they ask to see their site. It also draws the key routing line between editor links for user-owned files and direct image placement tools for sourcing/placement.

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.

Resources