Skip to main content
Glama

add_web_source

Fetch documentation from a web URL by crawling HTML pages, with configurable depth, pattern, and directory restrictions to add a new source.

Instructions

Fetch documentation from a web URL (or re-download existing source).

If url is not provided, re-downloads an existing web source by slug.

By default, only fetches URLs in the same directory or below the initial URL. For example, fetching https://example.com/docs/api/index.html will only fetch files under https://example.com/docs/api/ and not https://example.com/docs/other/.

Only HTML files (.html, .htm, or no extension) are fetched and followed. Non-HTML files (CSS, JS, images, fonts, etc.) are automatically skipped.

Args: slug: Unique identifier for this web source url: Base URL to fetch from (optional for re-download) name: Display name (defaults to slug) max_depth: Recursion depth for crawling (default: 2) pattern: Regex pattern for URLs to fetch (default: .*.html?$) url_prefix: Optional URL prefix to restrict crawling (default: directory of initial URL)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNo
nameNo
slugYes
patternNo.*\.html?$
max_depthNo
url_prefixNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

No annotations exist, so the description carries the burden. It discloses significant behavior: directory restriction, HTML-only crawling, non-HTML skipping, and default behavior. However, it does not mention auth requirements, rate limits, or whether re-downloading overwrites existing data—minor but notable 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 well-structured with a short intro, behavioral details with an example, and a labeled Args list. Every sentence contributes useful information, balancing detail with readability.

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 tool with 6 parameters, no annotations, and an output schema, the description is sufficiently complete. It covers param semantics, defaults, crawling behavior, and edge cases like no url provided. The output schema covers return values, so no description of return format is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully compensates by explaining every parameter (slug, url, name, max_depth, pattern, url_prefix) with clear semantics and defaults. It adds meaning beyond the raw schema, such as the pattern's regex meaning and url_prefix's directory default.

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 primary action: 'Fetch documentation from a web URL', and also the secondary mode: 're-download existing source'. It distinguishes from siblings through 'web URL' vs local source, making the tool's scope explicit.

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 description implies usage context: fetch from a web URL or re-download by slug. It provides a clear conditional for re-download but does not explicitly compare with alternatives like add_local_source. No exclusions are stated, but the 'web' vs local distinction is implicit.

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

Install Server

Other Tools

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/HellButcher/devdocs-mcp'

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