nodriver-mcp

by namecallfilter

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: v0.1.0
Disambiguation4/5
Tools are generally distinct, but browser_open and scraper_run could confuse an agent: both involve navigation, though scraper_run is specifically for executing a saved scraper. Descriptions mitigate this ambiguity largely.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with clear prefixes (browser_ and scraper_), making the purpose predictable and easy to navigate.
Tool Count5/5
Nine tools cover both browser interaction and scraper management without excess or deficiency, well-scoped for a focused MCP server.
Completeness4/5
The set covers core browser operations and CRUD-like scraper management (list, get, save, run), but lacks a delete scraper tool, which is a minor gap for full lifecycle management.
Average 3.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and openWorldHint=true, which the description does not contradict. The phrase 'hot-load' adds some behavioral context, but the description does not elaborate on side effects, state changes, or error conditions beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no fluff. Every word earns its place.
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 (7 parameters, mutable, destructive, open world, output schema exists), the description is too brief. It does not explain what 'hot-load' means, mention required parameter 'name', describe return values, or address error conditions. An output schema is present but not referenced.
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 repeats the constraint 'new_tab requires url' which is already in the schema's description for new_tab. It does not add meaning for the other five parameters (name, params, headless, timeout_seconds, tab_id). With schema description coverage at 29% (though the schema itself has descriptions), the tool description fails to compensate for the gap.
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 uses a specific verb ('run') and resource ('saved scraper'), and includes a constraint on parameter usage. It clearly distinguishes from sibling tools like scraper_list, scraper_get, and scraper_save, as well as browser tools.
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 mentions using 'either url or tab_id' and that 'new_tab requires url,' which provides some parameter guidance. However, it does not specify when to use this tool versus alternatives (e.g., browser_open), nor does it mention prerequisites like the scraper must already be saved.
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 annotations already declare readOnlyHint=true, which the description echoes with 'Report'. No additional behavioral traits (e.g., performance, tab requirements, error conditions) are disclosed beyond what annotations provide. The description adds no new transparency value.
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 with no fluff, but it could be slightly more informative (e.g., mentioning that it returns a snapshot of tab state). Still, it is well-structured and front-loaded with the key action.
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?
With no parameters and an existing output schema (which documents return values), the description is mostly complete. However, it does not clarify what 'MCP-accessible tabs' means or what metadata is included, which could cause minor ambiguity. Overall adequate for a simple read-only 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?
There are zero parameters, and schema description coverage is 100% (vacuously). The description does not need to explain parameters, but it clearly states the tool's purpose, which is sufficient for an agent to understand what data it will receive.
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 uses a specific verb 'Report' and clearly identifies the resource 'browser state and metadata for MCP-accessible tabs'. It distinguishes from sibling tools like browser_snapshot (which captures page content) and browser_query (which queries the DOM).
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 browser_snapshot or browser_query. The description does not mention context, prerequisites, or exclusions, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds useful behavioral context beyond annotations: the tool returns 'bounded' content (implying size limits), supports two formats, and allows CSS scoping. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and key options. Every word earns its place with no fluff.
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?
Covers the core functionality well, but omits details about default tab behavior and explicit mention of max_chars. However, given the openWorldHint and output schema presence, the description combined with schema is largely sufficient.
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 provides descriptions for all four parameters, so the description's additional mention of format and CSS selector adds some meaning but does not significantly improve understanding beyond the schema. Baseline of 3 is appropriate.
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 verb 'Return' and the resource 'bounded visible text or outer HTML', with optional scoping via CSS selector. This distinguishes it from siblings like browser_query, browser_status, and scraper_* tools, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like browser_query or scraper tools. The description does not provide context about when it is appropriate to use or when to avoid it.
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?
Annotations already declare readOnlyHint=true, so the description's 'List metadata' is consistent but adds no extra behavioral context such as authentication needs, rate limits, or response structure. With annotations covering the safety profile, the description provides minimal additional value.
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 no extraneous words. Perfectly front-loaded: verb + resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an existing output schema, the description is nearly complete. Minor gap: it could state explicitly that it returns all saved scrapers or confirm no pagination, but the current text is sufficient for understanding.
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?
There are zero parameters, and schema coverage is trivially 100%. The description does not need to add parameter-level meaning; baseline 4 applies per guidelines. The description confirms the action scope without redundant detail.
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 uses specific verb 'List' and resource 'metadata for saved scrapers', clearly distinguishing from sibling tools like scraper_get (which retrieves a specific scraper) and scraper_run (which executes a scraper). The 'metadata' qualifier sets accurate scope.
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 scraper_get or scraper_save. No context about prerequisites, pagination, or typical use cases is provided, leaving the agent uninformed about decision boundaries.
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?
The description adds value beyond annotations: it states tab reuse behavior and mentions the new_tab parameter's effect. Annotations already indicate destructiveHint=true and openWorldHint=true, so the agent knows this modifies state. The description doesn't contradict annotations. However, it could clarify that opening a URL may replace the current page in the active tab.
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 sentence that conveys the core behavior efficiently. It could be split for clarity but is not wasteful. No fluff.
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 an output schema exists (so return values are documented), annotations cover mutation and open-world hints, the description is sufficient for a navigation tool. It covers the main behavioral nuance (tab reuse), though could mention the browser may close existing tabs if headless changes mode.
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?
With 67% schema description coverage, the description adds minimal meaning beyond the schema. It explains the new_tab parameter's role but doesn't elaborate on url (already clear from schema) or headless (which has detailed schema descriptions). Baseline 3 is appropriate.
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 opens or navigates an MCP tab, specifying it reuses the active tab unless new_tab is true. This distinguishes it from siblings like browser_status or browser_close.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use new_tab (true for a new tab), but does not explicitly guide when to use this tool versus alternatives like scraper tools for page content extraction, or browser_status for checking state. No when-not-to-use guidance is provided.
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?
Annotations already indicate readOnlyHint=true, so the description's disclosure of returning source and metadata adds modest value. It does not, however, describe error behavior (e.g., if the scraper doesn't exist) or any side effects. Given the tool's simplicity and the annotation coverage, the description meets the minimum bar but does not exceed it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word is necessary; there is no redundancy or irrelevant information. It is perfectly sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one required parameter, existing output schema, and annotations providing safety profile), the description is complete. It states what the tool returns (source and metadata), and the output schema covers the return structure. No additional information is needed.
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% (the only parameter 'name' has a description). The tool description adds no additional meaning about the parameter beyond what the schema already provides. Therefore, it meets the baseline of 3.
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 uses a specific verb 'Return' and identifies the resource as 'a saved scraper's source and metadata.' This clearly distinguishes it from siblings like 'scraper_list' (lists scrapers) and 'scraper_run' (executes a scraper), making the purpose unambiguous.
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?
No explicit guidance on when to use this tool versus alternatives. While it's implied that you would use this to retrieve a specific scraper's details, there is no mention of when to avoid it (e.g., if you only need the name, use scraper_list) or prerequisites. The context is clear enough for a simple tool, but the lack of explicit guidance leaves room for error.
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?
The description aligns with annotations (readOnlyHint=true, openWorldHint=true) by stating it 'returns' data, implying no mutation. It adds value by specifying that only 'safe attributes' are returned, which is behavioral information beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence that communicates the essential purpose immediately. No wasted words, front-loaded with the action and outcome. Ideal conciseness for a straightforward tool.
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?
The description covers the core functionality adequately. With annotations covering read-only and open-world behavior, and an output schema presumably detailing the return structure, the description does not need to elaborate further. It could briefly mention that results are returned as a list or array, but this is a minor gap.
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 high (67%, all parameters have descriptions in schema). The tool description adds no new parameter-specific semantics beyond what the schema provides. It restates the overall purpose but does not elaborate on how 'limit' or 'tab_id' affect behavior.
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 verb 'Return', the resource 'text and safe attributes', and the condition 'matching a CSS selector'. This differentiates browser_query from siblings like browser_snapshot (which returns the full page) and scraper tools (which are for more targeted scraping).
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 does not provide explicit guidance on when to use this tool versus alternatives. It assumes CSS selector knowledge and does not mention when to prefer browser_query over browser_snapshot or scraper_get. Usage context is implied by the tool name but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveness. The description adds 'validate' and 'atomically', disclosing safety guarantees beyond the annotation. Missing are details on conflict behavior when expected_revision mismatches.
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 of 8 words, front-loading the core action. Every word is meaningful with no fluff.
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 presence of an output schema and well-documented parameters, the description is mostly complete but could be strengthened by mentioning what happens on validation failure or revision mismatch.
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?
With schema description coverage at 67% (and all parameters having informative schema descriptions), the tool description adds little parameter-specific meaning beyond the atomic/validation context. Baseline 3 is appropriate.
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 uses a specific verb 'save' with 'Validate and atomically' adding precise semantics. It clearly distinguishes from sibling scraper tools (list, get, run) which serve different purposes.
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 context (saving scrapers for runs), but does not explicitly state when to use this tool versus alternatives, nor provide when-not or prerequisite conditions.
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?
The annotations already declare destructiveHint=true and idempotentHint=true, so the description doesn't need to reiterate that. However, it adds value by specifying the dual behavior: closing the browser entirely or detaching tabs in attach mode. This goes beyond what annotations convey, but the description could mention that open pages or state will be lost if tabs are closed.
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 is concise and front-loaded, clearly stating the action without any filler. Every word earns its place.
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 that the tool has 0 parameters, an output schema exists, and the annotations are rich (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description is mostly sufficient. It explains the core behavior but misses minor behavioral details such as error handling or what happens if no session is active.
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?
There are zero parameters, and the schema description coverage is 100%, so the schema provides all necessary information. The description adds no parameter info, but no compensation is needed. With 0 params, the baseline is 4, and the description is adequate.
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 that the tool closes the browser session or detaches tabs in attach mode, using a specific verb ('Close') and resource ('managed browser' or 'MCP-owned tabs'), and it distinguishes itself from sibling tools like browser_open, browser_snapshot, and browser_query, which perform different operations.
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 implies that the tool should be used when you want to end a browser session or detach tabs, but it does not explicitly state when not to use it or what alternatives (e.g., leaving the browser open) exist. The context of sibling tools is provided but not leveraged in the description.
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:

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

Score Badge

Copy to your README.md:

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

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