Obsidian MCP Server
The Obsidian MCP Server enables AI assistants to comprehensively manage and interact with Obsidian vaults, providing extensive capabilities for note operations, knowledge graph analysis, and workflow automation.
Core Capabilities:
Note Management: Create, read, update, append, and delete notes with frontmatter support and safety features like trash folder protection
Advanced Search: Search by content, title, tags, or frontmatter properties with filtering options by folder and result limits
Link Analysis: Generate network graphs, find backlinks/outgoing links, discover related notes, and identify orphaned notes for knowledge graph visualization
Tag Operations: List all tags with usage counts and filter notes by specific tags
Daily Notes: Auto-create or access daily notes for any date and list recent entries
Templates: Create notes from templates with variable replacement (title, date, time)
Google Calendar Integration: Bidirectionally link calendar events with notes, including create, update, search, and delete operations
Batch Operations: Atomically update or append to multiple notes with automatic backup and rollback capabilities for safe bulk modifications
Vault Analytics: Access comprehensive vault statistics including note counts, tags, and size metrics
All operations include security features like path traversal protection and input validation, making it safe for AI assistants to manage your knowledge base programmatically.
Provides optional integration for creating, updating, and managing Google Calendar events with bidirectional linking to Obsidian notes
Enables reading, writing, and managing Obsidian vault notes with support for searching, link analysis, tag management, daily notes, templates, and vault statistics
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Obsidian MCP Serverfind all notes with the tag #meeting from last week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Obsidian MCP Server
Model Context Protocol (MCP) server for accessing Obsidian vaults. This server enables AI assistants like Claude to read, search, and interact with your Obsidian notes.
Features
Core Operations
Read Notes: Access individual notes with frontmatter and content
Write Notes: Create, update, append, and delete notes
Search: Search notes by content, title, tags, or frontmatter properties
List Notes: Browse notes with filtering options
Link Analysis
Backlinks: Find all notes that link to a specific note
Outgoing Links: Get all links from a note to other notes
Link Graph: Build a network graph of all note connections
Related Notes: Discover notes related by shared links and tags
Orphaned Notes: Find notes with no incoming or outgoing links
Tag Management
List All Tags: Get all tags with usage counts
Filter by Tag: Find all notes with a specific tag
Tag Statistics: Analyze tag usage across the vault
Daily Notes
Get Daily Note: Retrieve or create daily notes by date
List Daily Notes: Browse recent daily notes
Auto-creation: Automatically create daily notes with proper formatting
Templates
List Templates: Browse available templates
Create from Template: Generate new notes from templates
Variable Replacement: Support for {{date}}, {{time}}, {{title}} placeholders
Google Calendar Integration (Optional)
Create Calendar Events: Create Google Calendar events linked to notes
List Events: Browse upcoming calendar events
Delete Events: Remove calendar events and update note metadata
Bidirectional Linking: Events link to notes via obsidian:// URLs
Auto-metadata: Calendar event details stored in note frontmatter
Vault Statistics
Vault Stats: Total notes, tags, size, and distribution
Search by Property: Query notes by frontmatter fields
Security & Performance
Path Traversal Protection: Prevent access outside vault
Input Validation: Comprehensive validation of all inputs
Optimized Search: Fast search with caching
Safe Deletion: Trash folder support (reversible deletes)
Requirements
Python 3.10 or higher
An Obsidian vault
Installation
Using uv (Recommended)
# Clone or navigate to the project directory
cd obsidian_mcp
# Install with uv
uv pip install -e .
# Or install with development dependencies
uv pip install -e ".[dev]"Using pip
pip install -e .Configuration
Using .env File (Recommended)
Create a .env file in the project root:
# Copy the example file
cp .env.example .env
# Edit with your vault path
nano .envExample .env:
OBSIDIAN_VAULT_PATH=/Users/yourname/Documents/ObsidianVault
OBSIDIAN_MAX_RESULTS=100
OBSIDIAN_SNIPPET_LENGTH=200Using Environment Variables
Alternatively, set environment variables directly:
export OBSIDIAN_VAULT_PATH="/path/to/your/vault"
export OBSIDIAN_MAX_RESULTS=100
export OBSIDIAN_SNIPPET_LENGTH=200Google Calendar Integration (Optional)
To enable Google Calendar integration:
1. Enable Google Calendar API
Go to Google Cloud Console
Create a new project or select an existing one
Enable the Google Calendar API
Go to Credentials → Create Credentials → OAuth client ID
Configure OAuth consent screen if prompted
Select Application type: Desktop app
Download the credentials as
credentials.json
2. Configure Credentials
# Place credentials.json in your project directory
cp ~/Downloads/credentials.json /path/to/obsidian_mcp/
# Add to your .env file
echo "GOOGLE_CALENDAR_CREDENTIALS_PATH=/path/to/obsidian_mcp/credentials.json" >> .env
echo "GOOGLE_CALENDAR_ID=primary" >> .env
echo "OBSIDIAN_VAULT_URL_BASE=obsidian://open?vault=YourVaultName&file=" >> .envImportant: Replace YourVaultName with your actual Obsidian vault name (found in Obsidian Settings → About).
3. Scope to a Specific Calendar (Optional)
By default, the integration uses your primary calendar (GOOGLE_CALENDAR_ID=primary). To scope operations to a specific calendar:
Get your Calendar ID:
Go to Google Calendar
Click settings gear → Settings
Select the calendar you want to use (left sidebar)
Scroll to Integrate calendar section
Copy the Calendar ID (e.g.,
work@group.calendar.google.com)
Configure it:
# In your .env file
GOOGLE_CALENDAR_ID=work@group.calendar.google.comImportant: While OAuth grants access to all your calendars, the MCP server will ONLY create, read, update, and delete events in the configured calendar. All calendar operations respect this setting for safety.
4. First-Time Authorization
When you first use a calendar tool, the server will:
Open your browser for Google OAuth authorization
Ask you to grant calendar access permissions
Save the token to
.credentials/token.jsonfor future use
Security Notes:
The server uses scope
https://www.googleapis.com/auth/calendar.events(events only, no calendar management)Token file is automatically protected with 600 permissions
Both
credentials.jsonand.credentials/are gitignored
5. Event-Note Linking
Created calendar events include:
Obsidian deep link in event description (clickable in Google Calendar)
Event metadata in note frontmatter:
--- calendar_event_id: "abc123..." calendar_event_link: "https://www.google.com/calendar/event?eid=..." calendar_event_date: "2025-01-15" calendar_event_time: "14:00" ---
Claude Desktop Integration
Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"obsidian": {
"command": "uv",
"args": ["run", "obsidian-mcp"],
"env": {
"OBSIDIAN_VAULT_PATH": "/Users/yourname/Documents/ObsidianVault"
}
}
}
}Or using the installed script directly:
{
"mcpServers": {
"obsidian": {
"command": "/path/to/.venv/bin/obsidian-mcp",
"env": {
"OBSIDIAN_VAULT_PATH": "/Users/yourname/Documents/ObsidianVault"
}
}
}
}Usage
Available Tools
The server exposes 27 MCP tools organized by category:
Read Operations
read_note - Read the full content of a note
path(string): Relative path to the note (e.g., "Projects/MCP.md")
search_notes - Search the vault by content, title, tags, or all
query(string): Search querysearch_type(string): "content", "title", "tags", or "all" (default: "all")folder(string): Limit search to folderlimit(number): Max results (default: 20)
list_notes - List notes in the vault with optional filters
folder(string): Folder to list (empty for root)recursive(boolean): Include subfolders (default: true)limit(number): Max results (default: 100)
Link Analysis
get_backlinks - Get all notes that link to a specific note (incoming links)
path(string): Relative path to the note
get_outgoing_links - Get all links from a note to other notes (outgoing links)
path(string): Relative path to the note
get_related_notes - Find notes related to a specific note based on shared links and tags
path(string): Relative path to the notelimit(number): Maximum number of related notes (default: 10)
get_orphaned_notes - Find notes with no incoming or outgoing links
limit(number): Maximum number of results (default: 50)
Tag Operations
list_all_tags - Get all tags in the vault with usage counts
limit(number): Maximum number of tags to return (default: 100)
get_notes_by_tag - Find all notes with a specific tag
tag(string): Tag to search for (with or without #)limit(number): Maximum number of results (default: 50)
Search & Query
search_by_property - Search for notes by frontmatter property (metadata field)
property_name(string): Name of the frontmatter property to searchproperty_value(string): Optional value to match (empty to find all notes with this property)limit(number): Maximum number of results (default: 50)
Statistics
get_vault_stats - Get statistics about the vault
Returns total notes, tags, size, and top tags
Write Operations
create_note - Create a new note in the vault
path(string): Relative path for the new note (e.g., "Projects/New Idea.md")content(string): Content of the notetags(list[string]): Optional list of tags to add to frontmatteroverwrite(boolean): If true, overwrite existing note (default: false)
update_note - Update an existing note's content (preserves frontmatter)
path(string): Relative path to the notecontent(string): New content for the note body
append_to_note - Append content to the end of an existing note
path(string): Relative path to the notecontent(string): Content to append
delete_note - Delete a note (moves to .trash by default)
path(string): Relative path to the notepermanent(boolean): If true, permanently delete; otherwise move to .trash folder (default: false)
update_frontmatter - Update frontmatter fields in a note (preserves content)
path(string): Relative path to the noteproperty_name(string): Name of the frontmatter fieldproperty_value(string): Value to set
Batch Operations
batch_update_notes - Update multiple notes atomically with automatic backup/rollback
updates(list): Array of objects with{path, content, frontmatter?}structuredry_run(boolean): Preview changes without applying (default: false)confirm(boolean): Must be true to apply changes (safety check)
batch_append_notes - Append content to multiple notes atomically
appends(list): Array of objects with{path, content}structureconfirm(boolean): Must be true to apply changes
restore_batch_backup - Restore notes from a batch backup (undo operation)
backup_id(string): Backup timestamp ID (e.g., "20250115_143025")
list_batch_backups - List available batch backups
limit(number): Maximum number of backups to list (default: 10)
See docs/BATCH_OPERATIONS.md for complete guide with examples.
Daily Notes
get_daily_note - Get or create a daily note for a specific date
date_str(string): Date in YYYY-MM-DD format (empty for today)folder(string): Folder where daily notes are stored (default: "Daily Notes")create(boolean): If true, create the note if it doesn't exist (default: true)
list_daily_notes - List recent daily notes
folder(string): Folder where daily notes are stored (default: "Daily Notes")limit(number): Maximum number of notes (default: 30)
Templates
list_templates - List available note templates
folder(string): Folder where templates are stored (default: "Templates")
create_from_template - Create a new note from a template
template_path(string): Path to the template notenew_note_path(string): Path for the new notetitle(string): Optional title to replace {{title}} placeholder
Graph & Network
get_link_graph - Get the link graph for the vault (nodes and edges for visualization)
max_notes(number): Maximum number of notes to include (default: 500)
Google Calendar (Optional)
create_calendar_event - Create a Google Calendar event linked to a note
note_path(string): Path to the note to link (e.g., "Projects/Meeting.md")title(string): Event titledate(string): Event date in YYYY-MM-DD format (e.g., "2025-01-15")time(string): Event time in HH:MM format (e.g., "14:00")duration_minutes(number): Event duration in minutes (default: 60)description(string): Optional event descriptionconfirm(boolean): Must be true to confirm creation (safety check)
list_calendar_events - List upcoming calendar events
max_results(number): Maximum number of events (default: 10)days_ahead(number): Number of days to look ahead (default: 7)
get_calendar_event - Get details of a specific calendar event
event_id(string): Calendar event ID
search_calendar_events - Search calendar events by text query or date range
query(string): Text to search for in event title/description (optional)date_from(string): Start date YYYY-MM-DD (default: today)date_to(string): End date YYYY-MM-DD (default: 30 days from date_from)max_results(number): Maximum number of events (default: 20)
update_calendar_event - Update/move a calendar event
event_id(string): Calendar event ID to updatetitle(string): New event title (optional)date(string): New date YYYY-MM-DD (optional)time(string): New time HH:MM (optional)duration_minutes(number): New duration in minutes (optional)description(string): New description (optional)location(string): New location (optional)confirm(boolean): Must be true to confirm update (safety check)
delete_calendar_event - Delete a calendar event
event_id(string): Calendar event IDupdate_note(boolean): If true, remove event info from linked note (default: true)confirm(boolean): Must be true to confirm deletion (safety check)
Development
Setup Development Environment
# Install with development dependencies
make dev
# Or manually
uv pip install -e ".[dev]"Code Quality
# Format code
make format
# Lint code
make lint
# Type check
make type-check
# Run all quality checks
make qualityTesting
# Run unit tests only
make test
# Run integration tests
make test-integration
# Run all tests
make test-all
# Run tests with coverage
pytest tests/ --cov=src/obsidian_mcp --cov-report=htmlProject Structure
obsidian_mcp/
├── src/obsidian_mcp/
│ ├── __init__.py
│ ├── server.py # MCP server implementation
│ ├── vault.py # Vault operations
│ ├── search.py # Search functionality
│ ├── calendar.py # Google Calendar integration
│ └── config.py # Configuration management
├── tests/
│ ├── unit/ # Unit tests
│ ├── integration/ # Integration tests
│ └── conftest.py # Pytest fixtures
├── pyproject.toml # Project configuration
├── Makefile # Build automation
└── README.md # This fileSecurity
Safe by Design
The server is designed to work safely within your Obsidian vault:
Access is restricted to your configured vault directory only
Cannot access files outside the vault (including through symbolic links)
All file operations are validated before execution
Batch operations create backups before making changes and restore them if any operation fails
Best Practices
Separate Vault: Consider using a separate vault for AI access
Exclude Sensitive Folders: Configure
exclude_foldersin your setupUse Batch Operations: When editing multiple notes, use batch operations to get automatic backups before changes and automatic restore if anything fails
Regular Backups: Always maintain backups of your vault
Troubleshooting
Server Not Starting
Problem: "OBSIDIAN_VAULT_PATH environment variable must be set"
Solution: Set the vault path in your environment or Claude config.
No Notes Found
Problem: Search or list returns no results
Solution:
Check that the vault path is correct
Ensure notes have
.mdextensionCheck that folders aren't in the exclude list
Path Security Errors
Problem: "Path attempts to access files outside vault"
Solution: Use relative paths only (e.g., "folder/note.md" not "/absolute/path")
Unicode Errors
Problem: Errors reading notes with special characters
Solution: Ensure notes are saved as UTF-8 in Obsidian
Google Calendar Issues
Calendar Not Authorized
Problem: "Calendar credentials not found" or OAuth not starting
Solution:
Verify
GOOGLE_CALENDAR_CREDENTIALS_PATHpoints to validcredentials.jsonDelete
.credentials/token.jsonand re-authorizeCheck file permissions on credentials
Wrong Calendar Modified
Problem: Events created in wrong calendar
Solution:
Verify
GOOGLE_CALENDAR_IDin.envmatches your intended calendarGet correct Calendar ID from Google Calendar Settings → Integrate calendar
Restart Claude Desktop after changing
.envSee Calendar Guide for detailed instructions
Permission Denied
Problem: "Insufficient permission" when creating/updating events
Solution:
Re-authorize with correct scope: delete
.credentials/token.jsonand retryVerify OAuth consent screen includes
calendar.eventsscopeCheck you have edit permissions on the target calendar
Obsidian Links Not Working
Problem: Clicking event in Google Calendar doesn't open note
Solution:
Verify
OBSIDIAN_VAULT_URL_BASEexactly matches your vault name (Settings → About)Include proper format:
obsidian://open?vault=VaultName&file=Check vault name capitalization and spaces
Ensure Obsidian is installed and vault is open
For complete calendar documentation, see docs/CALENDAR.md and docs/EXAMPLES.md.
Limitations
File Types: Only
.mdand.canvasfiles by defaultNo Live Updates: Changes to vault require server restart to reflect in list operations
Link Resolution: Basic wikilink resolution (no support for aliases yet)
Batch Size: Batch operations limited to 50 notes per operation
Roadmap
Write operations (create, update, delete notes)
Backlinks and forward links support
Daily notes integration
Template system
Graph data resources
Google Calendar integration with bidirectional linking
Batch operations with async I/O optimization
Real-time vault monitoring
Canvas file support improvements
Attachment handling
Advanced link resolution (aliases, headings)
Caching for improved performance
Contributing
Contributions are welcome! Please:
Fork the repository
Create a feature branch
Write tests for new functionality
Ensure all tests pass (
make test-all)Run quality checks (
make quality)Submit a pull request
License
MIT License - see LICENSE file for details
Acknowledgments
Built with Model Context Protocol
Designed for Obsidian
Inspired by the knowledge management community
Available Tools
31 toolsappend_to_noteC
Append content to an existing note
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose permissions needed, whether appending is reversible, rate limits, or how it handles errors (e.g., if the note doesn't exist). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It's appropriately sized for the tool's complexity and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, 0% schema coverage, but an output schema exists, the description is incomplete. It covers the basic purpose but lacks usage guidelines, parameter details, and behavioral context. The output schema mitigates some gaps, but overall it's minimal for a tool with siblings and operational complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only implies parameters ('content' and 'path' from context) without explaining their semantics. It doesn't clarify what 'path' refers to (e.g., file path, note ID) or 'content' format (e.g., text, markdown). Baseline is 3 due to 0% coverage, but it adds minimal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Append content to an existing note' clearly states the action (append) and resource (note), but it's vague about scope and doesn't differentiate from siblings like 'update_note' or 'batch_append_notes'. It specifies 'existing' note but lacks details on format or limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'update_note' for modifications or 'create_note' for new notes. The description implies it's for appending to existing notes but doesn't mention prerequisites, exclusions, or sibling tools like 'batch_append_notes' for multiple operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
batch_append_notesC
Append content to multiple notes atomically
| Name | Required | Description | Default |
|---|---|---|---|
| appends | Yes | ||
| confirm | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'atomically' which hints at transactional behavior (all-or-nothing execution), but fails to disclose critical details like required permissions, rate limits, error handling, or what 'content' means (e.g., text formatting, metadata). For a batch mutation tool, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core action ('Append content') and key qualifiers ('multiple notes', 'atomically'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch mutation with 2 parameters, no annotations, but has an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for that in the description. However, for a batch operation, more context on usage, parameters, and behavioral traits would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'appends' implicitly but doesn't explain what 'NoteAppend' entails (e.g., note identifiers, content format) or the purpose of the 'confirm' parameter (e.g., safety confirmation). The description adds minimal value beyond the parameter names visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append content') and target ('multiple notes'), and specifies 'atomically' which distinguishes it from the sibling tool 'append_to_note' that likely handles single notes. However, it doesn't explicitly name the resource type (e.g., 'notes in a vault' or similar context), leaving some ambiguity about what 'notes' refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'append_to_note' (for single notes) or 'batch_update_notes' (for other batch operations). It mentions 'atomically' which implies transactional safety, but doesn't explain practical scenarios or prerequisites for using batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
batch_update_notesB
Update multiple notes atomically with automatic backup and rollback
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| dry_run | No | ||
| updates | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: atomic updates (all-or-nothing), automatic backup, and rollback capability. However, it lacks details on permissions, rate limits, error handling, or what 'atomically' entails in practice, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose ('Update multiple notes atomically') and adds value with behavioral context ('with automatic backup and rollback'), making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters, 0% schema coverage, no annotations, but an output schema, the description is incomplete. It covers atomicity and backup/rollback but misses parameter guidance, error details, and sibling differentiation. The output schema mitigates some gaps, but overall it's minimally adequate with clear deficiencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter-specific information. It implies 'updates' parameter usage but doesn't explain the NoteUpdate structure, 'confirm' for safety, or 'dry_run' for testing. The description fails to bridge the schema's documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update multiple notes atomically') and resource ('notes'), distinguishing it from single-note tools like 'update_note' or 'append_to_note'. However, it doesn't explicitly differentiate from 'batch_append_notes', which also handles multiple notes but for appending rather than updating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update_note' for single updates or 'batch_append_notes' for batch appends. It mentions 'automatic backup and rollback' but doesn't specify prerequisites or exclusions, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_calendar_eventC
Create a Google Calendar event linked to an Obsidian note
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| date | Yes | ||
| description | No | ||
| duration_minutes | No | ||
| note_path | Yes | ||
| time | Yes | ||
| title | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates events but lacks details on permissions required, whether events are public/private, error handling, or what 'linked' entails (e.g., bidirectional sync). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary elaboration. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks parameter semantics, behavioral context, and usage guidelines, leaving critical gaps for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'note_path' expects, how 'date' and 'time' should be formatted, or the purpose of the 'confirm' parameter. With 7 parameters undocumented in both schema and description, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('Google Calendar event linked to an Obsidian note'), making the purpose immediately understandable. It distinguishes from siblings like 'create_note' by specifying the calendar integration, though it doesn't explicitly contrast with 'update_calendar_event' or 'delete_calendar_event'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_note' for standalone notes or 'update_calendar_event' for modifying existing events. The description implies usage for creating calendar events with note links but offers no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_from_templateC
Create a new note from a template
| Name | Required | Description | Default |
|---|---|---|---|
| new_note_path | Yes | ||
| template_path | Yes | ||
| title | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'create' implying a write operation, but doesn't disclose behavioral traits like whether it overwrites existing files, requires specific permissions, handles errors (e.g., invalid paths), or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It covers the basic purpose but lacks parameter details, behavioral context, and usage guidelines. The output schema helps, but the description should do more to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'template' and 'new note' but doesn't explain what the parameters represent (e.g., 'new_note_path' is the destination file path, 'template_path' is the source template file, 'title' is optional content). Without this, users might not understand how to provide valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'new note from a template', which is specific and actionable. It distinguishes from generic 'create_note' by specifying template-based creation, though it doesn't explicitly differentiate from all siblings like 'list_templates' or 'read_note'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_note' (for non-template creation) or 'list_templates' (to find templates). There's no mention of prerequisites, such as needing an existing template file, or context for template-based workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_noteC
Create a new note in the vault
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| overwrite | No | ||
| path | Yes | ||
| tags | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Create') but doesn't describe what happens on success/failure, whether the note becomes immediately available, what permissions are required, or how the 'overwrite' parameter affects behavior. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that gets straight to the point. There's no wasted language or unnecessary elaboration. It's appropriately sized for a basic creation operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values) and no annotations, the description is minimally complete for stating the core action. However, for a 4-parameter mutation tool with 0% schema coverage and no behavioral annotations, it should provide more context about parameter usage and operational behavior to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 4 parameters, the description provides no information about parameter meanings. It doesn't explain what 'path' format is expected, what 'content' should contain, how 'tags' should be structured, or when 'overwrite' should be used. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('a new note in the vault'), making the purpose immediately understandable. It distinguishes from siblings like 'append_to_note' or 'update_note' by specifying creation rather than modification. However, it doesn't explicitly differentiate from 'create_from_template' which is also a creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'create_note' over 'create_from_template' or 'append_to_note', nor does it indicate any prerequisites or contextual constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_calendar_eventC
Delete a Google Calendar event
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| event_id | Yes | ||
| update_note | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive mutation, but the description doesn't specify if deletion is permanent, requires specific permissions, sends notifications, or has rate limits. It also doesn't explain the role of parameters like 'confirm' or 'update_note' in the deletion behavior, leaving critical operational details unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action without unnecessary words. It's appropriately sized for a simple tool, with zero waste or redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive mutation tool with 3 parameters, 0% schema coverage, no annotations, and an output schema (which might help with return values), the description is incomplete. It lacks essential details like behavioral traits, parameter explanations, and usage context, making it inadequate for safe and effective tool invocation by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate by explaining parameters. It adds no meaning beyond the schema—it doesn't clarify what 'event_id' refers to, why 'confirm' is needed, or what 'update_note' does. With 3 parameters and no schema descriptions, this leaves significant gaps in understanding how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('Google Calendar event'), making the purpose immediately understandable. It distinguishes from siblings like 'update_calendar_event' or 'get_calendar_event' by specifying deletion. However, it doesn't explicitly mention what distinguishes it from 'delete_note' (a different resource type), so it's not fully specific about sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing event_id), when not to use it (e.g., for soft deletion), or refer to siblings like 'update_calendar_event' for modifications. Without such context, the agent must infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_noteB
Delete a note (moves to .trash by default)
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| permanent | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that deletion typically moves notes to .trash unless 'permanent' is set, which is useful context about the tool's default safety behavior. However, it lacks details on permissions, error handling, or what the output schema might return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that efficiently conveys the core action and a key behavioral detail (default trash behavior). Every word earns its place, with no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and no annotations, the description is moderately complete. It covers the basic purpose and a critical behavioral trait, but as a mutation tool with 2 parameters, it should ideally include more about usage context or parameter details to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies the 'permanent' parameter's effect (default false means moves to trash), adding meaning beyond the schema. However, it doesn't explain the 'path' parameter or provide full parameter context, leaving gaps in documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a note'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from other deletion tools (like 'delete_calendar_event') beyond mentioning notes, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'delete_calendar_event' or other note-related tools. It mentions the default behavior (moves to .trash), but doesn't specify scenarios or prerequisites for use, leaving usage context vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_backlinksA
Get all notes that link to a specific note (incoming links)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function without mentioning permissions, rate limits, pagination, or response format. For a read operation with no annotation coverage, this is insufficient to inform the agent about key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core purpose. Every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It states the purpose clearly but lacks details on parameters, behavioral context, or usage nuances. The presence of an output schema reduces the need to explain return values, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not mention any parameters, leaving both 'path' and 'limit' unexplained. The baseline is 3 because the schema provides full structure, but the description adds no semantic meaning beyond what the schema already defines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get all notes that link to') and resource ('a specific note'), explicitly distinguishing it from sibling tools like 'get_outgoing_links' by specifying 'incoming links' in parentheses. This provides precise differentiation from related tools in the server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'incoming links,' which suggests when to use this tool versus alternatives like 'get_outgoing_links.' However, it lacks explicit guidance on when not to use it or comparisons with other tools like 'get_related_otes' or 'get_link_graph,' leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_calendar_eventB
Get details of a specific calendar event by ID
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves details but doesn't disclose behavioral traits such as required permissions, error handling, rate limits, or what details are included in the output. This is a significant gap for a read operation with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core purpose. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), low complexity (1 parameter), and no annotations, the description is minimally adequate. However, it lacks context on usage versus siblings and behavioral details, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'event_id' is used to identify a calendar event, but doesn't provide format, examples, or constraints beyond what the schema's title ('Event Id') implies. This partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('specific calendar event'), making the purpose unambiguous. It distinguishes from siblings like 'list_calendar_events' by specifying retrieval of a single event by ID, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_calendar_events' or 'search_calendar_events'. The description implies usage for retrieving a known event by ID, but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_daily_noteC
Get or create a daily note for a specific date
| Name | Required | Description | Default |
|---|---|---|---|
| create | No | ||
| date_str | No | ||
| folder | No | Daily Notes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool can 'Get or create' a daily note, implying it may perform a write operation if creation is needed, but doesn't specify permissions required, whether creation is automatic or conditional, error handling, or response format. This is a significant gap for a tool with potential mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently communicates the core functionality, earning a perfect score for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values), the description's main gap is in parameter semantics and behavioral transparency. However, with no annotations and 0% schema coverage, the description is incomplete for a tool that might create resources. It's minimally adequate but lacks critical details for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the parameters (e.g., what 'date_str' format to use, what 'folder' represents, or how 'create' affects behavior). It fails to compensate for the lack of schema documentation, leaving parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get or create') and resource ('daily note for a specific date'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'list_daily_notes' or 'read_note', which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify when to use 'get_daily_note' instead of 'list_daily_notes' or 'read_note', or mention any prerequisites or exclusions, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_link_graphB
Get the link graph for the vault
| Name | Required | Description | Default |
|---|---|---|---|
| max_notes | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but lacks details on what the link graph includes (e.g., nodes, edges, format), whether it's read-only or has side effects, performance considerations, or error handling. This leaves significant gaps for a tool that likely returns complex data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely complexity (returning a link graph) and the presence of an output schema, the description is minimally adequate. It states what the tool does but lacks context on the graph's structure or use cases. The output schema should cover return values, but more behavioral context would help the agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, which is acceptable since there's only one optional parameter ('max_notes') with a default value. With 0% schema description coverage, the description doesn't need to compensate, as the parameter is straightforward and optional. The baseline for 0 parameters is 4, reflecting that no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get[s] the link graph for the vault', which provides a clear verb ('Get') and resource ('link graph for the vault'). However, it doesn't differentiate from sibling tools like 'get_backlinks' or 'get_outgoing_links', leaving ambiguity about what distinguishes this graph from other link-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools like 'get_backlinks' or 'get_outgoing_links', leaving the agent to infer usage scenarios independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_notes_by_tagB
Find all notes with a specific tag
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| tag | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool finds notes but doesn't cover critical aspects like whether it's read-only, if it has side effects, rate limits, authentication needs, or pagination behavior. For a retrieval tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core functionality without unnecessary details, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is minimally adequate. It states the purpose but lacks behavioral details and parameter guidance. The presence of an output schema means return values are documented elsewhere, but the description should still cover usage context and limitations to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a specific tag,' which aligns with the 'tag' parameter in the input schema. However, schema description coverage is 0%, and the description doesn't explain the 'limit' parameter or provide additional context like tag format or search scope. It adds minimal value beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find all notes with a specific tag.' It specifies the verb ('find'), resource ('notes'), and filtering criterion ('with a specific tag'). However, it doesn't explicitly differentiate from sibling tools like 'search_notes' or 'list_notes,' which may also involve note retrieval, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_notes' or 'list_notes,' nor does it specify scenarios where tag-based filtering is preferred over other methods. This lack of context leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_orphaned_notesA
Find notes with no incoming or outgoing links
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but omits critical details such as whether this is a read-only operation, how results are ordered, if pagination is supported, or what happens when limit is exceeded. For a tool with output schema, some behavior is implied, but key operational traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core purpose and avoids unnecessary elaboration, making it easy for an agent to parse quickly. Every word earns its place by directly contributing to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (finding orphaned notes), no annotations, and an output schema that likely covers return values, the description is minimally adequate. It states the purpose clearly but lacks context on behavior, usage scenarios, or limitations. The presence of an output schema reduces the need to explain returns, but more operational guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the input schema, which has 0% description coverage. However, with only one parameter (limit) and a default value of 50, the schema is minimal and self-explanatory. The description does not need to compensate heavily, but it could have clarified the limit's effect (e.g., on performance or result truncation). Baseline is 4 due to low parameter complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find') and target resource ('notes with no incoming or outgoing links'), which distinguishes it from sibling tools like get_backlinks, get_outgoing_links, or get_related_notes that focus on linked notes. It precisely defines the scope of orphaned notes without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_notes, search_notes, or get_notes_by_tag. It does not mention prerequisites, exclusions, or typical use cases, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_outgoing_linksB
Get all links from a note to other notes (outgoing links)
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('Get'), implying non-destructive behavior, but doesn't disclose permissions, rate limits, output format, or error handling. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core purpose, zero waste. Efficiently conveys the essential action without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, but an output schema exists, the description is minimally adequate. It covers the basic purpose but lacks behavioral details and parameter guidance, leaving gaps for a tool with one required parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'from a note' which hints at the 'path' parameter referring to a note, but doesn't specify format (e.g., file path, note title) or constraints. This adds minimal meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all links from a note to other notes'), specifying outgoing links. It distinguishes from sibling 'get_backlinks' by directionality, though not explicitly named. It's not fully specific about scope (e.g., format or depth), keeping it at 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_backlinks' (for incoming links) or 'get_link_graph' (for broader link analysis). The description implies usage for outgoing links only, but lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vault_statsB
Get statistics about the vault
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('Get'), implying non-destructive behavior, but does not disclose any behavioral traits such as performance impact, data freshness, or authentication needs. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, output schema exists), the description is minimally adequate. However, with no annotations and an output schema, it fails to explain what statistics are returned or any behavioral context, leaving gaps in completeness for a stats-retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add param info, which is appropriate, earning a baseline score of 4 for adequately handling the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get statistics about the vault' clearly states the verb ('Get') and resource ('vault'), but it is vague about what specific statistics are retrieved (e.g., counts, sizes, usage). It distinguishes from siblings by focusing on vault-level stats rather than notes or events, but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, timing, or comparisons to other tools (e.g., for note-level stats). The description alone offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_all_tagsB
Get all tags in the vault with usage counts
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'usage counts' which adds some behavioral context, it doesn't address important aspects like whether this is a read-only operation, potential performance considerations for large vaults, pagination behavior, or what format the output takes. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's front-loaded with the essential information and doesn't include unnecessary elaboration. Every word earns its place in this concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and only one parameter with a default, the description is minimally adequate. However, it doesn't provide enough behavioral context for a tool with no annotations. The mention of 'usage counts' adds some value, but more context about the operation's characteristics would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 1 parameter and 0% schema description coverage, the description doesn't mention the 'limit' parameter at all. However, since there's only one parameter and it has a default value, the impact is reduced. The description focuses on what the tool returns rather than its inputs, which is reasonable for a simple list operation. A baseline of 4 is appropriate for a tool with zero parameters mentioned but only one actual parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all tags in the vault') along with additional context about 'usage counts'. It distinguishes from sibling tools like 'get_notes_by_tag' which filters notes by tag rather than listing tags themselves. However, it doesn't explicitly differentiate from all possible tag-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this tool is appropriate versus other tag-related operations or list operations. The sibling tools include 'get_notes_by_tag' which has a related but different purpose, but the description doesn't help the agent choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_batch_backupsB
List available batch backups
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic action without describing what 'available' means, whether results are paginated, sorted, or filtered, what authentication is required, or what the output format looks like. This leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, front-loading the essential action and resource. There's zero wasted language or redundancy, making it maximally efficient while still communicating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and only one simple parameter, the description's minimalism is somewhat acceptable. However, for a data listing operation with no annotations, it should ideally provide more context about what constitutes 'available' backups and how results are presented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema has one parameter ('limit') with 0% description coverage. Since the schema provides the parameter definition but no semantic context, and the description adds nothing about parameters, this meets the baseline for minimal parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('available batch backups'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'restore_batch_backup' or explain what distinguishes batch backups from other backup types in the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'restore_batch_backup' or other list operations. There's no mention of prerequisites, typical use cases, or when this specific listing function is appropriate versus other data retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_calendar_eventsB
List upcoming Google Calendar events
| Name | Required | Description | Default |
|---|---|---|---|
| days_ahead | No | ||
| max_results | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('List upcoming') but doesn't mention authentication requirements, rate limits, pagination behavior, error conditions, or what 'upcoming' means relative to current time. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing with filtering), no annotations, and an output schema that presumably covers return values, the description is minimally adequate. It states what the tool does but lacks important context about behavior, parameters, and differentiation from siblings. The existence of an output schema prevents this from being a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so parameters are only documented by their titles and types. The description doesn't mention either parameter, providing no additional semantic meaning beyond what's in the schema. However, with only 2 parameters and default values provided in the schema, the baseline is 3 as the schema provides basic documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('Google Calendar events') with a qualifier ('upcoming'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'search_calendar_events', which could serve a similar purpose with different filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_calendar_events' or 'get_calendar_event'. It lacks any context about prerequisites, appropriate scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_daily_notesC
List recent daily notes
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Daily Notes | |
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits like whether it's read-only, if it requires authentication, rate limits, or how 'recent' is defined (e.g., by date or count). It mentions 'recent' but doesn't clarify if this is based on creation date, modification, or another criterion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase 'List recent daily notes', which is front-loaded and wastes no words. Every part of the sentence contributes to the core purpose, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 2 parameters with low schema coverage, and no annotations, the description is minimally adequate but incomplete. It states what the tool does but lacks details on behavior, parameter usage, and differentiation from siblings, leaving gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, so the description must compensate but adds no parameter details. It doesn't explain what 'folder' or 'limit' mean, their defaults, or how they affect the listing. Since there are parameters, the baseline is not automatically 4, and the description fails to provide meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List recent daily notes' clearly states the verb ('List') and resource ('daily notes'), but lacks specificity about what constitutes 'recent' and doesn't differentiate from sibling tools like 'list_notes' or 'get_daily_note'. It's better than a tautology but remains vague in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_notes', 'get_daily_note', or 'search_notes'. The description implies a focus on daily notes but doesn't specify context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_notesC
List notes in the vault with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | ||
| limit | No | ||
| recursive | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists notes with filters but does not describe key behaviors such as pagination (implied by 'limit' parameter), default sorting, error handling, or whether it returns metadata or full content. This leaves significant gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 notes in the vault') and adds essential qualification ('with optional filters'). There is no wasted language, and it is appropriately sized for a basic listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is incomplete. It covers the basic purpose but lacks details on behavior, parameter usage, and differentiation from siblings. The presence of an output schema mitigates the need to describe return values, but other gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'optional filters' but does not specify what parameters are available or their meanings. With 0% schema description coverage and 3 parameters (folder, limit, recursive), the schema provides titles but no descriptions. The description adds minimal value by hinting at filtering but fails to compensate for the low schema coverage, resulting in inadequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'List notes in the vault with optional filters', which clearly indicates it retrieves notes with filtering capabilities. However, it does not differentiate from sibling tools like 'search_notes', 'get_notes_by_tag', or 'list_daily_notes', leaving ambiguity about when to use this specific listing tool versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'optional filters' but does not specify what types of filters are available or how they compare to filtering in sibling tools like 'search_notes'. There is no mention of prerequisites, exclusions, or recommended contexts for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesB
List available note templates
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Templates |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states it 'lists' templates, implying a read-only operation, but doesn't cover critical aspects like whether it requires authentication, returns paginated results, includes metadata (e.g., template names or descriptions), or how it interacts with the 'folder' parameter. For a tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'List available note templates'. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it lacks context on behavioral traits and usage scenarios, making it just sufficient but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what the input schema provides. With 0% schema description coverage and one parameter ('folder'), the schema alone defines it as a string with default 'Templates'. The description doesn't explain what 'folder' means (e.g., a directory path, a category) or its effect, so it doesn't compensate for the low coverage, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available note templates' clearly states the action (list) and resource (note templates), making the purpose immediately understandable. However, it doesn't distinguish this tool from other list-like siblings such as 'list_notes', 'list_all_tags', or 'list_calendar_events', which would require specifying what makes templates unique (e.g., predefined note structures).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_notes' and 'create_from_template', there's no indication whether this is for browsing templates before creation, checking what's available, or other contexts. The lack of when/when-not statements leaves usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_noteB
Read the full content of a note from the vault
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Read') but doesn't cover important aspects like permissions needed, error handling, or what happens if the note doesn't exist. This is a significant gap for a tool that likely interacts with a data vault.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple read operation, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is reasonably complete. It covers the basic action and resource, though it could benefit from more behavioral context, especially since no annotations are provided to fill in gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the 'path' parameter refers to a note in the vault, which clarifies beyond the schema's generic 'Path' title. With 0% schema description coverage and only one parameter, this compensates adequately, though it could provide more detail on path format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resource ('full content of a note from the vault'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_note' or 'search_notes', which might have overlapping functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_notes' or 'search_notes'. It lacks context about prerequisites or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
restore_batch_backupB
Restore notes from a batch backup (undo batch operation)
| Name | Required | Description | Default |
|---|---|---|---|
| backup_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'restore' and 'undo,' implying a write operation, but doesn't specify permissions needed, whether it's destructive, rate limits, or what happens to current notes. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loaded with the tool's purpose. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations), the description is incomplete—it lacks details on behavior, parameters, and output. However, an output schema exists, so return values are covered elsewhere, preventing a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters, and schema coverage is 0%, leaving the single parameter 'backup_id' undocumented. However, with only one parameter, the baseline is 4, but the description fails to compensate for the lack of schema info, so it's scored lower for not adding any meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('restore') and resource ('notes from a batch backup'), specifying it's for undoing batch operations. However, it doesn't differentiate from potential sibling tools like 'list_batch_backups' or explain what a 'batch backup' entails, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for undoing batch operations but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'list_batch_backups' to see available backups, 'batch_update_notes' for batch changes). It lacks prerequisites or exclusions, offering minimal context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_propertyB
Search for notes by frontmatter property (metadata field)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| property_name | Yes | ||
| property_value | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether it's read-only, pagination behavior, rate limits, authentication needs, or what happens with partial matches. The presence of an output schema helps but isn't mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and uses parentheses for clarification without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, 0% schema coverage, and no annotations, the description is minimal. The output schema existence reduces need to explain returns, but more context on usage, parameters, and behavior would improve completeness. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only mentions 'frontmatter property (metadata field)', which loosely relates to 'property_name'. It doesn't explain the three parameters (property_name, property_value, limit), their formats, or interactions. Baseline 3 is appropriate as it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('notes'), specifying the search criteria ('by frontmatter property/metadata field'). It distinguishes from generic 'search_notes' by focusing on frontmatter properties, but doesn't explicitly differentiate from other property-related tools like 'update_frontmatter'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_notes', 'get_notes_by_tag', or 'update_frontmatter'. The description implies it's for searching by metadata fields, but doesn't specify scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_calendar_eventsC
Search calendar events by text query or date range
| Name | Required | Description | Default |
|---|---|---|---|
| date_from | No | ||
| date_to | No | ||
| max_results | No | ||
| query | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation, what permissions are needed, how results are returned (e.g., pagination), rate limits, or error conditions. The phrase 'search' implies read-only, but this isn't explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('search calendar events by text query or date range') contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, but has output schema), the description is incomplete. It covers the basic purpose but lacks usage guidelines, detailed parameter semantics, and behavioral context. The output schema helps mitigate some gaps in return value explanation, but overall it's minimally adequate with clear deficiencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only vaguely references parameters ('text query or date range'). It doesn't explain what 'date_from' and 'date_to' represent (e.g., format, timezone), what 'max_results' defaults to or its limits, or how 'query' interacts with date filtering. This leaves significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and resource 'calendar events', specifying the search criteria as 'by text query or date range'. This distinguishes it from other calendar-related tools like 'list_calendar_events' or 'get_calendar_event', though it doesn't explicitly mention those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_calendar_events' or 'search_notes'. It mentions search criteria but doesn't specify scenarios, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_notesC
Search the vault by content, title, tags, or all
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | ||
| limit | No | ||
| query | Yes | ||
| search_type | No | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to describe key behaviors: whether this is a read-only operation (implied but not stated), what the output format is (though an output schema exists), whether results are paginated or limited (the 'limit' parameter suggests limiting but not described), or any performance/rate-limiting considerations. For a search tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and uses parallel structure ('content, title, tags, or all'). Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with 4 parameters) and no annotations, the description is incomplete. It covers the purpose and one parameter indirectly but lacks behavioral context, usage guidelines, and details on most parameters. The existence of an output schema reduces the need to describe return values, but other gaps remain. This is minimally adequate but with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions searchable fields (content, title, tags, or all), which maps to the 'search_type' enum parameter, adding some semantics. However, it doesn't explain the 'query', 'folder', or 'limit' parameters, leaving three of four parameters with minimal context. The baseline is 3 because it adds value for one parameter but doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('search') and resource ('the vault'), specifying what fields can be searched (content, title, tags, or all). It distinguishes from siblings like 'list_notes' (which lists without search) and 'search_by_property' (which searches by property rather than content/title/tags). However, it doesn't explicitly mention that it searches notes specifically, though this is implied by context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'search_notes' over 'list_notes' (for listing without query), 'get_notes_by_tag' (for tag-specific retrieval), or 'search_by_property' (for property-based search). There's no context about prerequisites, performance implications, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_calendar_eventC
Update/move a calendar event (change date, time, title, or description)
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| date | No | ||
| description | No | ||
| duration_minutes | No | ||
| event_id | Yes | ||
| location | No | ||
| time | No | ||
| title | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool updates or moves events but doesn't describe permissions required, whether changes are reversible, error handling (e.g., for invalid event IDs), rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('update/move a calendar event') and lists key modifiable fields. There's no wasted verbiage, but it could be slightly more structured by separating usage context from parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 8 parameters), lack of annotations, and presence of an output schema, the description is minimally adequate. It states the purpose but lacks usage guidelines, detailed parameter semantics, and behavioral context. The output schema may cover return values, but the description doesn't address mutation risks or prerequisites, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'change date, time, title, or description,' which covers only 4 of the 8 parameters (date, time, title, description), ignoring event_id, confirm, duration_minutes, and location. It doesn't explain parameter interactions, defaults, or required fields, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update/move') and resource ('calendar event'), and lists specific fields that can be modified (date, time, title, description). It distinguishes from sibling tools like 'create_calendar_event' and 'delete_calendar_event' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from 'update_note' or other update tools in terms of resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing event ID), compare to sibling tools like 'update_note' or 'update_frontmatter', or specify scenarios where this tool is preferred over others. Usage is implied through the action but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_frontmatterB
Update frontmatter fields in a note (preserves content)
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| property_name | Yes | ||
| property_value | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions 'preserves content' which is useful behavioral context, but doesn't address permissions needed, whether changes are reversible, error conditions, or what the output contains. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. Every word contributes: 'Update' (action), 'frontmatter fields' (scope), 'in a note' (target), 'preserves content' (behavioral detail). Perfectly front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no annotations, but with an output schema present, the description provides basic purpose and one behavioral detail. It's minimally adequate for understanding what the tool does, but lacks guidance, full parameter context, and comprehensive behavioral disclosure expected for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds context that parameters update 'frontmatter fields' and that content is preserved, giving meaning to what the parameters affect. However, it doesn't explain parameter formats, constraints, or examples beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update frontmatter fields') and target ('in a note'), with the specific detail that it 'preserves content'. It distinguishes from generic 'update_note' by focusing on frontmatter fields specifically, though it doesn't explicitly contrast with all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'update_note' or 'batch_update_notes'. The description implies it's for frontmatter updates, but doesn't specify prerequisites, constraints, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_noteC
Update an existing note's content
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates content, implying a mutation operation, but doesn't cover critical aspects: whether it overwrites or merges content, permissions required, error handling (e.g., if path doesn't exist), or side effects. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('Update an existing note's content'), making it easy to parse. Every word contributes directly to the purpose, achieving optimal conciseness for such a brief statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), the description's minimalism is partially acceptable. However, as a mutation tool with no annotations and low parameter semantics, it should do more to explain behavior and usage. The description is complete enough for basic understanding but inadequate for safe, effective use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'content' but doesn't explain what 'path' is (e.g., file path, note identifier) or details like format constraints (e.g., markdown, plain text). It adds minimal value beyond the parameter names, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing note's content'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_note' (creates new) and 'append_to_note' (adds to existing), though it doesn't explicitly mention these distinctions. The description is specific but could be more precise about what 'content' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., note must exist), exclusions (e.g., cannot update non-existent notes), or comparisons to siblings like 'batch_update_notes' (for multiple notes) or 'update_frontmatter' (for metadata). Usage is implied only by the verb 'Update,' leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Most tools have distinct purposes, such as note operations (create, read, update, delete), calendar event management, and search functions. However, some overlap exists between 'search_notes' and 'search_by_property', and between 'get_backlinks' and 'get_outgoing_links', which could cause minor confusion for agents.
Tool names follow a consistent verb_noun pattern throughout, such as 'create_note', 'list_notes', 'update_note', and 'search_notes'. This predictability makes it easy for agents to understand and use the toolset effectively.
With 31 tools, the count is on the high side for an Obsidian server, which may feel heavy and potentially overwhelming. While it covers many features, a more streamlined set might improve usability without sacrificing functionality.
The toolset provides comprehensive coverage for Obsidian vault management, including full CRUD for notes and calendar events, advanced search capabilities, link analysis, batch operations with backup/restore, and vault statistics. No significant gaps are apparent for the domain.
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Personal wiki and memory layer for AI assistants. Persistent, structured memory across sessions.
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/getglad/obsidian_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server