PageMap

Official

by Retio-ai

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.1
Disambiguation5/5
Each tool has a distinctly different purpose: page state vs full map, screenshot, navigation (back, scroll), form filling vs single action, waiting, tab lifecycle, and batch map retrieval. There is no meaningful overlap that would cause an agent to select the wrong tool for a given operation.
Naming Consistency4/5
Tool names consistently use snake_case with action-first verbs (get_, take_, navigate_, scroll_, fill_, wait_, execute_, open_, switch_, list_, close_, batch_get_). The pattern is mostly verb_noun, with minor deviations like 'navigate_back' and 'wait_for' that are still predictable and readable.
Tool Count5/5
13 tools is well within the ideal 3-15 range for a web automation server. Each tool is justified and non-redundant, covering page inspection, interaction, navigation, waiting, screenshot, tab management, and batch processing without excessive granularity.
Completeness4/5
The tool surface covers the core browsing lifecycle: get page data, interact, fill forms, wait, navigate back, scroll, take screenshots, manage tabs, and batch fetch. Minor gaps include lack of an explicit forward navigation or refresh, and navigation to a URL is implicitly done via get_page_map(url), but these are workable gaps.
Average 4.6/5 across 13 of 13 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as destructive (destructiveHint=true) and not read-only, so the baseline safety profile is known. The description adds valuable behavioral context by explaining that closing the active tab triggers an auto-switch to the next available tab and that the browser context is released. This goes beyond the annotations and gives a clearer picture of consequences.
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 extremely concise and well-structured. It opens with the main action, adds one key behavioral note, and then lists the parameter. Every sentence earns its place, with no redundant or verbose content.
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 simple tool with a single parameter and an output schema, the description covers the essential behavior and a critical edge case (auto-switch on active tab). It does not explain error cases or prerequisites, but these are less critical given the simplicity and the presence of annotations and an output schema. It is nearly complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section says 'name: Tab identifier to close,' which adds a minimal semantic label but does not explain how to obtain the identifier, what format it should be in, or how it relates to other tools like list_tabs. This is barely more informative than the schema's generic 'Name' title.
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 starts with a clear verb+resource construction ('Close a tab') and adds a meaningful behavioral detail ('release its browser context'). It is easily distinguished from sibling tools like open_tab or switch_tab, which have opposite or different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose makes its usage obvious (close a tab), but the description provides no explicit guidance on when to use it versus alternatives like switch_tab or list_tabs. There is no mention of exclusions or alternative scenarios, so it only gives implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description discloses an important behavioral trait: 'All subsequent tool calls operate on this tab.' This indicates a persistent context change. It does not contradict annotations, as switching tabs is a UI state change, not a data mutation.
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 extremely concise, consisting of two sentences and a brief Args section. Every sentence adds value, with no fluff. The key behavior is front-loaded.
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?
Given the tool's simplicity (one parameter, no nested objects), the description covers the essential behavior and side effect on subsequent calls. The presence of an output schema means return values need not be described. It lacks explicit error behavior or prerequisite (e.g., tab must exist), but this is acceptable for this simple operation.
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?
The schema provides no description for the 'name' parameter (0% coverage), so the description compensates with 'Tab identifier to switch to.' This adds basic meaning but lacks details about where to obtain the identifier or its format, which could be inferred from sibling list_tabs.
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 clearly states the action with a specific verb and resource: 'Switch the active tab.' It also adds scope by noting that subsequent tool calls operate on this tab. This distinguishes it from sibling tools like open_tab, close_tab, and list_tabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to change the active tab) but does not explicitly mention alternatives or exclusions, such as 'use open_tab to create a new tab.' The context with siblings helps, but the description itself offers no direct contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it lists 'all' tabs and includes 'current state', indicating the output includes status information beyond just tab identifiers. This goes slightly beyond what annotations alone convey, but lacks details about format or edge cases (e.g., empty tab list).
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?
A single, well-structured sentence that is front-loaded with the action ('List') and resource ('all open tabs'). It is concise with no filler or redundant information.
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 simple read-only tool with no parameters and an output schema present, the description is fully sufficient. It clearly states the operation and scope, and the existing annotations and schema cover additional details like safety and return structure.
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?
The input schema has zero parameters, so schema coverage is trivially 100%. The baseline for zero-parameter tools is 4, and the description does not need to add parameter details. No further semantic clarification is required or possible.
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?
Description clearly states the verb ('list'), resource ('all open tabs'), and adds scope ('current state'). It distinguishes from sibling tools like open_tab, switch_tab, and close_tab, and is unambiguous about being a read-only listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance about when to use this tool versus alternatives. It does not compare with get_page_state or get_page_map, nor does it mention scenarios like inspecting tabs before switching or closing. The description simply states the function without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds context by noting it is 'lightweight' and returns 'URL, title' without a full rebuild, plus a security warning about untrusted page titles. This goes 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?
Three short sentences each serve a purpose: what it does, when to use it, and a relevant security warning. No fluff.
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 simple read-only tool with no parameters and an existing output schema, the description covers purpose, usage, behavior, and a trust caveat. It is fully sufficient.
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?
With 0 parameters, the baseline is 4. The description clarifies what state is returned (URL, title), adding meaningful context even though no parameters exist.
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 clearly states 'Get lightweight current page state (URL, title)' with a specific verb and resource. It also distinguishes this tool from its sibling 'get_page_map' by saying 'without full Page Map rebuild'.
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?
Explicitly recommends use 'after execute_action' to check navigation results. It implies an alternative (full Page Map) by stating 'without full Page Map rebuild', but does not explicitly say when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnlyHint and openWorldHint annotations by disclosing that content is untrusted, markers like <web_content_*> should not be treated as instructions, and token budgets are clamped. No contradiction with annotations; adds significant context.
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?
Front-loaded with the core purpose, then a succinct security warning, then a well-formatted parameter list. Every sentence adds value; length is justified given the number of parameters and context needed. No filler or redundancy.
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 tool's complexity (7 parameters, open-world input), the description covers return types, interaction workflow (ref numbers + execute_action), security caveats, and parameter semantics. An output schema exists, so return structure details are not required. No significant gaps remain.
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 has zero description coverage (0%), so the description fully compensates by explaining all 7 parameters in detail: defaults, allowed values, precedence (max_content_tokens overrides detail_level), clamping range, and use cases for each. This is comprehensive and clarifies meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get structured Page Map') and resource, with a clear listing of return contents (interactive elements, ref numbers, compressed content). It distinguishes from batch_get_page_map by implying single-page usage, but does not explicitly contrast with get_page_state, leaving some ambiguity among sibling tools.
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?
Explicitly states to use ref numbers with execute_action for interaction, and offers task_hint categories ('search', 'detail', 'cart', etc.) that imply when to use the tool in different contexts. It does not explicitly state when not to use it or name alternatives, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds context about the standalone nature and lack of Page Map dependency, which is not in annotations. It also clarifies full_page behavior (captures scrollable page vs viewport), providing useful behavioral detail. No contradiction.
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 exceptionally concise, with only three lines. It front-loads the primary purpose, then adds necessary parameter clarification. Every sentence serves a distinct function with no redundancy.
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?
The tool has a simple signature (one optional boolean), and the description covers the core functionality, parameter behavior, and operational prerequisite (standalone, no Page Map). With an output schema present, the lack of return-value details is acceptable. Overall, it's a complete and self-contained description.
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?
Despite 0% schema description coverage, the description fully explains the full_page parameter, meaning 'capture the full scrollable page' vs. default viewport only. This adds context beyond the schema's default false, making the boolean parameter's impact clear.
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?
Description clearly states the tool's function: taking a screenshot of the current page, which is distinct from sibling tools like get_page_state or navigate_back. The verb 'take' and resource 'screenshot' are specific, and the additional note about being a standalone diagnostic tool clarifies its role.
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?
The description provides context that this tool is standalone and does not require an active Page Map, which helps the agent decide when to use it independently. It doesn't explicitly mention alternatives or exclusions, but the standalone note implies it can be used without prerequisites, giving sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal openWorldHint and destructiveHint, but the description adds critical context about untrusted element names and the full return schema including refs_expired and error keys. This goes well beyond the structured 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 with a front-loaded purpose statement, a security warning, return value details, and a compact Args section. Every sentence adds value, and the formatting makes it 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?
For a mutation-heavy tool with an output schema and error handling, the description covers return keys, the refs_expired workflow, and untrusted input risks. It is complete enough for an agent to invoke correctly without additional context.
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?
With 0% schema description coverage, the description compensates by explaining ref's source, enumerating allowed actions ('click', 'hover', 'type', 'select', 'press_key'), and clarifying that value is used for type/select. However, the meaning of value for press_key is not fully specified.
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 'Execute an interaction on a page element by its ref number,' clearly stating the verb, resource, and key input. The list of action types further distinguishes it from siblings like get_page_map (which produces refs) and fill_form (form-specific).
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?
It instructs that ref comes from the Page Map Actions section and explicitly says to call get_page_map before retrying when refs_expired is true. It doesn't draw direct comparisons with fill_form or scroll_page, but the workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral side-effect not captured in the annotations: it 'Invalidates current Page Map refs on success.' This is valuable context that helps the agent understand the tool's impact beyond the readOnlyHint/destructiveHint flags. There is no contradiction with 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 two sentences long, front-loaded with the core purpose, followed by a necessary warning. Every sentence earns its place; there is no fluff or redundant information.
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 simple, parameterless action, the description covers the essential context: what the tool does and what the agent must do after success (fetch fresh refs). The presence of an output schema obviates the need to explain return values, and the mention of get_page_map ties it to a sibling tool. This is complete for the tool's complexity.
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?
With zero parameters, the schema is fully covered and there is nothing for the description to elaborate on. The baseline for a no-parameter tool is 4, and the description appropriately focuses on behavior rather than parameter details.
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 clearly states a specific action ('Navigate back to the previous page') with an explicit resource (browser history). This unambiguously distinguishes it from sibling tools like open_tab or switch_tab, which handle tab management rather than history navigation.
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?
The description provides clear context that the tool is used for navigating back in browser history, and it gives an explicit post-success instruction ('Call get_page_map to get fresh refs'). However, it does not mention when not to use it or compare it directly to alternatives like open_tab or switch_tab, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description discloses key behavioral details: each URL opens in a separate tab, results are stored in the URL LRU cache rather than the active slot, and individual failures are isolated. These are significant operational traits not inferable from annotations or schema.
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 tightly structured: a one-sentence summary, three bullet points of behavioral notes, and a clear Args list. No redundant text; every sentence adds value.
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 output schema exists, return values need not be described. The description covers parallel behavior, caching location, failure semantics, and parameter limits, making it complete for a multi-URL batch tool.
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?
The input schema only provides types and a default, while the description adds essential constraints: urls limited to 10 and http/https only, max_concurrency default 5 and maximum 5. This meaningfully enriches the schema and guides correct invocation.
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 begins with a clear, specific action: 'Get Page Maps for multiple URLs in parallel.' This distinguishes it from the sibling tool get_page_map by explicitly targeting multiple URLs and parallel processing.
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?
The description clearly implies usage for fetching page maps of multiple URLs concurrently, but does not explicitly state when to prefer this over the singular get_page_map or list any exclusions or alternatives. Thus it provides clear context but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as non-readOnly and destructive, so the bar is lower. The description adds key behavioral details: 'Fields are executed sequentially (order matters for dynamic forms)' and 'Stops on first error or navigation,' plus a security warning about untrusted element names. This exceeds the annotation coverage and provides important operational context.
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 structured in short, purposeful sections: purpose, benefit, execution semantics, security warning, and parameter summary. It front-loads the main verb and resource, and despite the detail, every sentence adds value without redundancy.
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 batch form-filling tool with a single array parameter and an output schema, the description covers purpose, usage context, execution order, error handling, and a security caveat. The only missing piece is an explicit note about return behavior, but the presence of an output schema makes that unnecessary.
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 description coverage is 0%, so the description must compensate. It does so by explaining each field's components (ref, action, value), stating that value is required for type/select, and providing a concrete JSON example. This adds meaning beyond the minimal schema definitions.
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 action and resource: 'Fill multiple form fields in a single batch call.' It clearly distinguishes from siblings by emphasizing the batch nature and gives example use cases (login, checkout, search forms), which differentiates it from single-action tools like execute_action.
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?
It explains when to use the tool: for forms where you want to reduce round-trips, and notes that fields execute sequentially and order matters for dynamic forms. It doesn't explicitly name an alternative or give when-not-to-use, but the context implies using this for multi-field batch operations rather than single-action tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that each tab maintains independent cookies, storage, and login state, that the new tab becomes active, and that there is a maximum of 5 simultaneous tabs. It also explains the cookie injection behavior for pre-authenticated sessions. These details add significant transparency without contradicting the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false).
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, starting with a clear summary sentence, followed by key behavioral notes, then a bulleted parameter list. Each sentence adds useful information—no fluff—making it appropriately concise for a tool with three parameters.
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 presence of an output schema and annotations, the description covers the essential operational aspects: purpose, parameter semantics, side effects (active tab), and constraints (max 5 tabs). The only minor gap is what happens when the maximum is exceeded, but this is not required for a complete description.
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?
The input schema has no descriptions (0% coverage), so the description fully compensates. It details each parameter: 'name' is a unique identifier with alphanumeric+underscore and max 30 chars; 'url' is restricted to http/https; 'cookies' are pre-authenticated session cookies injected before navigation. This provides essential semantic meaning beyond the bare schema.
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 clearly states 'Open a new browser tab with an independent session', identifying the verb (open), resource (browser tab), and key characteristic (independent session). It also distinguishes from sibling tools like switch_tab and list_tabs by emphasizing it creates a new tab. The addition of becoming the active tab and max 5 tabs further clarifies the tool's role.
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?
The description provides context on when to use this tool by explaining each tab has its own cookies, storage, and login state, implying use when an isolated session is needed. However, it does not explicitly mention alternatives or cases where this tool should not be used, such as switching to an existing tab, which is handled by switch_tab. This earns a 4 rather than a 5 due to lack of explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a non-obvious side effect: scrolling invalidates current Page Map refs, which is critical for the agent to know. This goes beyond the readOnlyHint/openWorldHint annotations and adds real behavioral context.
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 compact and front-loaded: one sentence states purpose, a second covers the side effect, and a brief Args section provides parameter details. Every sentence earns its place.
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?
The tool is simple, and the description covers purpose, side effects, and parameter semantics. An output schema exists, so the lack of return-value detail is acceptable. No critical gaps.
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?
With 0% schema description coverage, the description fully compensates by explaining direction ('up' or 'down') and amount ('page', 'half', integer pixels max 50000). This adds meaning beyond the bare schema.
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 clearly states the tool scrolls the page up or down with a specific verb and resource. It distinguishes itself from siblings like get_page_map or navigate_back by focusing on viewport scrolling.
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?
Provides clear context by noting that Page Map refs are invalidated and instructing to call get_page_map afterwards. It does not explicitly state when to use scroll_page over other navigation tools, but the follow-up guidance is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses that the page map is invalidated after the condition is met and instructs to call get_page_map for updated references. It also mentions case-sensitivity, max character length, and timeout behavior—details not present in the schema or annotations. This fully characterizes the tool's operational side effects.
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 compact, front-loaded with the core purpose, and every sentence adds value—usage mode, avoidance of polling, side-effect warning, and parameter semantics. There is no redundancy or filler.
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 tool's moderate complexity, the description covers purpose, usage constraints, parameter details, and post-condition behavior. The output schema exists, so return values need not be explained. This is a complete and self-sufficient description.
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 description coverage is 0%, yet the description provides comprehensive meanings for all three parameters: text (appearance, case-sensitive, max 500 chars), text_gone (disappearance, e.g., 'Loading...'), and timeout (default 10, max 30). This fully compensates for the missing schema descriptions and exceeds the baseline.
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 begins with a specific verb+resource construction ('Wait for text to appear or disappear on the page') and clearly distinguishes itself from sibling tools like get_page_state and get_page_map. It precisely defines the two modes (appearance vs disappearance) and sets expectations for the operation.
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 explicitly advises avoiding repeated get_page_map calls, giving a clear when-to-use context. It also states the constraint 'Specify exactly one of text or text_gone', which is actionable usage guidance. This effectively differentiates the tool from alternatives and provides clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Retio-pagemap MCP server](https://glama.ai/mcp/servers/Retio-ai/Retio-pagemap/badges/card.svg)](https://glama.ai/mcp/servers/Retio-ai/Retio-pagemap)

Score Badge

Copy to your README.md:

[![Retio-pagemap MCP server](https://glama.ai/mcp/servers/Retio-ai/Retio-pagemap/badges/score.svg)](https://glama.ai/mcp/servers/Retio-ai/Retio-pagemap)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Retio-ai/Retio-pagemap'

If you have feedback or need assistance with the MCP directory API, please join our Discord server