Which integrations are available for this server?

Enables fetching and processing GitHub repository content in markdown format, including searching through repository documentation and README files. Provides tools for fetching web pages converted to markdown format via Jina reader, enabling content extraction and analysis from websites. Supports indexing and searching through MDX documentation files from repositories, enabling full-text search across documentation content.

How do I use FastMCP Documentation & Web Scraping Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FastMCP Documentation & Web Scraping Server search the docs for how to add tools" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

FastMCP Documentation & Web Scraping Server

by jcdumlao14

Overview Schema Source Related Servers Discussions Admin

Python

Remote

03-mcp

MCP-Model Context Protocol

This repository contains the homework for the MCP (Model Context Protocol) assignment.

Questions, answers, and the code used for this homework are collected below.

Question 1

Install uv
Initialize the project with uv
Install fastmcp
Find the first sha256 in uv.lock

Answers / actions performed:

uv installed and verified.
Project initialized with uv init.
fastmcp added with uv add fastmcp.
First sha256 in uv.lock is on line 20 for annotated-types:

sdist = { url = "https://files.pythonhosted.org/packages/ee/67/.../annotated_types-0.7.0.tar.gz", hash = "sha256:aff07c09a53a08bc8cfccb9c85b05f1aa9a2a6f23728d790723543408344ce89", size = 16081, upload-time = "2024-05-20T21:33:25.928Z" }

Related MCP server: FastMCP Documentation Search Server

Question 2 — FastMCP Transport

I updated main.py using the FastMCP starter and ran the server. The welcome screen shows the transport:

Answer: STDIO

Question 3 — Scrape Web Tool (Jina reader)

I implemented a tool using the Jina reader (https://r.jina.ai/...) and requests, added test.py to test it against https://github.com/alexeygrigorev/minsearch.

Test result (character count): 31361 → closest provided option: 29184.

Question 4 — Integrate the Tool

I added count_data.py that uses the MCP Jina-reader tool to fetch https://datatalks.club/ and count occurrences of the whole word data (case-insensitive).

Script output: 10 → closest option: 61.

Question 5 — Implement Search (minsearch)

I downloaded the FastMCP repo zip, extracted .md and .mdx files, indexed them with minsearch, and searched for demo.

First file returned for query "demo": examples/testing_demo/README.md.

Question 6 — Search Tool (ungraded)

I added a search_docs MCP tool to main.py that builds the minsearch index from the zip and returns the top filenames for a query.

Files added / modified (full contents)

`main.py`

from fastmcp import FastMCP
import requests
import os
import zipfile
from minsearch import Index

mcp = FastMCP("Demo 🚀")


def fetch_markdown_impl(url: str) -> str:
    """Fetch a web page using Jina reader and return its markdown text.

    The Jina reader endpoint is `https://r.jina.ai/{original_url}`.
    The `url` argument may be a full URL (including scheme) or a hostname/path.
    """
    if not url.startswith("http://") and not url.startswith("https://"):
        url = "https://" + url
    target = "https://r.jina.ai/" + url
    resp = requests.get(target, timeout=15)
    resp.raise_for_status()
    return resp.text


@mcp.tool
def fetch_markdown(url: str) -> str:
    """Return markdown content of a web page via Jina reader."""
    return fetch_markdown_impl(url)


@mcp.tool
def add(a: int, b: int) -> int:
    """Add two numbers"""
    return a + b


# --- minsearch integration for documentation search ---
ZIP_URL = "https://github.com/jlowin/fastmcp/archive/refs/heads/main.zip"
ZIP_NAME = "fastmcp-main.zip"

# simple module-level cache for the built index
_INDEX_CACHE = None


def ensure_zip():
    if os.path.exists(ZIP_NAME):
        return
    resp = requests.get(ZIP_URL, stream=True, timeout=60)
    resp.raise_for_status()
    with open(ZIP_NAME, "wb") as f:
        for chunk in resp.iter_content(1024 * 64):
            if chunk:
                f.write(chunk)


def iter_md_files_from_zip(zip_path):
    with zipfile.ZipFile(zip_path, "r") as z:
        for name in z.namelist():
            lower = name.lower()
            if lower.endswith(".md") or lower.endswith(".mdx"):
                data = z.read(name)
                text = data.decode("utf-8", errors="replace")
                if "/" in name:
                    _, rest = name.split("/", 1)
                else:
                    rest = name
                yield rest, text


def build_index_from_zip():
    docs = []
    ensure_zip()
    for fname in os.listdir('.'):
        if fname.lower().endswith('.zip'):
            for filename, text in iter_md_files_from_zip(fname):
                docs.append({'content': text, 'filename': filename})
    idx = Index(text_fields=["content"], keyword_fields=["filename"])
    idx.fit(docs)
    return idx


def get_index():
    global _INDEX_CACHE
    if _INDEX_CACHE is None:
        _INDEX_CACHE = build_index_from_zip()
    return _INDEX_CACHE


def search_docs_impl(query: str, top_k: int = 5):
    idx = get_index()
    results = idx.search(query, num_results=top_k)
    return results


@mcp.tool
def search_docs(query: str) -> list:
    """Search the documentation index and return top filenames for `query`."""
    results = search_docs_impl(query, top_k=5)
    return [r.get('filename') for r in results]


if __name__ == "__main__":
    mcp.run()

`test.py`

from main import fetch_markdown_impl

if __name__ == "__main__":
    url = "https://github.com/alexeygrigorev/minsearch"
    text = fetch_markdown_impl(url)
    print(len(text))

`test_search.py`

from main import search_docs_impl

if __name__ == '__main__':
    res = search_docs_impl('demo', top_k=5)
    if not res:
        print('No results')
    else:
        print(res[0].get('filename'))

`count_data.py`

from main import fetch_markdown_impl
import re

if __name__ == "__main__":
    url = "https://datatalks.club/"
    text = fetch_markdown_impl(url)
    count = len(re.findall(r"\bdata\b", text, flags=re.IGNORECASE))
    print(count)

`search.py`

import os
import requests
import zipfile
import io
from minsearch import Index

ZIP_URL = "https://github.com/jlowin/fastmcp/archive/refs/heads/main.zip"
ZIP_NAME = "fastmcp-main.zip"


def ensure_zip():
    if os.path.exists(ZIP_NAME):
        print(f"Zip already exists: {ZIP_NAME}")
        return
    print(f"Downloading {ZIP_URL} -> {ZIP_NAME}")
    resp = requests.get(ZIP_URL, stream=True, timeout=60)
    resp.raise_for_status()
    with open(ZIP_NAME, "wb") as f:
        for chunk in resp.iter_content(1024 * 64):
            if chunk:
                f.write(chunk)


def iter_md_files_from_zip(zip_path):
    with zipfile.ZipFile(zip_path, "r") as z:
        for name in z.namelist():
            lower = name.lower()
            if lower.endswith(".md") or lower.endswith(".mdx"):
                # read file
                data = z.read(name)
                text = data.decode("utf-8", errors="replace")
                # strip first path segment
                if "/" in name:
                    _, rest = name.split("/", 1)
                else:
                    rest = name
                yield rest, text


def build_index(docs):
    # docs: list of {'content':..., 'filename':...}
    idx = Index(text_fields=["content"], keyword_fields=["filename"]) 
    idx.fit(docs)
    return idx


def main():
    ensure_zip()
    docs = []
    # iterate all zip files in cwd
    for fname in os.listdir('.'):
        if fname.lower().endswith('.zip'):
            for filename, text in iter_md_files_from_zip(fname):
                docs.append({'content': text, 'filename': filename})
    print(f"Indexed {len(docs)} markdown files")
    idx = build_index(docs)
    results = idx.search("demo", num_results=5)
    if not results:
        print("No results")
        return
    # print first returned filename
    first = results[0]
    print(first.get('filename'))


if __name__ == '__main__':
    main()

Git & Repository

All changes have been committed and pushed to the current repository's main branch.

Available Tools

3 tools

addA

Add two numbers

ParametersJSON Schema

Name	Required	Description	Default
`a`	Yes
`b`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden. 'Add two numbers' accurately and sufficiently communicates a pure arithmetic operation, with no indication of side effects or hidden behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four words long, contains zero filler, and conveys the complete operation. It is front-loaded and every word earns its place.

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

Completeness4/5

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

For a simple two-integer addition tool with an output schema and no siblings, this description is nearly complete. It could mention the return value or pure behavior explicitly, but the output schema and inherent simplicity reduce that need.

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 0%, so the description must compensate. It clarifies that both parameters are numbers to be added, but it does not name them or describe each parameter individually. Since addition is commutative, the lack of role differentiation is a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a precise verb ('add') and a clear resource ('two numbers'), making the tool's purpose immediately obvious. With no sibling tools, there is no ambiguity to resolve.

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 intended use is clear: this tool is for summing two numbers. It does not explicitly discuss when not to use it, but with no sibling tools and only two integer parameters, the context is straightforward.

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

fetch_markdownB

Return markdown content of a web page via Jina reader.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

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 'Return markdown content' and 'via Jina reader', but fails to disclose critical behavioral traits such as rate limits, authentication needs, error handling, or whether it's a read-only operation. This leaves significant gaps for a tool that interacts with external web pages.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words, clearly front-loading the purpose. Every part ('Return markdown content', 'of a web page', 'via Jina reader') adds value, making it appropriately sized and well-structured.

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 (fetching web content), lack of annotations, and an output schema that likely covers return values, the description is minimally complete. It states what the tool does but misses behavioral details and usage context. With an output schema, it doesn't need to explain returns, but other gaps keep it at an adequate 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 input schema has 1 parameter with 0% description coverage, so the description must compensate. It implies the 'url' parameter is for a web page, adding some meaning beyond the bare schema. However, it doesn't specify URL format constraints, validation rules, or examples, providing only basic context. This meets the baseline for low coverage but doesn't fully address the gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Return markdown content') and the resource ('of a web page'), specifying it uses 'Jina reader' as the mechanism. It distinguishes from siblings like 'add' and 'search_docs' by focusing on fetching content rather than adding or searching. However, it doesn't explicitly differentiate from potential similar tools not listed, keeping it at 4 instead of 5.

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 'search_docs' for searching documents or other web-fetching tools. It lacks context on prerequisites (e.g., URL validity), exclusions, or typical use cases, leaving the agent with minimal direction.

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

search_docsB

Search the documentation index and return top filenames for query.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('Search') and return type ('top filenames'), but lacks details on permissions, rate limits, pagination, or error handling. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.

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 action and result. Every word earns its place, with no redundancy or unnecessary details, making it highly concise and well-structured.

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

Completeness3/5

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

Given the tool's moderate complexity (search operation), no annotations, and an output schema present, the description is minimally adequate. It covers the basic purpose but lacks behavioral context and parameter details. The output schema likely handles return values, but the description doesn't provide enough guidance for effective use without additional context.

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 minimal semantics beyond the input schema. It clarifies that the 'query' parameter is used for searching, but with 0% schema description coverage and only one parameter, the baseline is 4. However, it doesn't explain query syntax, format, or examples, so it doesn't fully compensate for the lack of schema documentation, resulting in a score of 3.

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 with a specific verb ('Search') and resource ('documentation index'), and specifies what it returns ('top filenames for query'). It distinguishes itself from sibling tools like 'add' and 'fetch_markdown' by focusing on search functionality. However, it doesn't explicitly differentiate from potential similar search tools beyond the scope of this server.

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 prerequisites, exclusions, or comparisons with sibling tools like 'add' or 'fetch_markdown'. The usage context is implied (searching documentation), but no explicit guidelines are given.

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.

3 tool updatesv1.0.0Jan 3, 2026
- First observedadd
- First observedfetch_markdown
- First observedsearch_docs

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored 2026-04-18 07:45 across 3 tools

Disambiguation5/5

The three tools have clearly distinct purposes: 'add' performs arithmetic addition, 'fetch_markdown' retrieves web content, and 'search_docs' searches documentation. There is no overlap in functionality, making tool selection straightforward.

Naming Consistency2/5

The naming is inconsistent: 'add' uses a simple verb, 'fetch_markdown' uses verb_noun with underscore, and 'search_docs' uses verb_noun with underscore but differs in style from 'fetch_markdown' (e.g., 'fetch' vs. 'search'). This mixed convention lacks a predictable pattern.

Tool Count2/5

With only 3 tools, the set feels thin for a server labeled 'Documentation & Web Scraping Server'. It lacks essential scraping or documentation management operations (e.g., no update, delete, or advanced scraping tools), making the scope underdeveloped.

Completeness2/5

The tool surface is significantly incomplete for the stated domain. It includes basic web fetching and documentation search but misses core documentation CRUD operations (e.g., create, update, delete docs) and comprehensive scraping capabilities, leading to potential agent failures in handling full workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Jina Reader A
io.github.pipeworx-io
Jina AI Reader/Search MCP — turn any URL into clean LLM-ready markdown, plus web search.
Web Scraping Search
382
MESSORA A
dev.messora
Scrape, crawl and search the web for AI agents via MCP.
Web Scraping Browser Automation Search
51
Brainiall Web A
com.brainiall
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Browser Automation Web Scraping
1
agentready-mcp A
io.github.AshutoshRaj97
Query any docs site via MCP. Submit a URL, ask questions, get cited answers.
Documentation Access Search
822

Related MCP Servers

Jina Web Search MCP
Web Scraping Search RAG Systems
hypersniper05
A
license
Not graded
quality
D
maintenance
Enables web content retrieval and semantic search capabilities through the Jina AI API. Provides tools to fetch content from URLs and perform intelligent web searches with natural language queries.
Updated a year ago (2025-08-08 16:00 UTC)
3
MIT
FastMCP Documentation Search
Search Web Scraping Developer Tools
DaniloBlancoMotta
F
license
B
quality
D
maintenance
Enables intelligent search through FastMCP documentation using TF-IDF indexing, along with utility tools for arithmetic operations, text hashing, and web page content extraction via Jina Reader.
Updated 9 months ago (2026-01-07 14:48 UTC)
4
-
mcp-jina-reader
Browser Automation Web Scraping Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Jina AI Reader/Search MCP that turns any URL into clean LLM-ready markdown and provides web search.
Updated 5 days ago (2026-09-18 22:32 UTC)
189 npm
MIT
jina-web-mcp
Web Scraping Search Browser Automation
Brunwo
F
license
Not graded
quality
D
maintenance
Enables web search and webpage scraping using Jina AI services.
Updated a year ago (2025-10-15 10:15 UTC)
-