Skip to main content
Glama
This connector has been deprecated

Duplicate listing of the same server under an old namespace. The maintained listing is Layero (ru.layero/layero): same endpoint https://mcp.layero.ru/mcp, current description and tools. The landing-page generator described here was removed in MCP 2.0.

Применить правку к разметке сайта

refactor_site
Read-onlyIdempotent

One named markup transformation — with a predictable result.

The tool PUBLISHES NOTHING. It returns the changed HTML; showing it to
the person, getting consent and calling `publish_site` is your job.
Never rewrite someone's site silently.

Transformations are idempotent: a repeated call changes nothing and
honestly answers `changed=false`. An empty list of changes is not an
error, it means "there was nothing to apply".

⚠️ WHAT IS NOT HERE AND WHY. Fonts from third-party hosts, re-encoding
images to webp and untangling inline styles are NOT included: they need
the files themselves, which the server does not have, or a judgement
about the intended look. `site_issues` names those problems — with a
location and an explanation; whoever holds the files fixes them.

The gain is measured with `check_performance` BEFORE and AFTER the
publish. A difference under three points is measurement noise, not an
improvement — say so.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fixYes`meta` — fill in lang and Open Graph markup from what the page already says. `lazy_images` — defer loading of images below the first screen (the first image is left alone: LCP is measured on it).
htmlYesThe contents of `index.html` — the file on the user's disk. Read the file yourself and pass it here.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fixYes
htmlNo
changedYes
changesYes
next_actionYes
available_fixesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / fix / description
      Previous value: -"`meta` — заполнить lang и OG-разметку из того, что на странице уже написано. `lazy_images` — отложить загрузку картинок ниже первого экрана (первую не трогает: по ней меряется LCP)."New value: +"`meta` — fill in lang and Open Graph markup from what the page already says. `lazy_images` — defer loading of images below the first screen (the first image is left alone: LCP is measured on it)."
    • changedInput schema / properties / html / description
      Previous value: -"Содержимое `index.html` — то, что лежит у пользователя на диске. Прочитай файл сам и передай сюда."New value: +"The contents of `index.html` — the file on the user's disk. Read the file yourself and pass it here."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Even with readOnlyHint and idempotentHint already present, the description adds substantial behavioral context: it publishes nothing, returns changed HTML, answers changed=false on repeated calls, treats an empty change list as a non-error, and insists on not silently rewriting someone's site. This goes well beyond the annotations.

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

Conciseness5/5

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

The description is well structured and front-loaded: core behavior first, then safety, exclusions, and measurement guidance. Every sentence earns its place, and the bolded 'WHAT IS NOT HERE' section makes the boundaries easy to scan.

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?

Given the schema, annotations, output schema, and sibling context, the description is complete. It covers what the tool returns, what the agent must do before publishing, idempotency semantics, excluded transformation types, and how to evaluate results with check_performance.

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

Parameters3/5

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

Schema coverage is 100%, so the input schema already documents both html and fix, including the enum meanings. The description adds no new parameter-specific semantics beyond referring to a 'named markup transformation,' so the baseline of 3 is appropriate.

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 opens with a specific verb and resource: 'One named markup transformation — with a predictable result.' It immediately clarifies the tool's narrow scope and explicitly contrasts itself with publishing and file-dependent transformations, so an agent can tell it apart from publish_site and site_issues without confusion.

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?

The description gives explicit workflow guidance: the tool returns changed HTML and the agent must show it, get consent, and call publish_site. It also names site_issues for problems the tool does not handle and check_performance for measuring gain, making when-to-use and when-not-to-use unambiguous.

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