Read any public web page as clean text, and files of public GitHub repositories. Free, no key.
Scored across 2 tools
The two tools have clearly distinct inputs and purposes: read_github_file targets repository files by repo+path, while read_web_page targets arbitrary public URLs. There is minor conceptual overlap since a GitHub file is also reachable as a web page, but the descriptions make the intended use of each clear.
Both tools follow the same consistent verb_noun snake_case pattern (read_github_file, read_web_page). There is no deviation in style or convention across the set.
With only 2 tools the surface is thin, though it matches a narrowly scoped content-reading purpose. A couple more complementary readers (e.g. pagination handling or search) would make the set feel complete rather than minimal.
For reading public content the surface covers the core needs, and the tools clearly delegate out-of-scope cases (login-required pages, PDFs) to other Faceabot tools. Minor gaps remain, such as no explicit way to fetch subsequent pages of long content.
Returns a file from a public GitHub repository (default: its README). Use when: you need a project's README, documentation or source file. Example: {"repo":"cloudflare/workers-sdk","path":"README.md"}
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Branch, tag or commit. Default: the default branch | |
| path | No | File path. Default: the README | |
| repo | Yes | owner/name, e.g. cloudflare/workers-sdk | |
| start | No | ||
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description usefully adds that the repo must be 'public' (no private/auth path) and that README is the default target. It says nothing about rate limits, truncation via max_chars, or behavior when the file/repo does not exist.
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?
Three short lines: the operation, the when-to-use trigger, and a literal invocation example. Front-loaded and free of filler, and the example directly aids correct calling.
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?
For a five-parameter read tool with no output schema, the description leaves important behavior unspecified: what the return value looks like, whether long files are truncated and how max_chars/start interact, and error behavior for missing repos or paths. Annotations cover the safety aspects, so what remains is a moderate but real gap.
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 60%: ref, path and repo are documented in the schema, while start and max_chars carry only constraints and defaults. The description restates the path default and supplies a concrete example, but does not explain the windowing/truncation semantics of start and max_chars, so it only partially compensates for the gap.
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?
States a specific verb and resource ('Returns a file from a public GitHub repository') and adds the default-readme behavior, so the purpose is unambiguous. It never names the sibling read_web_page or contrasts the two, so an agent gets no help distinguishing them from the description alone.
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 'Use when: you need a project's README, documentation or source file' line gives a clear triggering context. There are no exclusions or named alternatives (e.g., when to prefer read_web_page for non-GitHub URLs), which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a public web page and returns its title and main text as clean plain text (menus, scripts and ads removed), in pages of up to 50,000 characters. Use when: you need the content of an article, a documentation page, a blog post or any public page. Not for: pages that need a login; PDFs (use the Faceabot PDF tool). Example: {"url":"https://example.com"}
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public https address of the page | |
| start | No | ||
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavior beyond that: it strips menus/scripts/ads, returns clean plain text, and chunks output into pages of up to 50,000 characters, which signals truncation. It stops short of stating rate limits, retry behavior, or how to detect that more pages remain.
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?
Three front-loaded sentences using 'Use when:' / 'Not for:' / 'Example:' scaffolding, with zero filler. The leading sentence carries the core purpose and return format before any qualifications.
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?
With no output schema, the description correctly takes on the job of describing the return value (title + main text, plain text, paginated). Combined with the usage boundaries this is nearly complete for a three-parameter read tool; the only shortfall is that pagination mechanics ('start') are implied rather than spelled out.
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 only 33%: 'url' is documented in the schema, but 'start' and 'max_chars' have no descriptions there. The description partially compensates by revealing the 50,000-character page ceiling (which maps to max_chars' maximum) and by implying multi-page retrieval, but it never explains 'start' or the default 15000, so the compensation is incomplete.
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 states a concrete verb and resource ('Reads a public web page') and specifies exactly what comes back ('its title and main text as clean plain text'). The 'public web page' scope plus the article/docs/blog framing cleanly separates it from the sibling read_github_file, which targets repository files rather than arbitrary public URLs.
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?
It gives explicit positive triggers ('you need the content of an article, a documentation page, a blog post or any public page') and explicit exclusions ('Not for: pages that need a login; PDFs (use the Faceabot PDF tool)'), routing the agent to an alternative tool for the excluded case. Nothing about when to select this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
read_github_fileread_web_pageURL to clean markdown for LLMs: a polite, robots.txt-respecting web reader. Free, no API key
Read any public web page as clean Markdown for LLMs, with its metadata. Paid per call, x402.
Paid fallback for public webpages: clean text, Markdown, links, metadata, and JavaScript rendering.
Link-preview metadata and clean page-to-Markdown for any public URL. No install.
Add one secure layer between your agents and this server.
