Obsidian MCP (pgvector + Ollama, self-hosted)

check_upload

Check an upload link's status (pending, uploading, completed, unknown, revoked, or expired) and get the resulting path, size, SHA-256, and MIME type to confirm the transfer finished.

Instructions

Ask what happened to an upload link you minted with request_upload.

Returns one of pending (nothing sent yet), uploading (bytes are in flight), completed (with the path, size, sha256 and MIME type of what landed), unknown (a stream started and the server never recorded how it ended), revoked (the link is dead because the credential or vault root changed under it), or expired. Use it to confirm a transfer really finished before you tell the user it did, and to get the sha256 if they want to verify it.

Visibility is scoped to the principal that minted the link, not to one credential row. For an API key that is the key itself. For OAuth it is the whole grant family behind the access token you are calling with, so a handle stays readable across the hourly token refresh that mints a new row. A different API key, a different client, or a separate approval of the same client reads as not found.

uploading names the deadline the stream has. Check again after it: past that point the answer becomes either completed or unknown. unknown does not mean nothing arrived — a publish can succeed and still fail to record its completion — so read or list the path before minting another link or telling anyone the file did not arrive.

Pass the upload_id itself — the short handle from request_upload, not the upload URL and not the token after the #. Anything else is refused without a lookup.

Args: upload_id: The upload_id that request_upload returned.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`upload_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.0Aug 19, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and thoroughly discloses edge behaviors: each status meaning, the `unknown` ambiguity (publish can succeed without recorded completion), the deadline after which status settles, principal-based visibility with OAuth grant families, and refusal of non-upload_id inputs without a lookup. It also warns to read/list the path before minting another link or reporting failure. No contradictory annotation exists.

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?

Every paragraph addresses a distinct operational aspect—purpose, statuses, usage trigger, visibility, timeout semantics, and parameter guidance—without repeating schema or annotation information. The core purpose is front-loaded, and the length is justified by the tool's semantic complexity.

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?

The description covers return statuses and their implications, principal scoping, expiration behavior, the unknown-state caveat, and exact input requirements. Together with the existence of an output schema, an agent has everything needed to call this tool correctly and interpret its result.

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?

The schema provides only a bare string type with 0% coverage. The description compensates by defining the exact expected value ('the short handle from `request_upload`'), explicitly excluding the upload URL and the token after the `#`, and stating that anything else is refused without a lookup.

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 first sentence states a specific action ('Ask what happened to an upload link you minted with `request_upload`') and enumerates the possible statuses, distinguishing this status-check tool from transfer-creation siblings like request_upload. It is unmistakable what resource it operates on and what it returns.

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 explicitly instructs when to call it: 'Use it to confirm a transfer really finished before you tell the user it did, and to get the sha256 if they want to verify it.' It also clarifies the relationship to request_upload and that handles are scoped to the minting principal, which prevents misuse with other principals.

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