Obsidian MCP (pgvector + Ollama, self-hosted)

Import from URL

import_from_url

Destructive

Downloads a public HTTPS file directly into the Obsidian vault server-side, returning saved path, size, SHA-256, MIME type, and final URL; write access required.

Instructions

Fetch a file from a public https URL straight into the vault. Requires write permission — a readwrite API key, or an OAuth token carrying the readwrite scope. Peer to write_file and request_upload — use this one when the bytes are already somewhere public.

The server does the fetching, so nothing passes through your context: a 20 MB PDF costs one tool call. Returns the path, size, sha256, MIME type and the final URL after any redirects.

Only genuinely public addresses. This server sits on a private network next to a database and other services, so the fetch is restricted: https only — plain http is refused unless the operator has set IMPORT_ALLOW_HTTP=true — no credentials in the URL, no private/loopback/link-local/metadata addresses in any spelling, and the same rules re-checked at every redirect. A refusal names the rule that was violated — that is information about the URL, not a hint to work around it. Rewriting the URL to evade the check is never the right next step; ask the user for a public link instead.

Size-capped at MAX_FILE_WRITE_BYTES, with one 30-second deadline for the whole fetch. No-clobber unless overwrite=True. Nothing is written unless the whole body arrives intact.

This tool shares the transfer tools' preflight, so it also refuses when the server has no public origin configured (MCP_HOSTNAME or BASE_URL), even though it mints no link — that is an operator setting, not something to work around.

Args: url: Public https URL of the file, at most 8,192 characters; a longer one is refused with argument_too_long before anything is fetched. path: Vault-relative destination (e.g. "Attachments/paper.pdf"). overwrite: If True, allow replacing an existing file at path.

Input Schema

Name	Required	Description	Default
`url`	Yes
`path`	Yes
`overwrite`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.2Sep 24, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Addedv0.7.0Aug 19, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations, it discloses write-permission requirements, server-side fetching behavior, return data, SSRF restrictions, redirect re-checks, size and timeout limits, no-clobber defaults, and atomicity guarantees. These details add substantial operational context not captured by `destructiveHint`, `openWorldHint`, or `readOnlyHint`.

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 long but appropriately dense for a security-sensitive import tool. It is front-loaded with purpose, permission, and sibling differentiation, then proceeds logically through behavior, safety constraints, failure modes, and arguments without redundant filler.

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?

Given the tool's complexity, open-world network access, destructive potential, and 0% schema description coverage, the description supplies the missing safety, permission, and failure-mode context. It also explains return values even though an output schema exists, leaving no important operational gap for an agent.

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?

Although schema description coverage is 0%, the description fully documents all three parameters. It explains `url` as a public https URL capped at 8,192 characters, `path` as a vault-relative destination with an example, and `overwrite` as permitting replacement of an existing file.

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 states a specific verb and resource: fetch a public https URL into the vault. It explicitly distinguishes itself from siblings by naming `write_file` and `request_upload` and explaining that this tool is for bytes already public elsewhere.

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?

It gives clear when-to-use guidance relative to alternatives: use this when the source bytes are already public, rather than using `write_file` or `request_upload`. It also gives strong when-not-to-use guidance by restricting usage to genuinely public addresses and warning not to rewrite URLs to evade SSRF checks.

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