A
licenseB
qualityD
maintenanceFacilitates integration of Brave Search functionalities with AI assistants through the Model Context Protocol, enabling web and local searches using the Brave Search API.
2
15
MIT
CubicJ MCP Search
Officialby cubicj
Includes a site extractor to fetch and extract readable content from Bluesky URLs as markdown.
Provides relevance-ranked web search via the Brave LLM Context API, returning page excerpts per source URL with controls for result count, token budget, freshness, country, and search language.
Includes a site extractor for fetching GitHub content as markdown; optionally uses a GitHub token for higher API rate limits.
Includes a site extractor to fetch and extract readable content from Naver Blog URLs as markdown.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@CubicJ MCP Searchsearch for the latest AI research papers"
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.
CubicJ MCP Search
Stateless Streamable HTTP MCP server with two read-only tools for LLM clients:
Tool | What it does |
| Brave LLM Context search: relevance-ranked page excerpts per source URL, with |
| Readable extraction of one URL as markdown (Defuddle), with site extractors for DCInside, Naver Blog, Bluesky, GitHub, Clien, Ruliweb, FMKorea, and namu.wiki, PDF text, raw mode, and pagination |
It replaces the separate brave-search-api-mcp, dc-mcp-search, and defuddle-fetch-mcp servers with one deployment sized by measured usage.
Requirements
Node.js 24, npm 11
BRAVE_API_KEY(Brave Search API, Search plan) forweb_searchOptional
GITHUB_TOKENfor higher GitHub API limits infetch
Related MCP server: Brave Search MCP Server
Run
npm ci
npm run build
BRAVE_API_KEY=... node dist/index.js --transport http --port 8006
curl -s http://127.0.0.1:8006/healthWithout --transport http (or --port) the server speaks MCP over stdio. PORT sets the HTTP port when --port is absent; .env.example lists the variables for a systemd EnvironmentFile.
The HTTP endpoint is POST /mcp. Requests carrying a browser Origin header are rejected, bodies are capped at 1 MiB, and one log line per request goes to stderr. Put authentication in front of it (a reverse proxy or an OAuth gateway); the server has none.
Development
npm test # builds, then runs Vitest offline
npm run typecheck
npm run lint # Biome
npm run smoke -- "query" # live web_search, needs BRAVE_API_KEY exportedLicense
MIT
Available Tools
2 toolsfetchFetch URLARead-onlyIdempotent
Fetch one URL and return its readable content as markdown with a title and metadata. Use it to read a page in full after web_search, or any URL the user gives: articles, docs, forums, news. Site-specific extractors return post body plus comments for gall.dcinside.com, Clien, Ruliweb, and FMKorea; body only for blog.naver.com and namu.wiki; threads with replies and profiles with recent posts for bsky.app; raw content or REST data for github.com files, repos, issues, pull requests, and gists. Non-HTML text (JSON, XML, RSS, plain text) is returned as-is; PDFs as page-separated text with page_count; image-only PDFs return a notice; other binaries are errors. raw=true skips extraction and returns the decoded response text. Long content is paginated: content is sliced from start_index (default 0) for max_length characters (default 50000); to continue, call again with start_index advanced by the previous max_length and stop when start_index + max_length >= total_length. Bot-protection pages return an error; empty pages that need JavaScript or a login return a notice.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Get raw content without markdown conversion | |
| url | Yes | URL to fetch | |
| max_length | No | Maximum number of characters to return | |
| start_index | No | Start content from this character index |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| mode | Yes | |
| title | Yes | |
| content | Yes | |
| metadata | No | |
| extractor | No | |
| max_length | Yes | |
| start_index | Yes | |
| total_length | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnly, idempotent, etc.), but the description adds rich behavioral detail beyond annotations: site-specific extractors for gall.dcinside.com, Clien, Ruliweb, FMKorea, blog.naver.com, namu.wiki, bsky.app, and github.com; handling of non-HTML, PDFs, and binaries; pagination mechanics with start_index and max_length; and error/notice behavior for bot protection and JavaScript-only pages. This is exemplary transparency.
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?
Despite its length, the description is densely packed with essential information and front-loaded with the core action. Every sentence earns its place by covering extraction nuances, content types, pagination, and error cases. There is no filler or redundancy.
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?
An output schema exists, so return value details are not needed. The description thoroughly covers the tool's behavior, content handling, pagination, and failure modes. Given the complexity of a web-fetching tool with many site-specific extractors, the description is complete enough for an agent to invoke it correctly.
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 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains that raw=true skips extraction and returns decoded response text, and it details the pagination workflow using start_index and max_length with a concrete continuation rule. This goes beyond the schema's brief parameter descriptions.
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 begins with a specific verb and resource: 'Fetch one URL and return its readable content as markdown with a title and metadata.' It clearly distinguishes this tool from the sibling web_search by positioning it as the follow-up for reading full pages. An agent can immediately tell what the tool does and when to choose it over web_search.
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?
It explicitly says to use it after web_search or for any URL the user gives, naming the alternative (web_search) and the condition. However, it does not state when NOT to use fetch (e.g., avoid for binary content or when raw data is needed elsewhere). The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchWeb SearchARead-onlyIdempotent
Search the web and get relevance-ranked page excerpts for each result, ready to read and cite. First tool for any research, fact lookup, or URL discovery; most questions need one call and no follow-up fetch. Operators use a colon: site:example.com, "exact phrase", -excluded. count sets how many source URLs (1-20, default 8); max_tokens caps the total excerpt size (1024-32768, default 8192); freshness limits results by date (pd, pw, pm, py, or YYYY-MM-DDtoYYYY-MM-DD); country and search_lang scope the market. Returns JSON: query, result_count, results[{title, url, site, age, snippets[]}].
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of source URLs to return | |
| query | Yes | Search query; operators use a colon (site:example.com) | |
| country | No | Two-letter country code, e.g. KR, US | |
| freshness | No | Date filter: pd (day), pw (week), pm (month), py (year), or YYYY-MM-DDtoYYYY-MM-DD | |
| max_tokens | No | Cap on total excerpt tokens | |
| search_lang | No | Search language code, e.g. ko, en |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| result_count | Yes |
TDQS
A4.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive, so the safety profile is covered. The description adds useful context about output shape ('ready to read and cite') and expected call behavior, but it does not disclose rate limits, authentication needs, or other deeper operational traits.
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 front-loads purpose and usage, then moves into parameter and return details without excessive padding. It is dense but each sentence adds operational value, though it could be slightly more structured for scanning.
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?
For a six-parameter search tool with an output schema already present, the description is complete: it covers purpose, usage, parameter behavior, and return shape. An agent has everything needed to select and invoke it correctly.
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 coverage is 100%, so the baseline is 3, but the description adds real value by explaining query operator syntax (site:, exact phrase, -excluded), parameter defaults and ranges for count and max_tokens, and the meaning of freshness and market-scoping 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 states a specific verb and resource: 'Search the web and get relevance-ranked page excerpts for each result, ready to read and cite.' It also distinguishes the tool from its sibling by saying most questions need no follow-up fetch, making the boundary with `fetch` clear.
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?
It explicitly frames itself as the 'First tool for any research, fact lookup, or URL discovery' and states when a follow-up fetch is unnecessary ('most questions need one call and no follow-up fetch'). This gives both when-to-use and when-not-to-use guidance, with the alternative implied by the sibling `fetch`.
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.
2 tool updates
v0.1.0- First observed
fetch - First observed
web_search
TDQS
A4.4/5.0
Scored across 2 tools
Disambiguation5/5
web_search handles discovery with ranked excerpts, while fetch retrieves and extracts full content from a single URL. Their roles are clearly distinct and the descriptions reinforce when to use each.
Naming Consistency3/5
fetch is a bare verb and web_search is a compound noun/verb form, so there is no shared verb_noun pattern. Both are readable and common, but the conventions are mixed.
Tool Count4/5
Two tools cover the core search-and-retrieve workflow without redundancy, but the count is slightly below the typical 3–15 range. Each tool earns its place for the server's narrow purpose.
Completeness4/5
The surface covers discovery via web_search and retrieval via fetch, including pagination and many site-specific extractors. Minor gaps like batch fetching or search pagination exist, but there are no major dead ends.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Turn any URL into clean Markdown and structured data. Scrape, crawl, search and extract.
Fetch pages as markdown, search web and news, extract structured data. For AI agents.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables web and local business searches through the Brave Search API. Provides general web search with pagination and filtering, plus local business search with automatic fallback to web results.-
- AlicenseNot gradedqualityDmaintenanceIntegrates the Brave Search API into AI assistants to enable web and local business search capabilities. This allows models to perform real-time information retrieval and locate places using the Model Context Protocol.1MIT
- AlicenseAqualityDmaintenanceProvides web access capabilities for LLMs including search, fetching, content extraction, PDF reading, image viewing, and screenshots.346MIT