Skip to main content
Glama

Add text or a web page to a knowledge base

add_knowledge_source
Destructive

Add a block of text (kind text) or a web page (kind website) to a knowledge base; Fetch Hive indexes it in the background. Indexing uses credit, so call it first without approved to see what happens, and again with approved: true only after the person agrees. Files are added on the dashboard. Then check get_knowledge_base until the source is ready.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "knowledge_base_id": "<knowledge_base_id>",
      "kind": "<kind>"
    },
    "name": "add_knowledge_source"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNokind website: the page to index.
kindYes
nameNoDefault: the start of the text or the URL.
textNokind text: the content to index (up to 200,000 characters).
approvedNotrue only after the person has agreed to the cost.
knowledge_base_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint/openWorldHint and non-idempotent behavior, and the description adds real context beyond them: indexing happens asynchronously in the background and consumes credit, which motivates the approval flow. It does not explain why the operation is flagged destructive or what a failed/partially indexed source looks like, so it stops short of full behavioral disclosure.

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?

Three tightly packed sentences with the core action front-loaded and the cost-safety instruction second. Dense but no filler; the final polling hint could be merged more smoothly, keeping it just shy of ideal.

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 cost-incurring mutation with no output schema, the description covers the consent workflow, the async indexing model, the out-of-band file path, and the verification step. It leaves out only error/failure handling and what the preview response actually contains when 'approved' is omitted.

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 coverage is 67% and the schema already documents url, text, name, approved, and the kind enum, so the description's parameter-level additions are limited to reinforcing that 'approved' is a cost-consent gate. It adds no format, limit, or default guidance beyond what the structured fields already carry.

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 and resource ('Add a block of text ... or a web page ... to a knowledge base') and names the two modes tied to the kind enum, so the agent can separate it from create_knowledge_base and remove_knowledge_source immediately.

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?

Gives an explicit two-phase protocol: call first without 'approved' to preview the cost, then call again with approved: true only after the person agrees. It also names the alternative path for files (the dashboard) and the follow-up tool (get_knowledge_base) for verifying readiness.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources