Which integrations are available for this server?

Enables querying Markdown frontmatter data using DuckDB SQL, including support for complex queries with type casting, JSON array operations, and semantic search with vector embeddings. Provides tools for querying, updating, and managing frontmatter metadata in Markdown files, including batch operations for properties and array manipulation across multiple files. Supports querying and updating frontmatter in Obsidian vaults with graceful handling of Templater expressions, enabling automated metadata management across Obsidian notes.

How do I use Frontmatter MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Frontmatter MCP find all markdown files with 'project' tag from this year" 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.

Frontmatter MCP

by kzmshx

Overview Schema Related Servers Score Discussions

Python

Local

frontmatter-mcp

An MCP server for querying Markdown frontmatter with DuckDB SQL.

Configuration

Basic Usage

{
  "mcpServers": {
    "frontmatter": {
      "command": "uvx",
      "args": ["frontmatter-mcp"],
      "env": {
        "FRONTMATTER_BASE_DIR": "/path/to/markdown/directory"
      }
    }
  }
}

With Semantic Search

Semantic search requires large dependencies (~1GB). Set MCP_TIMEOUT to extend installation timeout:

{
  "mcpServers": {
    "frontmatter": {
      "command": "uvx",
      "args": ["--from", "frontmatter-mcp[semantic]", "frontmatter-mcp"],
      "env": {
        "FRONTMATTER_BASE_DIR": "/path/to/markdown/directory",
        "FRONTMATTER_ENABLE_SEMANTIC": "true",
        "MCP_TIMEOUT": "300000"
      }
    }
  }
}

Note: MCP_TIMEOUT is in milliseconds (300000 = 5 minutes).

Related MCP server: knowledgebased

Installation (Optional)

If you prefer to install globally:

pip install frontmatter-mcp
# or
uv tool install frontmatter-mcp

Tools

query_inspect

Get schema information from frontmatter across files.

Parameter	Type	Description
`glob`	string	Glob pattern relative to base directory

Example:

// Input
{ "glob": "**/*.md" }

// Output
{
  "file_count": 186,
  "schema": {
    "date": { "type": "string", "count": 180, "nullable": true },
    "tags": { "type": "array", "count": 150, "nullable": true }
  }
}

// Output (with semantic search ready)
{
  "file_count": 186,
  "schema": {
    "date": { "type": "string", "count": 180, "nullable": true },
    "tags": { "type": "array", "count": 150, "nullable": true },
    "embedding": { "type": "FLOAT[256]", "nullable": false }
  }
}

query

Query frontmatter data with DuckDB SQL.

Parameter	Type	Description
`glob`	string	Glob pattern relative to base directory
`sql`	string	DuckDB SQL query referencing `files` table

Example:

// Input
{
  "glob": "**/*.md",
  "sql": "SELECT path, date FROM files WHERE date >= '2025-11-01' ORDER BY date DESC"
}

// Output
{
  "columns": ["path", "date"],
  "row_count": 24,
  "results": [
    {"path": "daily/2025-11-28.md", "date": "2025-11-28"},
    {"path": "daily/2025-11-27.md", "date": "2025-11-27"}
  ]
}

update

Update frontmatter properties in a single file.

Parameter	Type	Description
`path`	string	File path relative to base directory
`set`	object	Properties to add or overwrite
`unset`	string[]	Property names to remove

Example:

// Input
{ "path": "notes/idea.md", "set": {"status": "published"} }

// Output
{ "path": "notes/idea.md", "frontmatter": {"title": "Idea", "status": "published"} }

batch_update

Update frontmatter properties in multiple files.

Parameter	Type	Description
`glob`	string	Glob pattern relative to base directory
`set`	object	Properties to add or overwrite
`unset`	string[]	Property names to remove

Example:

// Input
{ "glob": "drafts/*.md", "set": {"status": "review"} }

// Output
{ "updated_count": 5, "updated_files": ["drafts/a.md", "drafts/b.md", ...] }

batch_array_add

Add a value to an array property in multiple files.

Parameter	Type	Description
`glob`	string	Glob pattern relative to base directory
`property`	string	Name of the array property
`value`	any	Value to add
`allow_duplicates`	bool	Allow duplicate values (default: false)

Example:

// Input
{ "glob": "**/*.md", "property": "tags", "value": "reviewed" }

// Output
{ "updated_count": 42, "updated_files": ["a.md", "b.md", ...] }

batch_array_remove

Remove a value from an array property in multiple files.

Parameter	Type	Description
`glob`	string	Glob pattern relative to base directory
`property`	string	Name of the array property
`value`	any	Value to remove

Example:

// Input
{ "glob": "**/*.md", "property": "tags", "value": "draft" }

// Output
{ "updated_count": 15, "updated_files": ["a.md", "b.md", ...] }

batch_array_replace

Replace a value in an array property in multiple files.

Parameter	Type	Description
`glob`	string	Glob pattern relative to base directory
`property`	string	Name of the array property
`old_value`	any	Value to replace
`new_value`	any	New value

Example:

// Input
{ "glob": "**/*.md", "property": "tags", "old_value": "draft", "new_value": "review" }

// Output
{ "updated_count": 10, "updated_files": ["a.md", "b.md", ...] }

batch_array_sort

Sort an array property in multiple files.

Parameter	Type	Description
`glob`	string	Glob pattern relative to base directory
`property`	string	Name of the array property
`reverse`	bool	Sort in descending order (default: false)

Example:

// Input
{ "glob": "**/*.md", "property": "tags" }

// Output
{ "updated_count": 20, "updated_files": ["a.md", "b.md", ...] }

batch_array_unique

Remove duplicate values from an array property in multiple files.

Parameter	Type	Description
`glob`	string	Glob pattern relative to base directory
`property`	string	Name of the array property

Example:

// Input
{ "glob": "**/*.md", "property": "tags" }

// Output
{ "updated_count": 5, "updated_files": ["a.md", "b.md", ...] }

index_status

Get the status of the semantic search index.

This tool is only available when FRONTMATTER_ENABLE_SEMANTIC=true.

Example:

// Output (not started)
{ "state": "idle" }

// Output (indexing in progress)
{ "state": "indexing" }

// Output (ready)
{ "state": "ready" }

index_refresh

Refresh the semantic search index (differential update).

This tool is only available when FRONTMATTER_ENABLE_SEMANTIC=true.

Example:

// Output
{ "state": "indexing", "message": "Indexing started", "target_count": 665 }

// Output (when already indexing)
{ "state": "indexing", "message": "Indexing already in progress" }

Technical Notes

All Values Are Strings

All frontmatter values are passed to DuckDB as strings. Use TRY_CAST in SQL for type conversion when needed.

SELECT * FROM files
WHERE TRY_CAST(date AS DATE) >= '2025-11-01'

Arrays Are JSON Strings

Arrays like tags: [ai, python] are stored as JSON strings '["ai", "python"]'. Use from_json() and UNNEST to expand them.

SELECT path, tag
FROM files, UNNEST(from_json(tags, '[""]')) AS t(tag)
WHERE tag = 'ai'

Templater Expression Support

Files containing Obsidian Templater expressions (e.g., <% tp.date.now("YYYY-MM-DD") %>) are handled gracefully. These expressions are treated as strings and naturally excluded by date filtering.

Semantic Search

When semantic search is enabled, you can use the embed() function and embedding column in SQL queries. After running index_refresh, the markdown body content is indexed as vectors.

-- Find semantically similar documents
SELECT path, 1 - array_cosine_distance(embedding, embed('feeling better')) as score
FROM files
ORDER BY score DESC
LIMIT 10

-- Combine with frontmatter filters
SELECT path, date, 1 - array_cosine_distance(embedding, embed('motivation')) as score
FROM files
WHERE date >= '2025-11-01'
ORDER BY score DESC
LIMIT 10

Environment variables:

Variable	Default	Description
FRONTMATTER_BASE_DIR	(required)	Base directory for files
FRONTMATTER_ENABLE_SEMANTIC	false	Enable semantic search
FRONTMATTER_EMBEDDING_MODEL	cl-nagoya/ruri-v3-30m	Embedding model name
FRONTMATTER_CACHE_DIR	FRONTMATTER_BASE_DIR/.frontmatter-mcp	Cache directory for embeddings

License

MIT

Available Tools

9 tools

batch_array_addA

Add a value to an array property in multiple files.

Args: glob: Glob pattern relative to base directory (e.g. "atoms/**/*.md"). property: Name of the array property. value: Value to add. If value is an array, it's added as a single element. allow_duplicates: If False (default), skip files where value already exists.

Returns: Dict with updated_count, updated_files, and warnings.

Notes: - If property doesn't exist, it will be created with [value]. - If property is not an array, file is skipped with a warning. - Files are only included in updated_files if actually modified.

ParametersJSON Schema

Name	Required	Description	Default
`glob`	Yes
`value`	Yes
`property`	Yes
`allow_duplicates`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description fully bears the burden. Discloses key behaviors: property creation if missing, skip warning if property not array, allow_duplicates effect, and return structure (updated_count, updated_files, warnings). Lacks only explicit mention of idempotency or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise and well-structured with Args, Returns, Notes sections. Every sentence adds value, no redundancy. Efficiently communicates all necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given tool complexity (4 params, 3 required), existence of output schema, and no annotations, the description covers all critical aspects: parameter roles, edge cases, return values, and behavioral notes. It is complete for an agent to correctly select and invoke the tool.

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

Parameters4/5

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

Schema description coverage is 0%, but description adds meaning: glob pattern relative to base directory, property name, value added as single element even if array, allow_duplicates default false. This compensates well for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool adds a value to an array property in multiple files. Uses specific verb 'Add' and resource 'array property in multiple files', distinguishing it from siblings like batch_array_remove or batch_array_replace.

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

Usage Guidelines3/5

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

Description provides behavior details (property creation, skip condition, deduplication) but does not explicitly compare to alternatives or state when not to use. Implicit usage guidance is present but not comprehensive.

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

batch_array_removeA

Remove a value from an array property in multiple files.

Args: glob: Glob pattern relative to base directory (e.g. "atoms/**/*.md"). property: Name of the array property. value: Value to remove.

Returns: Dict with updated_count, updated_files, and warnings.

Notes: - If property doesn't exist, file is skipped. - If value doesn't exist in array, file is skipped. - If property is not an array, file is skipped with a warning. - Files are only included in updated_files if actually modified.

ParametersJSON Schema

Name	Required	Description	Default
`glob`	Yes
`value`	Yes
`property`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries full burden. It lists return values (updated_count, updated_files, warnings) and clearly states three skip conditions, plus notes that files are only counted if modified. This fully discloses behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear structure: main sentence, Args/Returns/Notes sections. Every sentence provides value, no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (seen in context), the description does not need to detail return format further. It covers all necessary aspects: purpose, parameters, and behavioral notes, making it complete for a batch operation tool.

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

Parameters4/5

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

Schema coverage is 0% (no descriptions in schema), so description must compensate. It defines glob with example, property as 'Name of the array property', and value as 'Value to remove', adding significant meaning beyond the bare schema names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Remove a value from an array property in multiple files...' which is a specific verb+resource combo. It clearly distinguishes from siblings like batch_array_add (adds value) and batch_array_replace (replaces value).

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

Usage Guidelines4/5

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

The 'Notes' section provides detailed edge-case behavior (skipping if property missing, value missing, or property not an array), guiding the agent on when the tool has no effect. However, it does not explicitly compare with siblings or provide when-to-use vs alternatives.

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

batch_array_replaceA

Replace a value in an array property in multiple files.

Args: glob: Glob pattern relative to base directory (e.g. "atoms/**/*.md"). property: Name of the array property. old_value: Value to replace. new_value: New value.

Returns: Dict with updated_count, updated_files, and warnings.

Notes: - If property doesn't exist, file is skipped. - If old_value doesn't exist in array, file is skipped. - If property is not an array, file is skipped with a warning. - Files are only included in updated_files if actually modified.

ParametersJSON Schema

Name	Required	Description	Default
`glob`	Yes
`property`	Yes
`new_value`	Yes
`old_value`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

No annotations are provided, so the description fully covers behavioral traits: it details skipping conditions (property missing, old_value absent, property not array) and states that files are only included in updated_files if modified. This is comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for intro, arguments, returns, and notes. It is concise, with no unnecessary words, while covering all essential details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (batch file operation), the description covers all necessary aspects: purpose, parameters, return structure, and edge cases. The output schema exists and the description aligns with it. Sibling tools provide differentiation.

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

Parameters4/5

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

The input schema has 0% description coverage, but the description provides meaningful context for all parameters: glob pattern with example, property name, old_value, new_value. It adds value beyond the schema's bare type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it replaces a value in an array property in multiple files, with specific verb 'replace' and resource 'array property in multiple files'. It distinguishes from sibling tools like batch_array_add and batch_array_remove by focusing on replacement.

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

Usage Guidelines4/5

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

The description explains when to use the tool (replacing a value across files matching a glob) and provides notes on edge cases (e.g., skipping if property doesn't exist). It does not explicitly say when not to use or provide direct alternatives, but sibling tools are listed separately.

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

batch_array_sortA

Sort an array property in multiple files.

Args: glob: Glob pattern relative to base directory (e.g. "atoms/**/*.md"). property: Name of the array property. reverse: If True, sort in descending order. Default is ascending.

Returns: Dict with updated_count, updated_files, and warnings.

Notes: - If property doesn't exist, file is skipped. - If array is empty, file is skipped. - If array is already sorted, file is skipped. - If property is not an array, file is skipped with a warning. - Files are only included in updated_files if actually modified.

ParametersJSON Schema

Name	Required	Description	Default
`glob`	Yes
`reverse`	No
`property`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

The description details edge cases: skipping non-existent/empty/already sorted properties, warning on non-array. However, it doesn't disclose destructive nature or authorization needs, but with no annotations, the description compensates well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Args, Returns, Notes sections. It is concise with no redundant phrasing, and the purpose is front-loaded in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers parameter meanings and common edge cases. The output schema exists, so return details are provided. Missing info on atomicity or permissions, but acceptable for this tool.

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

Parameters5/5

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

With 0% schema coverage, the description fully explains each parameter: glob pattern, property name, reverse flag with default. Adds examples and context, exceeding the schema's bare names and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it sorts an array property in multiple files. This is specific and distinct from sibling tools like batch_array_add and batch_array_remove.

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

Usage Guidelines3/5

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

Usage is implied (sort arrays), but no explicit guidance on when to use vs alternatives. It doesn't mention prerequisites or situations where other batch tools would be preferable.

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

batch_array_uniqueA

Remove duplicate values from an array property in multiple files.

Args: glob: Glob pattern relative to base directory (e.g. "atoms/**/*.md"). property: Name of the array property.

Returns: Dict with updated_count, updated_files, and warnings.

Notes: - Preserves the order of first occurrence. - If property doesn't exist, file is skipped. - If array is empty or has single element, file is skipped. - If array has no duplicates, file is skipped. - If property is not an array, file is skipped with a warning. - Files are only included in updated_files if actually modified.

ParametersJSON Schema

Name	Required	Description	Default
`glob`	Yes
`property`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description fully covers behavioral traits: order preservation, skipping conditions (missing property, empty/single array, no duplicates), warning for non-array, and reporting only modified files. Returns structure is also specified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Args, Returns, and Notes sections. However, some notes are repetitive (e.g., multiple 'file is skipped' conditions), making it slightly less concise than ideal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all relevant edge cases and behavior for a batch operation. With an output schema present (not shown but indicated), the agent has sufficient context to use the tool correctly.

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

Parameters4/5

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

Schema coverage is 0%, but the description adds meaning by explaining both parameters: glob pattern with example, and property as array property name. This compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Remove duplicate values from an array property in multiple files.' It specifies verb and resource, and is distinct from sibling tools like batch_array_add or batch_array_sort.

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

Usage Guidelines3/5

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

The description lacks explicit guidance on when to use this tool versus alternatives. While the name and notes imply its specific use case (deduplication), there is no 'when not to use' or comparison to other batch_array_ tools.

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

batch_updateA

Update frontmatter properties in multiple files matching glob pattern.

Args: glob: Glob pattern relative to base directory (e.g. "atoms/**/*.md"). set: Properties to add or overwrite in all matched files. unset: Property names to remove from all matched files.

Returns: Dict with updated_count, updated_files, and warnings.

Notes: - If same key appears in both set and unset, unset takes priority. - If a file has no frontmatter, it will be created. - Errors in individual files are recorded in warnings, not raised.

ParametersJSON Schema

Name	Required	Description	Default
`set`	No
`glob`	Yes
`unset`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

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

The description discloses key behaviors: unset takes priority over set, frontmatter creation, and error recording as warnings. With no annotations, this provides sufficient transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, well-structured with Args/Returns/Notes, and front-loads the main action. Every sentence provides value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description thoroughly covers the tool's purpose, parameters, return value, and edge cases (e.g., frontmatter creation, warnings), making it complete for an agent to use.

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

Parameters5/5

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

The description adds significant meaning beyond the input schema, explaining each parameter (glob, set, unset) with examples and behavior, despite 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool updates frontmatter properties in multiple files using a glob pattern, which distinguishes it from sibling tools like 'update' (single file) and other batch operations.

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

Usage Guidelines4/5

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

The description provides context such as glob pattern usage and notes on priority and error handling, but does not explicitly state when not to use this tool or compare it to alternatives.

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

queryA

Query frontmatter with DuckDB SQL.

Args: glob: Glob pattern relative to base directory (e.g. "atoms/**/*.md"). sql: SQL query string. Reference 'files' table. Columns are frontmatter properties plus 'path'.

Semantic search (when enabled and indexing is complete): - embedding: document embedding vector (NULL if not indexed) - embed('text'): converts text to embedding vector - array_cosine_similarity(a, b): similarity score (0-1)

Example - find similar documents:
    SELECT path,
           array_cosine_similarity(embedding, embed('search term')) as score
    FROM files WHERE embedding IS NOT NULL
    ORDER BY score DESC LIMIT 10

Returns: Dict with results array, row_count, and columns.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes
`glob`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses return format (dict with `results`, `row_count`, `columns`) and semantic search capabilities. Behaviors like read-only nature are implied but not stated; no mention of auth needs or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with bullet points for semantic search and an example. Front-loaded with purpose. Slightly verbose but each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists (true), description still explains return values. Covers all parameters, semantic search conditions, and example. Complete for a query tool with distinct sibling tools (update, batch, etc.).

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

Parameters5/5

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

Schema coverage is 0%, so description must compensate. It clearly explains `glob` (glob pattern relative to base directory) and `sql` (SQL query string referencing the `files` table), adding meaning beyond the schema's bare type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Query frontmatter with DuckDB SQL,' specifying the resource (frontmatter files) and action (querying with SQL). It distinguishes this tool from siblings like `query_inspect` by focusing on actual data querying rather than inspection.

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

Usage Guidelines4/5

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

Provides detailed usage: glob pattern, SQL query, and conditions for semantic search ('when enabled and indexing is complete'). Includes an example query. However, it does not explicitly exclude when not to use or mention siblings like `query_inspect` for inspection tasks.

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

query_inspectA

Get frontmatter schema from files matching glob pattern.

Args: glob: Glob pattern relative to base directory (e.g. "atoms/**/*.md").

Returns: Dict with file_count, schema (type, nullable, examples).

ParametersJSON Schema

Name	Required	Description	Default
`glob`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the return type but does not explicitly state that the tool is read-only or has no side effects, which is important for behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short paragraphs, using clear headers (Args, Returns) and no extraneous information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one parameter and an output schema exists, the description covers the purpose, parameter usage, and return structure (file_count, schema details) adequately for an agent to use the tool correctly.

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

Parameters4/5

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

The description provides an example for the 'glob' parameter (e.g., 'atoms/**/*.md'), adding meaningful context beyond the schema's name and type. With 0% schema coverage, this example compensates well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the verb 'Get' and resource 'frontmatter schema from files matching glob pattern', which is clear and distinguishes from sibling tools like 'query' that likely return content instead of schema.

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

Usage Guidelines3/5

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

The description implies usage for inspecting frontmatter schema but does not explicitly state when to use this tool versus alternatives like 'query' or the batch tools. No exclusions or when-not-to-use guidance is provided.

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

updateA

Update frontmatter properties in a single file.

Args: path: File path relative to base directory. set: Properties to add or overwrite. Values are applied as-is (null becomes YAML null, empty string becomes empty value). unset: Property names to remove completely.

Returns: Dict with path and updated frontmatter.

Notes: - If same key appears in both set and unset, unset takes priority. - If file has no frontmatter, it will be created.

ParametersJSON Schema

Name	Required	Description	Default
`set`	No
`path`	Yes
`unset`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

Despite no annotations, description discloses key behaviors: null handling, unset priority, and creation of frontmatter if absent. However, it omits details like error handling for missing files or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with Args, Returns, Notes. Each sentence adds value, though some sections could be more compact (e.g., combining null handling).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, return value, and edge cases (conflict resolution, frontmatter creation). Missing error scenario for non-existent files, but overall adequate for a mutation tool with an output schema.

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

Parameters5/5

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

With 0% schema coverage, description fully explains each parameter: path as relative file path, set with value semantics (null vs empty), and unset for removal. This adds essential meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool updates frontmatter properties in a single file, with a specific verb and resource. It distinguishes from sibling batch tools by focusing on single-file operations.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus siblings like batch_update. Usage is implied for single file updates, but alternatives are not discussed.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: query_inspect for schema, query for SQL queries, update/batch_update for generic property updates, and specialized batch_array_* tools for array operations. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with underscores, using 'batch_' prefix for batch operations. Names like batch_array_add are predictable and clear.

Tool Count5/5

With 9 tools, the server covers the essential frontmatter operations without being bloated. Each tool serves a specific need, and the count is well-scoped for the domain.

Completeness4/5

The tool set covers inspection, querying, and updating frontmatter, including batch operations and array manipulations. A minor gap is the lack of a dedicated tool to delete entire frontmatter blocks, though unset can remove properties.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

second-brain-bridge
io.github.IsaiahDupree
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Note Taking Knowledge & Memory Search
1
NeuroStack
io.github.raphasouthall
Token-efficient MCP memory for Markdown vaults. Tiered search, GraphRAG, AI memories.
Knowledge & Memory RAG Systems Vector Databases
246
sunub-obsidian-mcp-server
ai.smithery
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Note Taking Search Text Summarization
22
stagenth · 数据工具箱 A
com.stagenth
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Databases Data Platforms File Systems
62

Related MCP Servers

Semantic Search MCP
Search Note Taking Knowledge & Memory
bborbe
A
license
A
quality
B
maintenance
Enables semantic search over markdown files to find related notes by meaning rather than keywords, and automatically detect duplicate content before creating new notes.
Updated 8 days ago (2026-08-26 20:04 UTC)
3
2
BSD 2-Clause "Simplified"
knowledgebased
RAG Systems Knowledge & Memory
devkanro
A
license
A
quality
D
maintenance
Provides semantic search and a tag-based knowledge graph for any project, auto-discovering local markdown knowledge bases with YAML frontmatter.
Updated 4 months ago (2026-04-27 07:02 UTC)
10
14
MIT
mcp-recall-md
Note Taking Search Vector Databases
kalikin-artem
A
license
A
quality
C
maintenance
Enables semantic search over local markdown note collections using vector embeddings, with real-time file watching and zero-config setup.
Updated 2 months ago (2026-06-19 19:50 UTC)
4
MIT
harness-health-engineering
Health & Wellness RAG Systems Knowledge & Memory
cryptoyoginya
A
license
Not graded
quality
B
maintenance
Enables querying a local health knowledge base with hybrid RAG (vector + FTS5) and exploring backlinks between notes.
Updated 2 months ago (2026-07-03 20:58 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/kzmshx/frontmatter-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server