Obsidian Everywhere

Overview Schema Source Related Servers Discussions Admin

Get Related

get_related

Read-onlyIdempotent

Recommend related notes lacking direct links. Use jaccard for shared-tag similarity or semantic for embedding-based matching.

Instructions

Recommend similar notes that are NOT directly linked to the given note. Default method 'jaccard' is lightweight and uses shared tags and shared 1-hop neighbors. The optional method 'semantic' uses local embedding similarity and requires OBSIDIAN_EVERYWHERE_ENABLE_SEMANTIC=true because its multilingual model exceeds the default low-memory budget.

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": {
      "path": "<path>"
    },
    "name": "get_related"
  }
}

Input Schema

Name	Required	Description
`path`	Yes	Note path, title, or alias.
`limit`	No	Max results (default 5).
`method`	No	Similarity method (default jaccard).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.0Jul 27, 2026

addedInput schema / properties / method

Added value: +{
+  "description": "Similarity method (default jaccard).",
+  "enum": [
+    "jaccard",
+    "semantic"
+  ],
+  "type": "string"
+}

First observedv0.1.0Jul 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context: the 'NOT directly linked' constraint, the lightweight nature of the default method, and the memory/environment requirement for semantic. It explains the trade-off between methods without contradicting annotations.

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?

Two sentences, first states core behavior, second explains optional method and its requirement. Every sentence earns its place; no fluff, no repetition of schema fields. Front-loaded with the core purpose.

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?

Given the tool has 3 parameters, all documented in schema, and annotations cover the safety profile, the description adds the critical missing piece: the semantic method's memory requirement and default behavior. It doesn't describe the return format, but with no output schema that's not required. It's comprehensive for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions, so baseline is 3. The description adds extra semantics for the 'method' parameter by explaining what 'jaccard' vs 'semantic' actually do and why you might choose one. It also implies the 'limit' parameter with 'Max results' but the description doesn't add semantics beyond that, so slightly above baseline.

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 clearly states it 'Recommend(s) similar notes that are NOT directly linked to the given note' – specific verb (recommend), specific resource (similar notes), and a key scoping constraint (NOT directly linked). It distinguishes from siblings like get_backlinks and get_neighborhood by emphasizing indirect relatedness.

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?

It implicitly communicates when to use the default jaccard method vs semantic, and explicitly mentions the environment variable requirement for semantic. However, it doesn't contrast with alternative tools like search_notes or semantic_search, leaving the agent to infer when to prefer this over them.

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