Skip to main content
Glama
matiasngf

MCP Fetch

by matiasngf
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

MCP Fetch

A Model Context Protocol server providing tools for HTTP requests, GraphQL queries, WebSocket connections, and browser automation using Puppeteer.

Configuration

Add this to your MCP settings configuration file:

{
  "mcp-fetch": {
    "type": "stdio",
    "command": "npx",
    "args": [
      "-y",
      "mcp-fetch"
    ]
  }
}

Related MCP server: Browser MCP

Installation

If the puppeteer tool is not working, remember to install the chrome browser

npx puppeteer browsers install chrome

Features

  • HTTP Requests: Perform HTTP requests with full control over method, headers, and body

  • GraphQL Client: Execute queries/mutations and introspect GraphQL schemas

  • WebSocket Management: Connect, send, receive messages, and manage WebSocket connections

  • Browser Automation: Launch browsers, create pages, and execute JavaScript using Puppeteer

  • Comprehensive Docs: AI-ready documentation via get-rules tool

Available Tools

HTTP Requests

fetch

Perform HTTP requests with full control over method, headers, body, and other fetch options.

Parameters:

  • url (string, required): The URL to fetch from

  • method (string, optional): HTTP method (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS). Default: "GET"

  • headers (object, optional): HTTP headers as key-value pairs

  • body (string, optional): Request body for POST, PUT, PATCH, DELETE

  • mode (string, optional): Request mode (cors, no-cors, same-origin)

  • credentials (string, optional): Credentials mode (omit, same-origin, include)

  • cache (string, optional): Cache mode (default, no-store, reload, no-cache, force-cache, only-if-cached)

  • redirect (string, optional): Redirect handling (follow, error, manual). Default: "follow"

  • referrer (string, optional): Referrer URL

  • referrerPolicy (string, optional): Referrer policy

  • timeout (number, optional): Request timeout in milliseconds

  • followRedirects (boolean, optional): Whether to follow redirects. Default: true

Returns:

{
  "status": 200,
  "statusText": "OK",
  "headers": { "content-type": "application/json" },
  "body": "Response body as string",
  "redirected": false,
  "url": "https://api.example.com/data"
}

Example Usage:

// Simple GET request
fetch({ url: "https://api.example.com/users" })

// POST request with JSON body
fetch({
  url: "https://api.example.com/users",
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "John Doe", email: "john@example.com" })
})

// Request with authentication and timeout
fetch({
  url: "https://api.example.com/protected",
  headers: { "Authorization": "Bearer token123" },
  timeout: 5000
})

GraphQL

graphql

Execute GraphQL queries and mutations with support for variables and custom headers.

Parameters:

  • action (object, required): Action to perform with discriminated union:

    • For execution:

      • type: "execute"

      • endpoint (string): GraphQL endpoint URL

      • query (string): GraphQL query or mutation string

      • variables (object, optional): Variables for the query/mutation

      • headers (object, optional): HTTP headers (e.g., authorization)

      • operationName (string, optional): Operation name when query contains multiple operations

      • timeout (number, optional): Request timeout in milliseconds. Default: 30000

    • For introspection:

      • type: "introspect"

      • endpoint (string): GraphQL endpoint URL

      • headers (object, optional): HTTP headers

      • action (string): What to fetch: "full-schema", "list-operations", or "get-type"

      • typeName (string, optional): Type name (required when action is "get-type")

      • useCache (boolean, optional): Use cached schema if available. Default: true

      • cacheTTL (number, optional): Cache time-to-live in milliseconds. Default: 300000

Returns: For execution:

{
  "data": { "user": { "id": "1", "name": "John Doe" } },
  "errors": [],
  "extensions": {}
}

For introspection:

{
  "operations": {
    "queries": ["getUser", "listUsers"],
    "mutations": ["createUser", "updateUser"],
    "subscriptions": []
  }
}

Example Usage:

// Execute a query
graphql({
  action: {
    type: "execute",
    endpoint: "https://api.example.com/graphql",
    query: `
      query GetUser($id: ID!) {
        user(id: $id) {
          id
          name
          email
        }
      }
    `,
    variables: { id: "123" },
    headers: { "Authorization": "Bearer token123" }
  }
})

// Introspect schema
graphql({
  action: {
    type: "introspect",
    endpoint: "https://api.example.com/graphql",
    action: "list-operations"
  }
})

WebSocket

socket

Manage WebSocket connections - connect, send, receive messages, list connections, and close.

Parameters:

  • action (object, required): Action to perform with discriminated union:

    • For listing connections:

      • type: "list"

    • For connecting:

      • type: "connect"

      • url (string): WebSocket URL (ws:// or wss://)

      • protocols (array, optional): WebSocket subprotocols

      • headers (object, optional): HTTP headers for connection

      • autoReconnect (boolean, optional): Auto-reconnect on disconnection. Default: false

      • maxReconnectAttempts (number, optional): Max reconnection attempts. Default: 5

      • reconnectInterval (number, optional): Base reconnect interval in ms. Default: 1000

      • messageHistoryLimit (number, optional): Max messages to keep. Default: 100

    • For sending:

      • type: "send"

      • socketId (string): Socket connection ID

      • message (string or object): Message to send

      • binary (boolean, optional): Send as binary data. Default: false

    • For receiving:

      • type: "receive"

      • socketId (string): Socket connection ID

      • action (string): "get-latest", "get-all", or "get-since"

      • since (string, optional): ISO timestamp for get-since

      • clearAfterRead (boolean, optional): Clear queue after reading. Default: false

    • For closing:

      • type: "close"

      • socketId (string): Socket connection ID

      • code (number, optional): Close code. Default: 1000

      • reason (string, optional): Close reason. Default: "Normal closure"

Returns: For connect:

{
  "socketId": "ws_1234567890_abc123",
  "url": "wss://example.com/socket",
  "readyState": "OPEN",
  "protocol": "",
  "messageCount": 0
}

Example Usage:

// Connect to WebSocket
socket({
  action: {
    type: "connect",
    url: "wss://example.com/socket",
    headers: { "Authorization": "Bearer token123" },
    autoReconnect: true
  }
})

// Send message
socket({
  action: {
    type: "send",
    socketId: "ws_1234567890_abc123",
    message: { type: "subscribe", channel: "updates" }
  }
})

// Receive messages
socket({
  action: {
    type: "receive",
    socketId: "ws_1234567890_abc123",
    action: "get-latest"
  }
})

Browser Automation

puppeteer

Control browsers and pages with Puppeteer - launch/close browsers, open/close pages, execute JavaScript, and more.

Parameters:

  • action (object, required): Action to perform with discriminated union:

    • For listing browsers:

      • type: "list-browsers"

    • For launching browser:

      • type: "launch-browser"

      • headless (boolean, optional): Run in headless mode. Default: false

      • width (number, optional): Window width. Default: 1280

      • height (number, optional): Window height. Default: 720

      • url (string, optional): URL to navigate to after launch

    • For closing browser:

      • type: "close-browser"

      • browserId (string): Browser instance ID

    • For listing pages:

      • type: "list-pages"

    • For opening page:

      • type: "open-page"

      • browserId (string): Browser instance ID

      • url (string, optional): URL to navigate to

    • For closing page:

      • type: "close-page"

      • pageId (string): Page ID

    • For executing code:

      • type: "exec-page"

      • pageId (string): Page ID

      • source (string): JavaScript code to execute (has access to page object)

Returns: For launch-browser:

{
  "success": true,
  "browserId": "browser_1234567890_abc123",
  "message": "Browser launched successfully",
  "config": {
    "headless": false,
    "width": 1280,
    "height": 720
  }
}

Example Usage:

// Launch browser and navigate
puppeteer({
  action: {
    type: "launch-browser",
    headless: false,
    url: "https://example.com"
  }
})

// Execute page automation
puppeteer({
  action: {
    type: "exec-page",
    pageId: "page_id",
    source: `
      await page.goto('https://example.com');
      await page.type('#search', 'hello world');
      await page.click('#submit');
      const title = await page.title();
      return title;
    `
  }
})

Documentation

get-rules

Get comprehensive documentation about this MCP server.

Parameters:

  • random_string (string): Dummy parameter for no-parameter tools

Returns: Complete documentation including schemas, use cases, and best practices.

Use Cases

API Integration

Use the fetch tool to integrate with REST APIs, webhooks, and external services.

// Fetch data from REST API
fetch({
  url: "https://api.github.com/users/octocat",
  headers: { "Accept": "application/vnd.github.v3+json" }
})

// Submit form data
fetch({
  url: "https://api.example.com/submit",
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: "name=John&email=john@example.com"
})

GraphQL Operations

Use the graphql tool for type-safe API queries and schema exploration.

// Query user data
graphql({
  action: {
    type: "execute",
    endpoint: "https://api.example.com/graphql",
    query: `query { users { id name email } }`
  }
})

// Explore available operations
graphql({
  action: {
    type: "introspect",
    endpoint: "https://api.example.com/graphql",
    action: "list-operations"
  }
})

Real-time Communication

Use the socket tool for WebSocket connections, chat applications, and live data feeds.

// Connect to chat server
socket({
  action: {
    type: "connect",
    url: "wss://chat.example.com",
    autoReconnect: true
  }
})

// Subscribe to live updates
socket({
  action: {
    type: "send",
    socketId: "socket_id",
    message: { action: "subscribe", topics: ["news", "alerts"] }
  }
})

Web Automation

Use the puppeteer tool for web scraping, automated testing, and browser interactions.

// Automated form submission
puppeteer({
  action: {
    type: "exec-page",
    pageId: "page_id",
    source: `
      await page.goto('https://forms.example.com');
      await page.type('#name', 'John Doe');
      await page.type('#email', 'john@example.com');
      await page.click('#submit');
      await page.waitForNavigation();
      return page.url();
    `
  }
})

// Screenshot generation
puppeteer({
  action: {
    type: "exec-page",
    pageId: "page_id",
    source: `
      await page.goto('https://example.com');
      const screenshot = await page.screenshot({ encoding: 'base64' });
      return screenshot;
    `
  }
})

Best Practices

General

  1. Always handle errors - Wrap operations in try-catch blocks

  2. Use appropriate timeouts - Set reasonable timeouts for network operations

  3. Clean up resources - Close connections when done (browsers, websockets)

  4. Follow rate limits - Respect API rate limits and add delays if needed

HTTP & GraphQL

  1. Use proper headers - Set Content-Type, Accept, and Authorization headers

  2. Handle redirects appropriately - Consider security implications

  3. Validate responses - Check status codes and response formats

  4. Use HTTPS - Always prefer secure connections

WebSockets

  1. Implement reconnection logic - Use autoReconnect for critical connections

  2. Handle connection states - Check readyState before sending

  3. Process messages efficiently - Clear message queues regularly

  4. Use appropriate close codes - Follow WebSocket close code standards

Browser Automation

  1. Use headless mode for automation - Better performance and resource usage

  2. Wait for elements - Use waitForSelector before interacting

  3. Handle navigation - Use waitForNavigation after clicks

  4. Limit concurrent browsers - Avoid resource exhaustion

  5. Clean up pages and browsers - Prevent memory leaks

Installation

Dependencies are automatically installed when running the server. If you encounter issues:

# For browser automation (Puppeteer)
npx puppeteer browsers install chrome

# For all dependencies
npm install mcp-fetch

Limitations

  • Browser instances and WebSocket connections are stored in memory and lost on restart

  • Each browser instance consumes significant system resources

  • WebSocket message history is limited by messageHistoryLimit

  • GraphQL introspection cache is temporary and cleared on restart

  • File uploads are not directly supported (use base64 encoding in body)

License

MIT

Available Tools

5 tools
fetchB

Perform HTTP requests with full control over method, headers, body, and other fetch options

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to fetch from
methodNoThe HTTP method to use. Defaults to GETGET
headersNoHTTP headers to include in the request as key-value pairs
bodyNoThe request body. Can be a string, JSON, or form data
modeNoThe mode for the request (cors, no-cors, or same-origin)
credentialsNoWhether to include credentials with the request
cacheNoThe cache mode for the request
redirectNoHow to handle redirects. Defaults to followfollow
referrerNoThe referrer to send with the request
referrerPolicyNoThe referrer policy for the request
signalNoAn AbortSignal to abort the request
timeoutNoRequest timeout in milliseconds
followRedirectsNoWhether to follow redirects. Defaults to true

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false, idempotentHint=false, and destructiveHint=false, indicating this is a non-idempotent, non-destructive operation that may have side effects. The description adds context about 'full control' over HTTP aspects, which hints at flexibility but doesn't disclose behavioral traits like rate limits, error handling, or response formats. No contradiction with annotations exists, but the description offers minimal additional behavioral insight beyond what annotations already convey.

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 front-loads the core purpose without unnecessary elaboration. Every word earns its place by summarizing the tool's capabilities succinctly. It avoids redundancy and is appropriately sized for a general-purpose HTTP tool.

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 complexity (13 parameters, no output schema) and rich schema coverage, the description is adequate but incomplete. It covers the 'what' (perform HTTP requests) but lacks context on 'why' or 'how' to use it effectively, such as error handling, response interpretation, or integration with sibling tools. The absence of an output schema means the description should ideally hint at return values, but it doesn't, leaving gaps for the agent.

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 detailed descriptions for all 13 parameters including enums and defaults. The description adds no parameter-specific semantics beyond stating 'full control over method, headers, body, and other fetch options,' which merely echoes the schema's scope. Since the schema comprehensively documents parameters, the baseline score of 3 is appropriate, as the description doesn't enhance understanding of individual parameters.

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: 'Perform HTTP requests with full control over method, headers, body, and other fetch options.' It specifies the verb ('perform HTTP requests') and resource (HTTP endpoints via URL), but doesn't distinguish it from potential sibling tools like 'graphql' or 'socket' that might also perform network requests. The description is accurate but lacks sibling differentiation.

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 to choose 'fetch' over 'graphql' or 'socket' for network operations, nor does it specify prerequisites like authentication requirements or appropriate use cases. The agent must infer usage from the tool name and parameters alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-rulesA
Read-onlyIdempotent

Get use cases and best practices for using the tools in this MCP server

ParametersJSON Schema
NameRequiredDescriptionDefault
rulesYesThe documentation sections to retrieve

TDQS

A3.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds context beyond annotations: it specifies that the tool retrieves 'use cases and best practices,' which clarifies the type of information returned, not just that it's a read operation. Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's safe and repeatable. The description complements this by detailing the content, though it doesn't cover aspects like rate limits or auth needs, which aren't contradicted.

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 tool's purpose without any wasted words. It is front-loaded with the core function, making it easy for an agent to parse quickly. Every part of the sentence earns its place by specifying what is being retrieved.

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 with full schema coverage) and annotations that cover safety and idempotency, the description is adequate but has gaps. It doesn't explain the return values or format, and there's no output schema, so the agent might be uncertain about what 'use cases and best practices' look like structurally. However, for a read-only tool with good annotations, it meets a minimum viable level.

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 does not mention parameters at all, but the input schema has 100% description coverage for its single parameter 'rules,' which is well-documented with an enum of documentation sections. Since schema coverage is high, the baseline score is 3, as the description doesn't need to compensate. It adds no extra semantic meaning beyond what the schema provides.

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: 'Get use cases and best practices for using the tools in this MCP server.' It specifies the verb 'Get' and the resource 'use cases and best practices,' making the function evident. However, it doesn't explicitly differentiate from sibling tools like 'fetch' or 'graphql,' which might also retrieve information but for different purposes, so it misses full 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 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 any context, prerequisites, or exclusions, such as when to prefer this over direct tool usage or other documentation sources. This leaves the agent without explicit usage instructions, relying solely on the tool name and description for inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

graphqlB

Execute GraphQL queries and mutations with support for variables and custom headers

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesThe action to perform with GraphQL

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering basic safety. The description adds that it handles 'queries and mutations' and supports variables/headers, which clarifies it's a general GraphQL client. However, it lacks details on error handling, rate limits, or authentication requirements beyond headers, missing deeper 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 a single, efficient sentence that front-loads the core functionality ('Execute GraphQL queries and mutations') and includes key features. There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.

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 complexity (handling GraphQL queries/mutations and introspection) and lack of output schema, the description is somewhat incomplete. It doesn't explain return values, error formats, or the introspection capability implied by the schema. However, annotations provide basic hints, and the schema covers inputs thoroughly, making it minimally adequate but with gaps for a multi-action tool.

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%, so parameters are well-documented in the schema. The description mentions 'variables and custom headers,' aligning with schema properties but adding no extra semantic meaning. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter 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 tool's purpose: 'Execute GraphQL queries and mutations with support for variables and custom headers.' It specifies the verb ('execute'), resource ('GraphQL queries and mutations'), and key features. However, it doesn't distinguish this from sibling tools like 'fetch' which might also make HTTP requests, leaving room for improvement.

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 like 'fetch' for general HTTP requests or other siblings. It mentions support for variables and headers but doesn't clarify specific use cases, prerequisites, or exclusions for GraphQL versus REST APIs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

puppeteerB

Control browsers and pages with Puppeteer - launch/close browsers, open/close pages, execute JavaScript, take screenshots, and more

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesThe action to perform with Puppeteer

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide basic hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false), but the description adds context about browser/page lifecycle management and JavaScript execution. However, it lacks details on error handling, performance implications, resource cleanup, or authentication needs. No contradiction with annotations exists, as 'control' aligns with non-read-only operations.

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 front-loads the core purpose ('Control browsers and pages with Puppeteer') followed by a concise list of key actions. Every word earns its place, with no redundancy or unnecessary elaboration, making it easy for an agent to quickly grasp the tool's scope.

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 complex input schema (multiple action types) and lack of output schema, the description provides a high-level overview but lacks details on return values, error conditions, or advanced usage patterns. It's adequate for basic orientation but incomplete for guiding an agent through the full range of actions and their outcomes.

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 detailed parameter documentation in the schema itself. The description mentions general action categories but adds no specific parameter semantics beyond what's in the schema. This meets the baseline for high schema coverage, where the description doesn't need to compensate but also doesn't enhance parameter 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 tool's purpose as 'Control browsers and pages with Puppeteer' and lists specific actions (launch/close browsers, open/close pages, execute JavaScript, take screenshots). It distinguishes from sibling tools like fetch, get-rules, graphql, and socket by focusing on browser automation. However, it doesn't explicitly differentiate from potential similar browser tools that might exist elsewhere.

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 lists actions, it doesn't specify prerequisites (e.g., need to launch a browser before opening pages), sequencing requirements, or when to choose Puppeteer over other tools like fetch for web interactions. The agent must infer usage from the action list alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

socketB

Manage WebSocket connections - connect, send, receive messages, list connections, and close

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesThe action to perform on WebSocket connections

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide basic hints (not read-only, not idempotent, not destructive), but the description adds useful context about the five specific actions available. However, it doesn't disclose important behavioral traits like connection persistence, error handling, authentication requirements, or rate limits that would help an agent use it effectively.

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 - a single sentence listing all five actions. Every word earns its place with zero waste. It's front-loaded with the core purpose and efficiently enumerates capabilities without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-action tool with comprehensive schema coverage but no output schema, the description provides minimal but adequate coverage. It identifies the scope of operations but lacks details about return values, error conditions, or practical usage patterns that would help an agent understand what to expect from each action.

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 100% schema description coverage, the input schema comprehensively documents all parameters. The description mentions the five action types but adds no additional semantic meaning beyond what's already in the schema descriptions. This meets the baseline for high schema coverage.

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 as managing WebSocket connections with specific actions (connect, send, receive, list, close). It uses specific verbs and identifies the resource (WebSocket connections), but doesn't differentiate from sibling tools like 'fetch' or 'graphql' which handle different protocols.

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 WebSocket connections are appropriate compared to HTTP requests (fetch) or GraphQL queries, nor does it specify prerequisites or exclusions for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 12 tool updatesv1.0.0
    • Removedclose-browser
    • Removedclose-page
    • Removedcreate-page
    • Removedexec-page
    • Addedfetch
    • Changedget-rules2 fields changed
      • addedInput schema / properties / rules
        Added value: +{
+  "description": "The documentation sections to retrieve",
+  "items": {
+    "enum": [
+      "quickStart",
+      "commonErrors",
+      "interactions",
+      "tools",
+      "workflow",
+      "performanceOptimization",
+      "gamingTips",
+      "debuggingWithPuppeteer"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedInput schema / required
        Added value: +[
+  "rules"
+]
    • Addedgraphql
    • Removedlaunch-browser
    • Removedlist-browsers
    • Removedlist-pages
    • Addedpuppeteer
    • Addedsocket
  2. 8 tool updates
    • First observedclose-browser
    • First observedclose-page
    • First observedcreate-page
    • First observedexec-page
    • First observedget-rules
    • First observedlaunch-browser
    • First observedlist-browsers
    • First observedlist-pages
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: fetch for HTTP requests, get-rules for documentation, graphql for GraphQL operations, puppeteer for browser automation, and socket for WebSocket management. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency3/5

The naming conventions are mixed: fetch, graphql, and socket use lowercase single words, while get-rules uses kebab-case and puppeteer is a proper noun. This inconsistency reduces predictability, though the names remain readable and descriptive of their functions.

Tool Count5/5

With 5 tools, the server is well-scoped for a utility-focused domain like web and browser operations. Each tool serves a distinct and essential purpose, such as HTTP requests, GraphQL, browser control, WebSocket management, and documentation, making the count appropriate and efficient.

Completeness4/5

The tool set covers key areas for web and browser automation, including HTTP, GraphQL, WebSockets, and Puppeteer, with a documentation tool for guidance. Minor gaps might exist, such as advanced caching or proxy handling, but core workflows are well-supported without dead ends.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • dev-chrome-monitor

    2sslgetlool
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables interaction with Chromium browser instances through Puppeteer for inspecting dev builds, capturing screenshots, and automating UI interactions. Features permission-gated tools for secure browser navigation, DOM manipulation, and JavaScript evaluation.
    10
    1
    MIT

  • Browser MCP

    blink-new
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server for browser automation using Puppeteer that enables AI assistants to navigate web pages, interact with UI elements, and capture screenshots. It supports comprehensive web tasks including form filling, content extraction, and executing custom JavaScript within the browser context.
    1
    MIT

  • Playwright MCP

    Patrick-Ogbue
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables browser automation and web scraping by exposing Playwright tools through an HTTP-based MCP server. Users can navigate pages, interact with web elements, capture screenshots, and extract structured content using a persistent Chromium instance.
    MIT

  • puppeteer

    silvino-av
    F
    license
    Not graded
    quality
    D
    maintenance
    MCP server for headless browser automation using Puppeteer, enabling AI to navigate, click, fill forms, take screenshots, and execute JavaScript on web pages.
    -

Appeared in Searches

Latest Blog Posts

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/matiasngf/mcp-fetch'

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