Skip to main content
Glama

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.

tokens per search

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

  • glyph on your PATH (or its path in GLYPH_BIN). Install it from the glyph repo with cargo 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-mcp

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

Tools

  • 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 tools
web_fetchВеб-фетч (glyph)A

Загрузить URL как чистый ПЛОСКИЙ ТЕКСТ через браузер glyph (срезает HTML/JS/навигацию/рекламу). Токеноэкономно для статей, документации, блогов и прочих статических/текстовых страниц. НЕ подходит для JS-тяжёлых SPA и динамических дашбордов (вернёт мало) — там используй встроенный веб-фетч.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesАбсолютный http(s) URL
max_charsNoЛимит символов в ответе (по умолчанию 8000)

TDQS

A4.4/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 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Tool Schema Changelog

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

  1. 2 tool updatesv0.1.0
    • First observedweb_fetch
    • First observedweb_search

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow the 'web_' prefix naming convention, making it easy to identify them as web-related. Consistent pattern.

Tool Count4/5

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.

Completeness5/5

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

ActivityInactive
ResponsivenessNo issues

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

  • A
    license
    A
    quality
    A
    maintenance
    A self-hosted MCP server providing web search and URL fetching tools, running locally without external API keys or accounts.
    2
    539
    MIT
  • F
    license
    A
    quality
    C
    maintenance
    A focused MCP server that provides a single web_search tool for web searches, integrating Tavily and Brave with automatic fallback and key rotation.
    1
    -
  • F
    license
    Not graded
    quality
    C
    maintenance
    A 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.
    -

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/k1y0miiii/glyph-mcp'

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