Skip to main content
Glama
lyonzin

knowledge-rag

by lyonzin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

add_from_url

Fetch a public URL, convert its HTML to markdown, and index it immediately in the knowledge base so web content becomes searchable.

Instructions

Fetch content from a URL, convert to markdown, and add to the knowledge base.

Mutating — makes an outbound HTTP request (requires internet access), strips HTML, converts to markdown, saves to disk, and indexes immediately.

Args: url: Full URL to fetch (https:// required). The page must be publicly accessible. category: Document category — one of: security, ctf, logscale, development, general, redteam, blueteam (default: general) title: Optional document title. Auto-detected from the page's tag if omitted.

Returns: JSON string with indexing results (detected title, filepath, chunks created, status).

Usage: Use to ingest web content (writeups, blog posts, documentation pages) directly by URL. Use add_document() instead when you already have the text content. The document is immediately searchable after this call — no manual reindex needed.

Input Schema

NameRequiredDescriptionDefault
urlYes
titleNo
categoryNogeneral

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.11.1
    • addedInput schema / properties / title / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / title / type
      Removed value: -"string"
  2. First observedv3.0.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it declares the tool as mutating, names the outbound HTTP / internet-access dependency, and enumerates side effects (HTML stripping, markdown conversion, disk write, immediate indexing). It stops short of failure modes and dedupe semantics — e.g. what happens if the same URL is added twice, or whether an existing document is overwritten.

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?

Front-loaded with purpose and the mutating warning, then structured Args and Usage blocks — an agent can skim it. Minor waste: the Returns block restates fields already covered by the output schema, and the first paragraph partially repeats the second.

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?

For a 3-parameter ingest tool with an output schema, the essentials are present: input constraints, category vocabulary, title fallback, mutation effects, and immediate searchability. The remaining gap is lifecycle behavior on re-ingestion (dedupe/overwrite) and any size or fetch-failure limits, which matter for a tool that writes to disk and indexes.

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%, so the description must compensate and does: url is constrained to full https URLs on publicly accessible pages, category is fully enumerated (security, ctf, logscale, development, general, redteam, blueteam) with its default, and title's auto-detection from the <title> tag is explained. This is materially more than the bare schema supplies.

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?

States a specific verb chain (fetch, convert, add) against a concrete resource (URL content into the knowledge base), and explicitly distinguishes itself from the sibling add_document by input type. An agent can route between the two without opening either schema.

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 Usage section names the scenario (writeups, blog posts, doc pages by URL) and the exclusion with the exact alternative: use add_document() when you already have the text. It also closes the follow-up question by stating no manual reindex is needed.

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

Deploy Server

Other Tools