Skip to main content
Glama
Sign In
wiki-compiler

wiki-compiler

by Ray0907
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

add_document

Fetch any URL and compile it into a structured, backlinked wiki page in your Obsidian-compatible vault for easy knowledge querying.

Instructions

Fetch and compile a URL into the wiki vault.

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": {
      "url": "<url>"
    },
    "name": "add_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'fetch and compile' but does not disclose side effects such as creating/modifying files in the vault, network requests, auth requirements, or failure modes. It is vague about what 'compile' entails.

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 concise sentence with no filler. Every word contributes to conveying the tool's core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple tool with one parameter, but it still lacks important context: no mention of side effects, when to use it, or what happens on success/failure. The description is too minimal for an agent to safely invoke it without further assumptions.

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?

The schema has zero description coverage, but the description does indicate that the 'url' parameter is the target URL to fetch and compile. However, it adds no detail about URL format, validity, or edge cases. It provides essential context but not much beyond the parameter property name.

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 'Fetch and compile a URL into the wiki vault' uses a specific verb ('fetch and compile') and names the resource (URL into the wiki vault), clearly distinguishing it from sibling tools like search_wiki and lint_wiki. It clearly states what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or situations where search_wiki or lint_wiki would be more appropriate. Usage context is only implied by the verb and name.

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