Another bloated Obsidian MCP Server

Overview Schema Source Related Servers Discussions Admin

list_attachments

Find all non-markdown files (images, PDFs, audio, etc.) in an Obsidian vault. Filter by folder or attachment type to locate specific files.

Instructions

List all non-markdown files (images, PDFs, etc.) in the vault. Can filter by folder and type.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_attachments"
  }
}

Input Schema

Name	Required	Description	Default
`type`	No	Filter by attachment type (default: all)	all
`folder`	No	Folder to search for attachments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.3.0Aug 2, 2026

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the full burden. 'List' inherently conveys a read-only operation, and the description specifies what qualifies as an attachment (non-markdown files). However, it omits details like recursion behavior, output format, or handling of hidden files, which an agent might need.

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, efficient sentence that front-loads the core purpose ('List all non-markdown files') and then states the filter option. Every word earns its place with no redundancy.

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?

With no output schema or annotations, the description covers the core purpose and filters, which is largely sufficient for a simple list tool. However, it does not specify the return format (e.g., full paths vs. names) or whether subfolders are included recursively, leaving minor gaps.

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?

Schema description coverage is 100%, so the parameters are already well-documented. The description's 'Can filter by folder and type' merely restates the schema properties and adds no new meaning beyond what is already in the structured data.

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 'List all non-markdown files (images, PDFs, etc.) in the vault' with a specific verb and resource, and it mentions filtering by folder and type. This distinguishes it from sibling tools like list_notes and get_attachments_in_note.

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

Usage Guidelines3/5

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

The description implies vault-wide listing of non-markdown files, but it does not explicitly state when to use this tool over alternatives such as get_attachments_in_note or find_unused_attachments. It provides context (vault-wide vs. per-note) but no direct comparison or exclusion.

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