Skip to main content
Glama
swebsy

swebsy-mcp

Official
by swebsy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

swebsy_read_page

Read the current page structure to get addressable component target paths, then use them to edit or copy sections. Verify results after changes.

Instructions

Read the current page structure and addressable component target paths. 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. 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

TableJSON Schema
NameRequiredDescriptionDefault
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. '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. First observedv0.8.0

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It does this well by describing output size bounds ('~1-2 KB'), the character-capped outline mode, the complete cleaned JSON for full mode, and scoping behavior. It does not explicitly state 'read-only' or 'non-destructive,' but the verb 'Read' and the verify-after-edits context strongly imply it.

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 front-loaded with the core purpose, then gives workflow guidance, then a verification note. Every sentence earns its place; there is no filler or repetition of schema fields.

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 tool with two optional parameters, no output schema, and no annotations, the description is remarkably complete. It explains all three detail modes, the targetPath scoping mechanism, and the correct calling contexts before and after edits. Nothing essential is missing for an agent to invoke it correctly.

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 baseline is 3. The description adds extra value by explaining when to prefer `detail: full` and why `targetPath` is 'strongly recommended' with it, plus describing the output character of each mode. This enriches the schema rather than merely repeating it.

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: 'Read the current page structure and addressable component target paths.' It immediately clarifies what the tool returns and how it fits into an editing workflow, distinguishing it from the write/edit siblings without needing to name them.

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?

Usage is explicitly guided: call BEFORE editing a non-current named/relative component, use `detail: full` WITH `targetPath` when copying content, and call again AFTER edits to verify. This is concrete, actionable guidance that leaves little to inference.

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