MCP Fetch

by matiasngf

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.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.
Average 3.3/5 across 5 of 5 tools scored.
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

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.
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.
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.
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.
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.

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:

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

Score Badge

Copy to your README.md:

[![mcp-fetch MCP server](https://glama.ai/mcp/servers/matiasngf/mcp-fetch/badges/score.svg)](https://glama.ai/mcp/servers/matiasngf/mcp-fetch)

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

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