tbro-mcp
Click on "Install 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., "@tbro-mcpsearch for latest Python release notes"
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.
glyph-mcp
English · Русский
An MCP server that gives Claude two web tools — web_search and web_fetch —
that return plain text instead of HTML. Pages are rendered through the
glyph terminal browser. The point is to
spend fewer tokens on web lookups.
Claude already has web tools, so why this one? Two reasons. glyph reduces a page to just its readable text — no markup, scripts, navigation, or ads — and the result is plain enough that you can grep or trim it before it reaches the model. For a search that works out to roughly 8x fewer tokens.

The trade-off is JavaScript: there isn't any. Single-page apps and dynamic dashboards come back mostly empty, so the tool descriptions tell Claude to fall back to its built-in fetch for those. Static pages, docs, articles, and plain searches are where this earns its keep.
Requirements
glyphon your PATH (or its path inGLYPH_BIN). Install it from the glyph repo withcargo install --locked --path crates/app— it lands in~/.cargo/bin.Node 18 or newer.
Related MCP server: @greatnxy/web-search-mcp
Add it to Claude Code
Published on npm as @k1y0mi/glyph-mcp,
so no build step is needed — npx runs it:
claude mcp add glyph -e GLYPH_BIN=$HOME/.cargo/bin/glyph -- npx -y @k1y0mi/glyph-mcpRestart Claude Code and the two tools appear. To wire it up by hand instead, add
this to .mcp.json (project) or ~/.claude.json:
{
"mcpServers": {
"glyph": {
"command": "npx",
"args": ["-y", "@k1y0mi/glyph-mcp"],
"env": { "GLYPH_BIN": "/Users/you/.cargo/bin/glyph" }
}
}
}Build from source
If you'd rather run it from a checkout instead of npm:
npm install
npm run build
claude mcp add glyph -e GLYPH_BIN=$HOME/.cargo/bin/glyph -- node /absolute/path/to/glyph-mcp/build/index.jsTools
web_search(query, max_chars?)— run a search, get the results as text.web_fetch(url, max_chars?)— pull a single page as text.
max_chars caps the reply (default 8000). GLYPH_BIN points at the binary if
it isn't on your PATH.
Notes
Arguments are passed to glyph via execFile, not a shell, so there's nothing to
inject. Each call times out at 30 seconds. test/smoke.mjs starts the server
over stdio and calls both tools — run it with node test/smoke.mjs after a
build.
License
MIT.
Available Tools
2 toolsweb_fetchВеб-фетч (glyph)A
Загрузить URL как чистый ПЛОСКИЙ ТЕКСТ через браузер glyph (срезает HTML/JS/навигацию/рекламу). Токеноэкономно для статей, документации, блогов и прочих статических/текстовых страниц. НЕ подходит для JS-тяжёлых SPA и динамических дашбордов (вернёт мало) — там используй встроенный веб-фетч.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Абсолютный http(s) URL | |
| max_chars | No | Лимит символов в ответе (по умолчанию 8000) |
TDQS
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 discloses that the tool strips HTML/JS/navigation/ads and returns flat text, and notes limitations for dynamic pages. However, it omits details like redirect handling, timeout, or whether it follows robots.txt, which could affect behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the main action and limitations. Every sentence adds value, with no wasted words. It is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema, and no nested objects, the description explains what it returns (flat text) and its limitations. It is mostly complete but could mention response format or error handling for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both parameters have descriptions in the schema. The tool description adds minimal value beyond restating the default max_chars (8000) and that url must be absolute http(s). No additional semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads URLs as pure flat text, specifies the resource (web pages), and distinguishes it from inappropriate uses (JS-heavy SPA). It explicitly mentions the verb and resource, providing high clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool (static/text pages) and when not to (JS-heavy SPA), even suggesting an alternative ('built-in web fetch'). This provides clear usage guidance beyond general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchВеб-поиск (glyph)A
Поиск в вебе с выдачей ПЛОСКИМ ТЕКСТОМ через браузер glyph (движок Mojeek — без капчи, без JS, без рекламы). Экономит токены: чистый текст, без HTML. Предпочитай для общих/текстовых/документационных запросов. Для real-time, JS-рендеренной или платной выдачи используй встроенный веб-поиск.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Поисковый запрос | |
| max_chars | No | Лимит символов в ответе (по умолчанию 8000) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the engine (Mojeek), output format (plain text, no HTML), and benefits (no captcha, no JS, no ads, token savings). It does not mention rate limits or caching behavior, but the disclosed traits are sufficient for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action and key features. It is efficient and avoids redundancy, though it could be slightly more compact without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and a sibling tool, the description covers most relevant aspects: engine, output format, token efficiency, and usage scenarios. It lacks detail on the exact structure of results but is generally complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds no extra meaning beyond the schema's parameter descriptions, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs web search with flat text output via glyph browser using Mojeek engine. However, it does not explicitly differentiate from its sibling 'web_fetch', which may have overlapping functionality. The purpose is specific but sibling distinction is not provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (general/text/documentation queries) and when not to (real-time, JS-rendered, paid results), and suggests an alternative (built-in web search). This provides clear usage guidance.
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.
2 tool updates
v0.1.0- First observed
web_fetch - First observed
web_search
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one fetches a specific URL as plain text, the other performs a web search. No overlap in functionality.
Both tools follow the 'web_' prefix naming convention, making it easy to identify them as web-related. Consistent pattern.
With only 2 tools, the set is minimal but appropriate for a focused utility that provides web fetching and search. Slightly small but not insufficient.
The set covers the two primary web interaction needs: fetching a specific URL and searching the web. No obvious gaps for the stated purpose of plain-text web content.
Maintenance
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
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Related MCP Servers
- AlicenseAqualityAmaintenanceA self-hosted MCP server providing web search and URL fetching tools, running locally without external API keys or accounts.2539MIT
- FlicenseAqualityCmaintenanceA focused MCP server that provides a single web_search tool for web searches, integrating Tavily and Brave with automatic fallback and key rotation.1-
- FlicenseNot gradedqualityCmaintenanceA read-only MCP server that fetches hard-to-scrape web pages via an anti-detection browser and returns clean, token-efficient markdown. It exposes a single fetch tool that converts pages to markdown without requiring approval prompts.-
- AlicenseAqualityAmaintenanceAn MCP server providing web search, image search, and page scraping tools to LLMs without requiring API keys.312MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/k1y0miiii/glyph-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server