Browser-MCP Navigator

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., click vs js_click vs cdp_call), but the difference between click and js_click might confuse an agent without careful reading. Overall, each tool targets a unique action.
Naming Consistency3/5
All names use snake_case, but the pattern mixes simple verbs (click, hover, scroll) with verb_noun phrases (get_text, read_console, press_key) and compound noun_verb (js_eval, cdp_call). This inconsistency, while still readable, could be improved.
Tool Count4/5
21 tools is slightly above the typical 3-15 range, but each tool serves a specific need in browser automation (navigation, interaction, JavaScript execution, bulk operations, etc.). The count feels justified for the domain.
Completeness4/5
Covers essential browser automation operations: navigation, clicking, typing, scrolling, waiting, reading page state, console/network monitoring, and JavaScript execution. Missing a dedicated file upload tool, but can be done via cdp_call. Minor gaps overall.
Average 3.5/5 across 21 of 21 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions 'human click' and 'returns new snapshot,' but fails to explain what happens if the element is not found, whether it waits, or any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, but the brevity sacrifices clarity and completeness. It could benefit from more structured information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of browser tools and the presence of an output schema, the description lacks contextual details about prerequisites (e.g., active page), element visibility, or the content of the returned snapshot.
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?
The schema has 0% description coverage for the single parameter 'ref.' The description hints at an element identifier via '@eN' but does not explain the format or coordinate usage, and conflicts with 'by coordinates.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a human click on an element, returning a new snapshot, which distinguishes it from programmatic clicks like js_click. However, the phrase 'por coordenadas' (by coordinates) conflicts with the parameter 'ref' (likely an element reference), causing ambiguity.
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 guidance is provided on when to use this tool versus alternatives like hover, fill, or js_click. The description does not mention prerequisites or when it is appropriate to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses focusing, clearing, typing, and optional submit. However, it does not explain what '@eN' means (likely a placeholder), whether the tool waits for elements, or error handling. The behavior is partially described but lacks important details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but its shorthand (e.g., '@eN') reduces clarity. It is appropriately short but at the expense of understandability. The information is front-loaded with 'Enfoca' (focuses) as the first word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of browser automation and the lack of annotations, the description is incomplete. It does not cover return values (though output schema exists), error states, or prerequisites like element visibility. For a tool with 3 parameters and no enums, the description is insufficient for an agent to use it correctly without additional context.
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. It mentions 'ref' implicitly via '@eN' and 'text' via 'escribe text', and explicitly mentions 'submit=True'. However, it does not define 'ref' or 'text' clearly, nor their expected formats. Adds minimal value 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?
The description clearly states that the tool focuses on an element (by ref), clears it, and writes text, with an option to submit (Enter). The verb 'fill' aligns with this action. It differentiates from siblings like 'set_value' or 'click' by implying a sequence of actions, but does not explicitly distinguish from siblings.
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 guidance is provided on when to use 'fill' versus alternatives like 'set_value' or 'js_eval'. There are no exclusions or context for appropriate use. The description implies use for filling form fields, but this is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions capturing the accessibility tree but does not indicate whether it is read-only, side-effect-free, or requires permissions. The parameter 'interactive_only' is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it lacks structure and important details. It is concise but at the expense of completeness, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (one optional param, many siblings, output schema exists), the description is incomplete. It fails to explain the parameter, usage context, or how the output differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the lone parameter 'interactive_only'. The parameter's effect on the output is entirely unaddressed.
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 captures the accessibility tree as compact text, which is a specific verb and resource. It distinguishes from sibling tools like screenshot and get_text by targeting accessibility data.
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 guidance is provided on when to use this tool versus alternatives such as get_text or screenshot. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses wait strategies (none|load|networkidle) and mentions returning a snapshot, which is behavioral. However, it does not explain side effects like page replacement or that the tool modifies the current page state. Annotations are absent, so the description partially carries the burden.
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?
The description is very concise, one sentence covering core purpose and wait options. It is front-loaded but could benefit from structured bullet points or more detail on return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description does not elaborate on what 'snapshot' means (e.g., content type, format). With no annotations and low schema coverage, the description feels incomplete for a navigation tool that changes page state.
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?
With 0% schema description coverage, the description does not explain the 'url' or 'wait' parameters beyond what the schema already provides (required url, optional wait with default). It adds minimal semantic value.
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?
The description clearly states the verb 'navigate' and the resource 'a URL', and mentions additional actions (wait strategies and returns snapshot). It distinguishes from sibling tools like 'click' or 'fill' by specifying navigation context.
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 guidance is provided on when to use this tool versus alternatives like clicking a link or using 'current_url'. The description lacks any contextual cues for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose more. It only says 'presses a key' but doesn't mention key-up/down, waiting, or effects on disabled elements.
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?
Single sentence, front-loaded with action, concise. However, could list accepted keys more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with output schema. But lacks clarity on whether it types into an active element or sends events, and when to use over siblings.
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 0%, but the description adds meaning: 'key' is a named key with examples, and 'ref' is optional for focusing. This compensates well.
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?
The description clearly states it presses a named key and gives examples (Enter, Tab, ArrowDown). It differentiates from siblings by specifying keyboard interaction, but does not explicitly distinguish from tools like 'js_eval' for keyboard events.
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 guidance on when to use this tool versus alternatives like 'click' or 'fill'. The optional 'ref' hint suggests focusing, but no explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It does not clarify behavior when both label and value are provided, what happens if no match is found, or if the element is not a <select>. Lacks important behavioral details.
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?
The description is a single concise sentence, front-loading the verb and resource. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the browser automation context and existence of an output schema, the description is adequate for a simple selection tool but lacks error handling details and return value information. It is minimally complete but could be improved.
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 description must explain parameters. It mentions selecting by value or label, which covers label and value parameters, but does not explain the 'ref' parameter (likely a selector for the <select> element). Also unclear if label and value are mutually exclusive or how they interact.
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 selects an option from a <select> element, specifying two methods (by value or by visible label). This verb+resource combination distinguishes it from sibling tools like click, fill, etc.
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 usage guidelines provided. Does not mention when to use this tool versus alternatives (e.g., set_value, click), nor prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the basic action. No warnings about consequences of terminating the connection or process, especially given no annotations are present.
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 a single sentence that efficiently conveys the tool's purpose and parameter behavior with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stop tool, the description is mostly adequate but lacks usage context and potential side effects. The output schema is not shown but present.
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 parameter 'kill' has no schema description (0% coverage), but the description adds meaning by explaining its effect. This compensates for the missing schema detail.
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?
The description clearly states the tool closes a CDP connection and optionally terminates Chrome, which is a specific verb+resource. It distinguishes from sibling tools like browser_start.
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 guidance is provided on when to use this tool versus alternatives like cdp_call or browser_start. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions listing and filtering but does not explain the effect of the 'clear' parameter, whether the tool is read-only, or what happens when capture is not active.
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?
A single sentence that directly conveys the core purpose without repetition, though it could benefit from separating key behaviors.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about prerequisites (e.g., network capture must be active), return type (even though an output schema exists), and does not mention side effects of the 'clear' parameter.
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?
With 0% schema description coverage, the description must compensate. It explains the 'filter' parameter (optional URL substring) but completely omits the 'clear' parameter, leaving its semantics unclear.
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 lists captured requests with optional URL substring filtering, which is specific and distinguishes it from siblings like read_console.
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 usage for reading network requests but provides no explicit guidance on when to use this tool versus alternatives or prerequisites like browser capture state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions launching or reconnecting Chrome but does not explain implications of reconnection, side effects, authentication needs, or what happens with the headless parameter. The description lacks depth for safe agent usage.
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 short sentences. Every sentence adds value: the first states the tool's action, the second gives an essential usage hint. No unnecessary words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 optional parameter, no annotations) and existence of an output schema, the description is minimal but covers the core action and ordering requirement. However, it fails to explain the headless parameter or the reconnection behavior, leaving gaps for an agent. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'headless' parameter at all. It adds no meaning beyond the schema's type definition. The agent receives no guidance on how or why to set headless mode, which is critical for a start tool.
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 launches or reconnects Chrome with CDP, specifying the verb 'lanza' (launch) and resource 'Chrome con CDP'. It distinguishes from sibling tools by indicating it must be called before any others, which implies it is the initialization step.
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 explicitly states 'Debe llamarse antes que las demas tools' (must be called before the other tools), providing clear context for when to use this tool. However, it does not mention when not to use it or provide alternatives, but the context of sibling tools makes the purpose evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral disclosures such as side effects, required permissions, whether it waits for events, or what happens on failure. It only states it's 'direct' and 'more reliable' without sufficient detail.
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?
The description is very concise (two sentences) and front-loaded with the key purpose. However, it could add a brief explanation of the parameter without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to mention error handling, prerequisites, or whether the action is synchronous. The lack of annotation coverage and parameter clarity makes it incomplete for a tool with one critical parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'ref' has no description in the schema (0% coverage) and the tool description does not clarify what it represents (e.g., CSS selector, element handle). The description adds no meaning beyond the schema's 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 clearly states it performs a direct JS element.click() and distinguishes it from sibling 'click' by noting it's more reliable for React SPAs and Angular, especially when standard click fails due to event delegation.
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?
Explicitly says to use when click() does not trigger the handler, with an example (React 17+ delegation), providing clear when-to-use and implied when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the core behavior (returning innerText based on ref) but does not disclose error handling, element existence, or edge cases.
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 a single sentence with no fluff, front-loading the main action and conditional behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool is simple, the description is adequate but lacks details on failure modes or return format, leaving some gaps.
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 has 0% description coverage; the description partially compensates by linking ref to an element identifier (@eN) and indicating the null case. However, it does not specify the format or expected value of ref.
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 it returns the innerText of an element or the full body if ref is None, which is specific and distinguishes it from sibling tools like click or navigate.
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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses basic behavior (wait until text appears or timeout) but lacks details on what happens on timeout (e.g., error vs. return value) or how 'appears' is defined (visible, present in DOM). With no annotations, more depth would be beneficial.
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 a single, concise sentence with no unnecessary words. It front-loads the essential action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple wait tool, the description covers the core functionality. However, it omits behavioral details like whether the tool blocks until condition met or returns a result, and the output schema (though present) is not described, leaving some uncertainty.
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 description mentions both parameters (text and timeout_ms), which adds meaning beyond the schema's type definitions. However, coverage is 0% and the description does not clarify nuances like what 'text' matching entails (exact substring? case-sensitive?) or the unit of timeout_ms (milliseconds implied).
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's action: waiting until text appears on the page, with a timeout. It uses a specific verb ('wait for') and resource ('text on the page'), distinguishing it from sibling tools like 'click' or 'navigate'.
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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a page already loaded, nor does it compare to sibling tools like 'get_text' for reading text after a wait.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It mentions moving to center and triggering hover effects, but lacks details on waiting, side effects, or safety.
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 sentence efficiently conveys the core functionality with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the parameter semantics gap leaves it incomplete. An output schema exists but is not referenced in the description.
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 coverage is 0%, and the description does not explain the 'ref' parameter beyond a cryptic '@eN' reference. The agent cannot infer what input is expected.
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 (move mouse to center) and the effect (triggers hover menus/tooltips). It distinguishes itself from sibling tools like 'click' and 'scroll'.
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 usage for hovering over elements to trigger menus, but does not explicitly state when to use it vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that setting clear=True empties the buffer, which is important. However, it does not clarify whether reading is destructive, whether it returns only new messages, or the order of operations (return then clear). More transparency is needed for a complete behavioral understanding.
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 short sentences, front-loaded with the main purpose. Every word adds value; no redundancy. It efficiently communicates the core function and a key parameter behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides basic function and parameter effect, but lacks context about when to use (e.g., after browser actions, requires active session). Since an output schema exists, return value details are not needed, but usage prerequisites are missing. The Spanish language might be a minor barrier but is not penalized heavily.
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 0% description coverage, so the description must compensate. It explains the effect of the clear parameter: 'clear=True vacia el buffer' (empties the buffer). This adds meaning beyond the schema's type and default, though it could explicitly state what happens when clear is false.
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 returns captured console messages. The verb 'Devuelve' (returns) and resource 'mensajes de consola capturados' specify the action and object. It also mentions the clear parameter effect, which distinguishes it from sibling tools that perform browser actions (click, navigate) or other reads (read_network).
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 guidance is provided on when to use this tool versus alternatives like read_network or when it should be invoked in a browser session. The description lacks context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the output is a base64 PNG, but does not mention whether the tool is read-only or destructive, nor does it detail the effect of the 'full_page' parameter. The behavioral insight is minimal.
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?
The description is a single short sentence, which is concise and front-loaded with the key purpose. However, it is informal and mixed-language, missing an opportunity to be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema. The description adequately clarifies the relationship with the sibling 'snapshot' tool but fails to explain the 'full_page' parameter or describe the output structure. It is minimally complete.
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 explain parameters. It does so for none: the 'full_page' boolean parameter is not described. The description adds no meaning beyond what the schema's name and default value imply.
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 it is an 'escape hatch' producing a PNG in base64, and contrasts it with the default text snapshot. It distinguishes from the sibling 'snapshot' tool by specifying the output format.
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 phrase 'usa snapshot de texto por defecto, no esto' explicitly tells the agent that the text snapshot is the default, implying this tool is for when a graphical screenshot is needed. Clear context is provided, though no explicit when-not-to-use scenarios are listed.
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?
Despite no annotations, the description reveals the underlying mechanism (using Object.getOwnPropertyDescriptor and dispatching input+change events) and why it's needed. This provides good transparency about the tool's behavior beyond a simple value assignment.
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 concise, front-loading the purpose, then providing technical rationale, and ending with usage examples. Every sentence adds value without redundancy.
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 complexity of working with framework-controlled inputs, the description covers the essential behavioral details (setter override, event dispatching). However, it lacks parameter documentation and does not mention the output schema, though the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no explanation of the parameters 'ref' and 'value'. While 'ref' likely refers to an element selector and 'value' the target value, the description should explicitly define them, especially given the tool's complexity.
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 sets the value of input/select elements using the native JS setter, specifically for controlled inputs in React/Vue/Angular. This distinguishes it from sibling tools like 'fill' or 'click', which have different mechanisms.
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 explicitly lists use cases (date pickers, spinbuttons, custom selects, inputs with validation) and explains why it's necessary (framework overrides setter). It doesn't explicitly state when not to use, but the context implies it's for controlled inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the operation is 'cheap' (non-destructive, fast) and excludes snapshot data. However, does not mention error conditions or prerequisites like a loaded page.
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?
Single sentence with all key information front-loaded: what it returns and key quality (cheap, without snapshot). No wasted words.
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 no parameters and presence of an output schema (which likely documents return structure), the description is adequately complete. It adds context about cost and snapshot exclusion, sufficient for a simple retrieval tool.
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?
No parameters exist, and schema coverage is 100%. Baseline is 4 for zero-param tools. The description adds value by explaining what the tool returns (URL and title) beyond the empty 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?
Clearly states the tool returns URL and title, and distinguishes from snapshot by noting it's cheap and without snapshot. The verb 'Devuelve' (returns) is specific, and the resource is the current page's URL and title.
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?
Implies usage for quick URL/title checks without need for full snapshot, but does not provide explicit when-not or alternatives among siblings like navigate or get_text. Guidance is implicit but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It covers async execution, element context, and batch behavior. However, it does not disclose potential risks (e.g., page state changes, security implications, error handling). Adequate but not exhaustive.
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?
Description is fairly long but well-structured with examples, performance advice, and clear sections. Front-loaded with core purpose. Slightly verbose but every section adds value.
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 output schema exists (though not shown), return values need not be explained. Covers main use cases, batch processing, and sibling differentiation. Mentions js_eval_loop for large datasets. 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?
Schema coverage is 0%, so description must compensate. It explains 'script' as JavaScript code and 'ref' with two modes (None vs @eN) with examples. Adds meaningful context beyond 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?
Clearly states it executes arbitrary JavaScript on the page returning result + snapshot. Distinguishes between ref=None (window context) and ref=@eN (element context). Examples clarify usage. Sibling js_eval_loop is mentioned for batch operations, differentiating use cases.
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?
Explicitly explains when to use ref=None vs ref=@eN. Provides a performance section advising batch operations to avoid multiple round-trips, and directs to js_eval_loop for large datasets. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains internal mechanics (scrollBy vs scrollIntoView) and gives examples. However, it does not disclose if scrolling is smooth, if it waits for completion, or return value details. Moderate transparency.
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?
Description is concise with front-loaded purpose, uses bullet points and examples efficiently. Every sentence adds value.
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?
Description covers main behavior and common use cases. With an output schema present, it need not detail return values. Lacks edge cases (e.g., invalid ref) but sufficient for typical usage.
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 0% description coverage, so description fully compensates. It explains the role of x, y, ref, default behavior, and provides concrete examples showing parameter usage.
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 a page or specific element, with a verb and resource. No sibling tool does scrolling, so it is well-differentiated.
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?
Examples show when to use with ref (element) vs without (window), and how to scroll to bottom. No explicit when-not-to or alternatives, but it's the only scroll tool, so guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the session context (use_session parameter) but does not disclose potential risks like browser crashes or permission requirements. The examples imply safe usage but lack explicit warnings about destructive behavior.
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?
The description is relatively concise, front-loading the purpose and then explaining parameters and examples. Every sentence adds value, but it could be slightly more condensed without losing clarity.
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 has 3 parameters, no annotations, and an output schema exists (return values not required), the description covers all necessary usage information: parameter meanings, when to use vs siblings, and concrete examples. It is complete for an agent to select and invoke the tool correctly.
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 all three parameters: method (domain.method format), params (JSON string with example), and use_session (boolean for context). Examples clarify parameter usage.
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 'Llama cualquier metodo del protocolo CDP directamente' (calls any CDP method directly), and then gives examples of actions without dedicated tools, distinguishing it from siblings like click, navigate, etc.
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 explicitly says 'Ejemplos de acciones que no tienen tool dedicada' (examples of actions without dedicated tool), guiding the agent to use this tool for CDP methods that are not covered by sibling tools. It provides concrete examples like drag & drop, file upload, device emulation.
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?
With no annotations provided, the description carries full burden and does well: it explains the execution flow (script per item, item variable available), return format (array with ok/result/error per item plus final snapshot), and the delay parameter. However, it does not explicitly mention potential risks of running arbitrary JS or whether the tool is destructive, which could be important for safety.
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: a brief summary, then explanation of variable and return, usage guidance, parameter details, and a comprehensive example. Every sentence adds value without unnecessary fluff, balancing detail with conciseness.
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 complexity, the description covers the main aspects: what it does, how to use it, and what it returns. It even provides a working example. However, it does not address edge cases like empty items or script errors, and the output schema is not shown but the description mentions the return format. Slightly more detail on error handling would improve completeness.
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 thoroughly explains each parameter: items (list of objects), script (JS with await and item in scope), delay_ms (default 300ms). The detailed example further clarifies usage, providing much-needed semantics beyond the bare schema types.
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's purpose: 'Ejecuta script una vez por cada item — UNA llamada en lugar de N.' It distinguishes from sibling tools like js_eval by emphasizing that it handles bulk operations in a single call, making the purpose and uniqueness evident.
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 explicitly advises to use this tool instead of calling js_eval/click/fill N times for bulk operations, providing a clear usage context. It also explains the performance benefit: 'Cada tool call = un round-trip LLM. Un loop aqui = 50-100x mas rapido para N>5.' This gives strong guidance on when to use it.
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:

[![Fast-browser-MCP MCP server](https://glama.ai/mcp/servers/ingjohnfigueroablanco/Fast-browser-MCP/badges/card.svg)](https://glama.ai/mcp/servers/ingjohnfigueroablanco/Fast-browser-MCP)

Score Badge

Copy to your README.md:

[![Fast-browser-MCP MCP server](https://glama.ai/mcp/servers/ingjohnfigueroablanco/Fast-browser-MCP/badges/score.svg)](https://glama.ai/mcp/servers/ingjohnfigueroablanco/Fast-browser-MCP)

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/ingjohnfigueroablanco/Fast-browser-MCP'

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