Playwright Plus Python MCP

by MCP-Mirror

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between playwright_click and playwright_click_text, which could cause confusion about when to use each. The other tools are clearly differentiated by their specific actions like navigation, evaluation, or content retrieval.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with the prefix 'playwright_' followed by a descriptive verb or verb_noun combination. This uniformity makes the tool set predictable and easy to understand at a glance.
Tool Count5/5
With 8 tools, this server is well-scoped for browser automation tasks, covering essential actions like clicking, navigating, evaluating JavaScript, and retrieving content. Each tool serves a clear purpose without being overly complex or sparse.
Completeness4/5
The tool set covers core browser automation workflows, including navigation, interaction, and content extraction. However, there are minor gaps, such as the lack of tools for handling pop-ups, managing cookies, or performing drag-and-drop actions, which could limit some advanced automation scenarios.
Average 2.9/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Fill out an input field' implies a write operation but doesn't specify if it requires page interaction, handles errors (e.g., missing selector), or has side effects like triggering events. It lacks details on permissions, rate limits, or response format, which is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence ('Fill out an input field') that directly states the purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 a web automation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return values, error handling, or interaction context (e.g., requires a loaded page). For a tool that performs mutations in a dynamic environment, more context is needed to ensure correct usage.
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 input schema has 100% description coverage, with clear documentation for 'selector' (CSS selector) and 'value' (value to fill). The description doesn't add any meaning beyond this, such as examples or constraints, but the schema provides sufficient detail. According to the rules, with high schema coverage, the baseline is 3 even without extra param info in the description.
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 'Fill out an input field' clearly states the action (fill) and target (input field), which is better than a tautology. However, it lacks specificity about what kind of input field or context (e.g., web page, form) and doesn't distinguish it from potential sibling tools like playwright_click_text that might also interact with input fields. This makes it vague but functional.
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. It doesn't mention sibling tools like playwright_click or playwright_evaluate, nor does it specify prerequisites (e.g., needing a page loaded) or exclusions. This leaves the agent with minimal context for tool selection.
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 provided, the description carries full burden for behavioral disclosure. It mentions 'auto create a session' which adds some context about session management, but fails to describe critical behaviors: whether navigation is blocking, timeout handling, error conditions, or what happens if the URL is invalid. For a navigation tool with zero annotation coverage, this leaves significant gaps.
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 brief and front-loaded with the core purpose. The two clauses ('Navigate to a URL' and 'thip op will auto create a session') are both relevant, though the second has a typo ('thip op' likely means 'this op'). There's no unnecessary verbosity, but the typo slightly reduces clarity.
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 no annotations, no output schema, and 0% schema description coverage for a navigation tool, the description is incomplete. It doesn't explain what happens after navigation, error handling, session lifecycle implications, or return values. For a tool that likely has side effects and behavioral complexity, this leaves too much unspecified.
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 for the undocumented parameter. The description mentions 'URL' but provides no semantic context about what constitutes a valid URL, whether relative URLs are supported, or any format requirements. It adds minimal value beyond what's implied by the parameter name 'url' in 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 the tool's purpose: 'Navigate to a URL' specifies the verb and resource. It distinguishes from siblings like playwright_click or playwright_fill by focusing on navigation rather than interaction or content extraction. However, it doesn't explicitly differentiate from potential navigation alternatives (though none are listed in 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?
The description provides no guidance on when to use this tool versus alternatives. While it mentions 'auto create a session,' it doesn't explain prerequisites, when navigation is appropriate versus other actions, or any constraints. There's no explicit when/when-not usage context provided.
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 carries the full burden. It states the action ('click') but lacks behavioral details: it doesn't specify if this waits for the element to be clickable, handles errors (e.g., if selector not found), requires page interaction permissions, or has side effects (e.g., navigation). The description is minimal and misses key 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 a single, efficient sentence with zero waste. It front-loads the core action ('Click an element') and method ('using CSS selector'), making it easy to parse. Every word earns its place without redundancy.
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 no annotations, no output schema, and a simple but action-oriented tool (clicking can trigger navigation or errors), the description is incomplete. It lacks context on prerequisites (e.g., page must be loaded), error handling, behavioral traits (e.g., waiting), or output expectations. For a tool with potential side effects, this is inadequate.
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 description coverage is 100%, with the parameter 'selector' fully documented in the schema as 'CSS selector for element to click'. The description adds no additional meaning beyond this, such as selector syntax examples or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
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 action ('click') and target ('element on the page'), and specifies the method ('using CSS selector'). It distinguishes from sibling tools like playwright_click_text (which clicks by text) and playwright_fill (which fills inputs). However, it doesn't explicitly contrast with all siblings, such as playwright_evaluate or playwright_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. It doesn't mention prerequisites (e.g., needing a page loaded), exclusions (e.g., not for non-interactive elements), or comparisons to siblings like playwright_click_text (CSS selector vs. text matching). Usage is implied but not explicitly stated.
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 provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe execution context (e.g., runs in page context vs isolated), error handling, return values, or potential side effects. 'Execute JavaScript' implies mutation capability but lacks details about permissions or safety considerations.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and immediately communicates the core functionality without unnecessary elaboration.
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?
For a JavaScript execution tool with no annotations and no output schema, the description is insufficient. It doesn't explain what gets returned, error conditions, execution environment details, or how results are formatted. The agent would need to guess about important behavioral aspects.
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 has 100% description coverage with the 'script' parameter clearly documented. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without providing additional semantic context.
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 action ('Execute JavaScript') and location ('in the browser console'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like playwright_get_html_content or playwright_get_text_content which might also involve JavaScript execution indirectly.
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. It doesn't mention prerequisites (e.g., needing a page loaded), when-not-to-use scenarios, or how it differs from other playwright tools that might manipulate the browser in different ways.
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 provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states what the tool does but doesn't describe how it behaves: no mention of error handling (e.g., what happens if the selector doesn't exist), performance characteristics, or return format details. The description doesn't add meaningful context beyond the basic action, leaving significant gaps in understanding the tool's operational behavior.
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 at just one sentence ('Get the HTML content of the page'), with no wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place, and there's no unnecessary elaboration or redundancy.
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 tool's complexity (interacting with web pages via Playwright) and the absence of both annotations and an output schema, the description is insufficiently complete. It doesn't explain what the tool returns (e.g., raw HTML string, structured data), error conditions, or dependencies on other tools like 'playwright_navigate'. For a tool with no structured behavioral hints, the description should provide more operational context to be truly helpful.
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 input schema has 100% description coverage, with the 'selector' parameter clearly documented as a 'CSS selector for the element'. The description adds no additional parameter semantics beyond what's in the schema. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
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 action ('Get') and resource ('HTML content of the page'), making the tool's purpose immediately understandable. It distinguishes itself from sibling tools like 'playwright_get_text_content' by specifying HTML content rather than text. However, it doesn't explicitly mention that this operates on a web page context, which is implied but could be more specific.
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. It doesn't mention sibling tools like 'playwright_get_text_content' for text extraction or 'playwright_evaluate' for more complex DOM interactions. There's no context about prerequisites (e.g., requiring a page to be loaded first) or typical use cases, leaving the agent to infer usage from the tool name alone.
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 provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't mention important behavioral aspects: whether this requires specific page states, what format the screenshot returns (image data, file path), if there are size/quality settings, or any error conditions. The description is minimal and lacks 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 a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool and front-loads the core functionality.
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?
For a tool with 2 parameters (one undocumented), no annotations, and no output schema, the description is inadequate. It doesn't explain what the 'name' parameter does, what the tool returns, or important behavioral constraints. The minimal description leaves too many gaps for effective tool use.
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 description coverage is 50% (only 'selector' has a description). The description mentions 'current page or a specific element' which aligns with the selector parameter's documented behavior, but doesn't explain the 'name' parameter at all. It adds minimal value beyond what's already in the schema description for selector.
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 action ('Take a screenshot') and target ('current page or a specific element'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like playwright_get_html_content or playwright_get_text_content, which also capture page content in different formats.
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. It doesn't mention when screenshotting is preferable to getting HTML/text content from sibling tools, nor does it discuss prerequisites like needing a page to be loaded first.
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 provided, the description carries the full burden of behavioral disclosure. It states the action ('Click') but lacks details on what happens after clicking (e.g., page navigation, error handling if text isn't found, or interaction effects). For a tool that performs UI actions, this is a significant gap in 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?
The description is a single, clear sentence that efficiently conveys the core functionality without unnecessary words. It is front-loaded with the main action and target, making it easy to parse quickly. Every part of the sentence serves a purpose.
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 moderate complexity (performing a UI action) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but omits important context like error conditions, return values, or interaction with sibling tools. It meets the minimum viable threshold but has clear 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?
The input schema has 100% description coverage, with the 'text' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as examples of text content or matching behavior. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 action ('Click') and target ('an element on the page by its text content'), making the purpose immediately understandable. It distinguishes itself from the sibling 'playwright_click' by specifying text-based targeting, though it doesn't explicitly contrast with other siblings like 'playwright_fill' or 'playwright_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. It doesn't mention scenarios where text-based clicking is preferred over other methods (e.g., using 'playwright_click' for different selectors) or prerequisites like needing a page to be loaded first. Usage is implied but not explicitly stated.
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 carries full burden but provides minimal behavioral insight. It doesn't disclose if this is read-only, what 'all elements' entails (e.g., scope, filtering), potential side effects, or output format, leaving key traits undefined.
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, direct sentence with no wasted words, making it highly concise and front-loaded. Every word contributes to stating the tool's purpose efficiently.
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 no annotations, no output schema, and a vague description, the tool lacks completeness. It doesn't explain what 'text content' includes (e.g., trimmed, formatted), how elements are selected, or the return structure, making it inadequate for informed use.
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 tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description doesn't add param details, but this is acceptable given the lack of parameters, warranting a baseline score above minimum.
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 action ('Get') and target ('text content of all elements'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'playwright_get_html_content' or specify what 'all elements' means in context, preventing a perfect score.
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 'playwright_get_html_content' or 'playwright_evaluate'. The description lacks context about prerequisites (e.g., needing a page loaded) or exclusions, leaving usage unclear.
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:

[![williamvd4_playwright-plus-python-mcp MCP server](https://glama.ai/mcp/servers/MCP-Mirror/williamvd4_playwright-plus-python-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MCP-Mirror/williamvd4_playwright-plus-python-mcp)

Score Badge

Copy to your README.md:

[![williamvd4_playwright-plus-python-mcp MCP server](https://glama.ai/mcp/servers/MCP-Mirror/williamvd4_playwright-plus-python-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MCP-Mirror/williamvd4_playwright-plus-python-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/MCP-Mirror/williamvd4_playwright-plus-python-mcp'

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