Skip to main content
Glama
Sign In
swebsy

swebsy-mcp

Official
by swebsy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read page

swebsy_read_page
Read-onlyIdempotent

Inspect the current page structure to get each component's target path and id before editing. Call it to locate sections or drill into nested elements, then re-read to verify edits.

Instructions

Read the current page structure: each line shows a component's target path and its #id. edit_section, delete_section, move_section, duplicate_section and link_page take either — prefer the id (targetId), which survives moves and inserts; other tools take the path. Use the id only to target; don't copy auto ids into markup. Call this BEFORE editing a named or relative page component that is not the current selection. The default sections read lists every top-level section with its target path — enough to pick the one to edit. To find a nested element (a link, button, card) pass that section's targetPath plus depth — one call instead of drilling down level by level. When copying content between components, use detail: full WITH the targetPath of the one section you're copying, not a whole-page read. Also call it AFTER applying edits to verify the result.

Input Schema

NameRequiredDescriptionDefault
depthNoOptional. How many levels of the indexed tree to print below the section layer (default 1 = each section only, deeper nodes summarised as '(N descendants)'). Every printed line keeps its target path. Pair with `targetPath` to see a whole section in one call — e.g. `targetPath: [7], depth: 6` lists every link in the footer with its path for link_page/edit_section. Above 1 the read is capped at ~24 KB and ends with a '…(truncated: … next is [path])' marker if it doesn't fit; values above 12 are clamped.
detailNo'sections' (default): every section at the read root with its target path, an ~80-char text preview, and its descendant count — bounded and complete (~1-2 KB). 'outline': a deeper type/tag/class tree, character-capped (~2 KB; prefer `sections` + `depth`). 'full': the complete cleaned JSON tree, for copying content between components (scope it with targetPath).
targetPathNoOptional. Zero-based component indexes from the page root (as returned by a prior read_page) that scope the read to that ONE subtree instead of the whole page. Strongly recommended with `detail: full` — reading one section's JSON instead of the entire page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.13.1
    • addedInput schema / properties / depth
      Added value: +{
+  "description": "Optional. How many levels of the indexed tree to print below the section layer (default 1 = each section only, deeper nodes summarised as '(N descendants)'). Every printed line keeps its target path. Pair with `targetPath` to see a whole section in one call — e.g. `targetPath: [7], depth: 6` lists every link in the footer with its path for link_page/edit_section. Above 1 the read is capped at ~24 KB and ends with a '…(truncated: … next is [path])' marker if it doesn't fit; values above 12 are clamped.",
+  "maximum": 12,
+  "minimum": 1,
+  "type": "integer"
+}
    • changedInput schema / properties / detail / description
      Previous value: -"'sections' (default): every section at the read root with its target path, an ~80-char text preview, and its descendant count — bounded and complete (~1-2 KB). 'outline': a deeper type/tag/class tree, character-capped. 'full': the complete cleaned JSON tree, for copying content between components (scope it with targetPath)."New value: +"'sections' (default): every section at the read root with its target path, an ~80-char text preview, and its descendant count — bounded and complete (~1-2 KB). 'outline': a deeper type/tag/class tree, character-capped (~2 KB; prefer `sections` + `depth`). 'full': the complete cleaned JSON tree, for copying content between components (scope it with targetPath)."
  2. First observedv0.8.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover read-only/idempotent, but the description adds substantial behavioral facts: ids survive moves and inserts while paths do not, auto ids must not be copied into markup, reads above depth 1 are capped at ~24 KB and end in a truncation marker, and values above 12 are clamped. These are non-obvious contract details an agent cannot infer from schema or annotations.

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?

Front-loaded with the core purpose and the id-vs-path rule, then ordered by reading workflow (before, drill-down, copy, after). It is long for a single block, but every sentence carries distinct guidance rather than filler; only the 'prefer the id' statement is restated slightly.

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?

No output schema exists, and the description compensates by describing what a line looks like, per-mode size/shape of output (`sections` ~1-2 KB bounded, `outline` ~2 KB, `full` = complete JSON tree), and truncation markers. Nothing an agent needs to call this correctly is missing.

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 coverage is 100%, so baseline is 3; the description earns extra by giving parameter-level strategy the schema doesn't: pair `depth` with `targetPath` for one-call whole-section reads, prefer `sections` + `depth` over `outline`, and strongly recommend `targetPath` when using `detail: full`.

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?

Opens with a specific verb+resource ('Read the current page structure') and immediately pins down the exact return format ('each line shows a component's target path and its `#id`'). It explicitly differentiates itself from the nearest sibling by naming read_selection's domain ('the current selection').

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?

Gives explicit when-to-call rules ('BEFORE editing a named or relative page component that is not the current selection', 'AFTER applying edits to verify the result') and names alternatives by task: paragraph on 'To find a nested element... pass targetPath plus depth', and 'When copying content... use detail: full WITH targetPath'. Sibling tools edit_section/delete_section/link_page are named for the id-vs-path choice.

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