Skip to main content
Glama
Sign In
swebsy

swebsy-mcp

Official
by swebsy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Move section

swebsy_move_section

Reorder page components by moving a section, column, or CTA before or after another element while keeping its id, classes, and styles intact—avoid delete-and-re-add that loses styling.

Instructions

Move a component to just before or after another component on the current page — reorder sections, swap columns, lift a CTA above the footer. The component keeps its id, classes and id-styles. ALWAYS use this to reorder; delete + re-add loses the component's styles. Name each side by id (targetId/anchorId) or by path (targetPath/anchorPath).

Input Schema

NameRequiredDescriptionDefault
anchorIdNoThe component to place it next to by its id, as `read_page` shows it after `#` (e.g. "ieyubib", or "call-2-2" in a symbol instance). Stays valid when other components move or are added, unlike a path. Pass this OR the path, not both.
positionNoWhich side of the anchor. Default after.
targetIdNoThe component to move by its id, as `read_page` shows it after `#` (e.g. "ieyubib", or "call-2-2" in a symbol instance). Stays valid when other components move or are added, unlike a path. Pass this OR the path, not both.
anchorPathNoPath (from the same `read_page`) of the component to place it next to.
targetPathNoPath (from the most recent `read_page`) of the component to move.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.13.1
    • addedInput schema / properties / anchorId
      Added value: +{
+  "description": "The component to place it next to by its id, as `read_page` shows it after `#` (e.g. \"ieyubib\", or \"call-2-2\" in a symbol instance). Stays valid when other components move or are added, unlike a path. Pass this OR the path, not both.",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / targetId
      Added value: +{
+  "description": "The component to move by its id, as `read_page` shows it after `#` (e.g. \"ieyubib\", or \"call-2-2\" in a symbol instance). Stays valid when other components move or are added, unlike a path. Pass this OR the path, not both.",
+  "minLength": 1,
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "targetPath",
-  "anchorPath"
-]
  2. Addedv0.10.0

TDQS

A4.5/5.0
Behavior4/5

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

Adds real behavioral context beyond annotations: the component keeps its id, classes and id-styles, and the warning that delete+re-add loses styles. Annotations cover non-destructive/non-read-only, but the description usefully explains the state-preservation guarantee. Missing details like whether ordering impacts symbol instances or permission requirements.

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?

Three tight sentences + a heuristic. Front-loaded with what it does, then the critical ALWAYS rule, then the id-vs-path decision. No filler.

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 5-param mutation tool with full schema coverage and no output schema, the description covers the essential semantics and behavior. It doesn't mention the return value or whether `position` default 'after' interacts with missing target/anchor — minor given schema covers defaults.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description adds the either/or rule: name each side by id OR by path, and explains the tradeoff (ids stay valid when other components move, unlike paths). This gives the agent a clear decision heuristic that the schema alone doesn't synthesize.

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 (move/reorder) and resource (component/section), gives concrete use cases (reorder sections, swap columns, lift a CTA above footer), and clearly distinguishes from delete+re-add as well as from siblings like duplicate_section or edit_section.

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?

Explicit 'ALWAYS use this to reorder; delete + re-add loses the component's styles' tells the agent when to use it and which anti-pattern to avoid. However, it doesn't clarify when to prefer move_section over duplicate_section or how it relates to wrap_section.

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

Deploy Server

Other Tools