screaming-frog-mcp

by marykovziridze

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.2.0
Disambiguation5/5
Each tool has a distinct purpose with no overlap: crawl_site initiates crawls, crawl_status checks progress, delete_crawl removes data, export_crawl exports data, list_crawls lists saved crawls, read_crawl_data reads exported data, sf_check verifies installation, and storage_summary shows disk usage. The descriptions clearly differentiate their functions, preventing agent misselection.
Naming Consistency5/5
All tools follow a consistent snake_case naming pattern with clear verb_noun structures (e.g., crawl_site, list_crawls, read_crawl_data). The naming is predictable and readable throughout the set, with no deviations in style or convention.
Tool Count5/5
With 8 tools, this server is well-scoped for managing Screaming Frog crawls. Each tool earns its place by covering essential operations like starting, monitoring, exporting, and managing crawls, without being overly sparse or bloated. The count aligns perfectly with the domain's workflow needs.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for Screaming Frog crawls: create (crawl_site), read (export_crawl, read_crawl_data), update (implied via crawl_status monitoring), delete (delete_crawl), and management (list_crawls, storage_summary, sf_check). There are no obvious gaps, and agents can handle all core tasks without dead ends.
Average 4.2/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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. It mentions checking status but does not disclose behavioral traits such as whether this is a read-only operation, potential error conditions (e.g., invalid crawl_id), response format, or rate limits. The description is minimal and lacks essential context for safe and effective use.
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 appropriately sized and front-loaded, with the purpose stated clearly in the first sentence. The additional 'Args' section is concise and relevant. There is no wasted text, making it efficient, though it could be slightly more structured for better readability.
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 low complexity (one parameter) and the presence of an output schema (which handles return values), the description is somewhat complete but lacks depth. It covers the basic purpose and parameter source but misses behavioral details and usage guidelines, making it adequate but with clear gaps for informed tool selection.
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 adds meaning by explaining that 'crawl_id' is 'returned by crawl_site,' which clarifies its source and purpose beyond the schema's basic title ('Crawl Id'). However, with 0% schema description coverage and only one parameter, the description compensates somewhat but does not fully detail constraints or examples, meeting the baseline for minimal param info.
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: 'Check the status of a running or completed crawl.' It specifies the verb ('check') and resource ('crawl'), but does not explicitly differentiate it from siblings like 'list_crawls' or 'read_crawl_data', which might also provide status-related information. This clarity is sufficient but lacks sibling distinction.
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 by referencing 'crawl_id returned by crawl_site,' suggesting it should be used after initiating a crawl. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'list_crawls' for broader status checks or 'read_crawl_data' for detailed results. The context is implied but not comprehensive.
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 provided, the description carries the full burden. It discloses the tool's behavior by stating it returns total size and per-crawl breakdown, which is useful. However, it doesn't cover other traits like performance, error handling, or data freshness, leaving gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and efficiently structured in two sentences: the first states the action and resource, the second details the return values. Every sentence earns its place with no wasted words, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is largely complete. It explains the purpose and output semantics well. However, with no annotations, it could benefit from more behavioral details like update frequency or data scope, slightly reducing completeness.
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 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on output semantics, explaining what data is returned (total size and per-crawl breakdown), which adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Show disk usage') and resources ('Screaming Frog's internal crawl storage', 'ProjectInstanceData'). It distinguishes from siblings by focusing on storage metrics rather than crawl operations like crawl_site or delete_crawl.
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 is provided on when to use this tool versus alternatives. While the description implies usage for monitoring storage, it doesn't specify scenarios (e.g., before starting a new crawl) or exclusions (e.g., not for real-time data). The context is clear but lacks actionable guidelines.
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 provided, the description carries the full burden. It discloses that the tool returns specific data (crawl names, Database IDs, sizes) and mentions the Database ID's use with other tools, but does not cover behavioral aspects like rate limits, authentication needs, pagination, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by output details and usage guidance in two additional sentences. Every sentence adds value without redundancy, making it efficiently structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations, but has an output schema), the description is mostly complete. It explains what the tool does and how to use its output, but lacks details on behavioral traits like performance or limitations. The output schema likely covers return values, reducing the need for description here.
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 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and output usage. A baseline of 4 is applied for zero parameters.
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 specific action ('List all crawls'), resource ('saved in Screaming Frog's internal database'), and scope ('all crawls'). It distinguishes from siblings by focusing on listing rather than crawling, deleting, exporting, or reading data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to get crawl names, Database IDs, and sizes, and explicitly states to use the Database ID with export_crawl or delete_crawl. However, it does not specify when NOT to use it or explicitly compare it to alternatives like storage_summary.
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 provided, the description carries full burden. It discloses key behavioral traits: the crawl runs in the background, returns a crawl_id for tracking, and requires polling via crawl_status. However, it doesn't mention potential side effects (resource consumption), authentication needs, rate limits, or error conditions that would be important for a background job tool.
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?
Perfectly structured with clear sections (description, Args, Returns, Note), zero wasted sentences, and front-loaded critical information. Every sentence earns its place by providing essential operational details or practical guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (background job with 3 parameters), no annotations, but with output schema (implied by 'Returns' section), the description is mostly complete. It covers purpose, parameters, return value, and operational flow, but lacks information about error handling, performance characteristics, or integration with other tools beyond crawl_status.
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: url (URL to crawl with example), config_file (optional .seospiderconfig for settings/limits with practical guidance), and label (optional identifier with example). It adds meaningful context beyond basic schema types, especially for config_file 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 specific action ('Start a background Screaming Frog crawl') and resource ('saves to SF's internal database'), distinguishing it from siblings like crawl_status (check progress) or export_crawl (export data). It uses precise technical terminology that identifies the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to initiate a crawl) and references crawl_status for checking progress, but doesn't explicitly contrast when to use this versus alternatives like list_crawls or delete_crawl. The note about config_file usage offers practical guidance but not sibling differentiation.
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 provided, the description carries full burden. It discloses that this is an export operation (implying data retrieval rather than modification) and mentions the output format (CSV files) and next steps (using read_crawl_data). However, it doesn't mention potential side effects like whether this consumes resources, has rate limits, requires specific permissions, or how long exports might take.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence adds value: the first states the core function, parameter explanations provide necessary details without redundancy, and the return statement clarifies next steps. 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 the tool's complexity (export operation with multiple parameters) and no annotations, the description does well by explaining parameters and mentioning the output schema's content (export_id and CSV files). However, it could better address behavioral aspects like performance expectations or error conditions. The presence of an output schema reduces the need to detail return values.
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 compensates fully by explaining all 4 parameters. It provides specific examples for db_id, export_tabs, bulk_export, and save_report, including default values for export_tabs and clarifying that db_id comes from list_crawls. This adds crucial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Load a saved crawl... and export data as CSV files') and distinguishes it from siblings like list_crawls (which lists crawls) and read_crawl_data (which reads exported files). It explicitly names the resource ('saved crawl from SF's database') and output format ('CSV files'), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by mentioning that db_id comes from 'list_crawls' and that exported files should be read with 'read_crawl_data'. However, it doesn't explicitly state when NOT to use this tool versus alternatives like directly accessing crawl data through other means, or when to use it versus delete_crawl for cleanup operations.
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 provided, the description carries full burden. It discloses the tool's behavior (verification operation, returns version/license info) but doesn't mention potential errors if CLI is inaccessible, authentication requirements, or rate limits. The behavioral disclosure is adequate but not comprehensive.
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?
Two concise sentences with zero waste. First sentence states the verification purpose, second describes the return values. Perfectly front-loaded and appropriately sized for this simple 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 simplicity (0 parameters, no annotations, but has output schema), the description is complete enough. It explains what the tool does and what it returns, and with an output schema present, the description doesn't need to detail return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's core functionality without unnecessary parameter explanations.
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 with specific verbs ('verify', 'returns') and resources ('Screaming Frog SEO Spider', 'CLI', 'version info', 'license status'). It distinguishes from siblings by focusing on installation/accessibility verification rather than crawling 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 usage context - verifying CLI accessibility before performing crawls - but doesn't explicitly state when to use this tool versus alternatives. No exclusions or prerequisites are mentioned, though the context is reasonably clear.
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 provided, the description carries the full burden. It discloses that the tool reads data (non-destructive) and returns formatted text, but lacks details on permissions, rate limits, error handling, or data format specifics. It adds basic context but misses key behavioral traits for a read operation with filtering capabilities.
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 and front-loaded: purpose first, then Args and Returns sections. Every sentence earns its place—no fluff. The bullet-point style for parameters is efficient, and the text is appropriately sized for the tool's complexity.
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 6 parameters, 0% schema coverage, no annotations, but an output schema exists, the description does well. It explains the tool's purpose, usage context, and parameter semantics thoroughly. The output schema handles return values, so the description doesn't need to detail them. It could improve by addressing error cases or authentication needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 6 parameters: export_id links to export_crawl, file specifies the CSV filename, limit/offset handle pagination, and filter_column/filter_value enable case-insensitive substring filtering. This adds substantial meaning beyond the bare schema, though it doesn't cover all edge cases.
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: 'Read CSV data from an export.' It specifies the verb ('Read'), resource ('CSV data'), and source ('from an export'), distinguishing it from siblings like crawl_site or export_crawl. The mention of 'Use after export_crawl' further clarifies its role in the workflow.
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 provides usage guidance: 'Use after export_crawl.' This indicates a prerequisite and timing context, distinguishing it from alternatives like list_crawls or crawl_status. It effectively tells the agent when to invoke this tool in relation to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers excellent behavioral disclosure. It explicitly warns about permanent deletion ('This permanently deletes the crawl data. It cannot be undone.'), clearly indicating destructive behavior. This goes beyond what minimal schema would convey about this high-risk operation.
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 perfectly structured and front-loaded: purpose statement first, then parameter guidance, then critical warning. Every sentence earns its place - the first explains what and why, the second explains parameter sourcing, the third provides essential safety warning. Zero wasted words.
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 this is a destructive operation with no annotations, the description provides complete context: clear purpose, parameter guidance, and explicit permanent deletion warning. The existence of an output schema means return values don't need explanation. For a high-risk tool with 1 parameter, this covers all essential information an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that db_id comes from 'list_crawls', providing crucial context about parameter sourcing that isn't in the schema. For a single parameter with no schema documentation, this fully compensates and adds practical guidance.
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 specific action ('Delete a crawl') and resource ('from Screaming Frog's internal database') with explicit purpose ('to free disk space'). It distinguishes from siblings like list_crawls (read-only) and export_crawl (data extraction) by focusing on permanent removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to free disk space) and references list_crawls as the source for the required db_id parameter. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among siblings like export_crawl for data preservation before deletion.
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:

[![screaming-frog-mcp MCP server](https://glama.ai/mcp/servers/marykovziridze/screaming-frog-mcp/badges/card.svg)](https://glama.ai/mcp/servers/marykovziridze/screaming-frog-mcp)

Score Badge

Copy to your README.md:

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

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