Obsidian MCP (pgvector + Ollama, self-hosted)

Outgoing links

get_links

Read-onlyIdempotent

Retrieve a note's outgoing links—both resolved and dangling—to trace dependencies and find broken references needing follow-up notes. Supports a limit and flags truncated results.

Instructions

Outgoing links from path — both resolved and dangling.

Useful for "what does this note depend on?" or finding broken references that need follow-up notes.

The result carries a truncated field. truncated: true means this note holds more links than the indexer's per-note cap and the list is the first N in document order only — treat it as incomplete rather than as the note's full outgoing-link set.

Links come back in document order and are capped by limit; when more rows exist the result says how many of them were persisted, so a partial page is never read as the whole set. limit raises the page up to a hard cap of 500 — this tool has no paging beyond that, so a note with more than 500 link rows can only be read in full from the note itself.

Each row's link text is clipped to 120 characters.

Args: path: Vault-relative path to the source note. limit: Maximum links returned (default 100, hard cap 500).

Input Schema

Name	Required	Description	Default
`path`	Yes
`limit`	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
```

Changed1 schema field changedv0.8.1Sep 16, 2026

addedInput schema / properties / limit

Added value: +{
+  "default": 100,
+  "title": "Limit",
+  "type": "integer"
+}

First observedMay 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive); the description adds the parts annotations can't: the `truncated` flag and its per-note cap meaning, document-order results, and the fact that no paging exists beyond the 500 hard cap. It also discloses a lossy behavior (link text clipped to 120 chars) that would otherwise silently distort results.

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 the one-line purpose and use cases, then progressively deeper detail. Slightly repetitive: the truncation concept is explained three times across three paragraphs (per-note cap, `limit` capping, hard cap 500), which costs a sentence or two of economy.

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?

An output schema exists, yet the description still explains the one return field whose semantics matter operationally (`truncated`), which is exactly the right level of overlap. Nothing an agent needs to call this correctly or interpret a partial result is missing.

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 description coverage is 0%, so the description must carry the load and does: `path` is documented as vault-relative (semantics beyond a bare string), and `limit` gets default, purpose, and hard cap 500. The explicit Args block removes any ambiguity the schema leaves.

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 resource and direction: outgoing links from `path`, both resolved and dangling. The word 'outgoing' plus the 'dangling' qualifier cleanly separates it from get_backlinks and from read_note without the agent needing to open 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 Guidelines4/5

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

Gives two concrete use cases ('what does this note depend on?', finding broken references) and implicitly routes the agent to the note itself when the >500-row case arises. It never explicitly names get_backlinks or read_note as alternatives, so the when-not guidance is by implication rather than declaration.

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