Skip to main content
Glama
takuya0206

Obsidian MCP

by takuya0206

searchWithJsonLogic

Search Obsidian notes using JsonLogic queries to filter metadata and content with structured logical conditions in JSON format.

Instructions

Search Obsidian notes using JsonLogic format queries. Using logical conditions expressed in JSON, you can flexibly filter note metadata and content. Suitable for programmatically generated searches, allowing complex conditions to be expressed in a structured way.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesJsonLogic query object. Express logical conditions in JSON format for advanced note searching. Basic Concept: JsonLogic is a specification for expressing logical conditions in JSON format. Each condition is expressed in the form {"operator": [arg1, arg2, ...]}. In Obsidian search, you can specify conditions for note metadata fields. Main Operators: 1. Common comparison operators: - "==", "===": Equality (e.g., {"==": [{"var": "rating"}, 5]}) - "!=", "!==": Inequality - ">", ">=", "<", "<=": Magnitude comparison 2. Logical operators: - "and": All conditions are true (e.g., {"and": [condition1, condition2]}) - "or": At least one condition is true - "!": Negation of a condition 3. Obsidian-specific operators: - "glob": Glob pattern matching (e.g., {"glob": [{"var": "file.path"}, "*.md"]}) - "regexp": Regular expression matching (e.g., {"regexp": ["^task.*", {"var": "file.name"}]}) 4. Data access: - "var": Get the value of a field (e.g., {"var": "frontmatter.tags"}) Basic Structure: { "operator": [ {"var": "field name"}, comparison value ] } Or compound conditions: { "and/or": [ {condition1}, {condition2}, ... ] } Usage Examples: 1. Search for notes with a specific tag: { "in": ["project", {"var": "tags"}] } 2. Search for notes where a specific frontmatter field equals a specific value: { "==": [{"var": "frontmatter.status"}, "in progress"] } 3. Search for notes with a specific URL pattern: { "glob": [{"var": "frontmatter.url"}, "https://example.com/*"] } 4. Combination of multiple conditions - notes with a specific tag and due date before today: { "and": [ {"in": ["task", {"var": "tags"}]}, {"<=": [{"var": "frontmatter.due"}, "2023-12-31"]} ] } 5. Complex example - notes in a specific folder and having a specific status or matching a specific URL pattern: { "and": [ {"glob": [{"var": "file.path"}, "projects/*"]}, {"or": [ {"==": [{"var": "frontmatter.status"}, "important"]}, {"glob": [{"var": "frontmatter.url"}, "https://github.com/*"]} ]} ] } Notes: - Field names specified with "var" must match the actual metadata structure of notes - If a field doesn't exist, the condition is not ignored but evaluated as false - Date comparisons are treated as strings, so using ISO format (YYYY-MM-DD) is safest - File properties include file.path, file.name, file.size, file.ctime, file.mtime, etc. - Frontmatter fields can be accessed with frontmatter.fieldname - The "in" operator is useful for array-type fields (such as tags)

Implementation Reference

  • src/server.ts:78-84 (registration)
    Registers the searchWithJsonLogic tool with the MCP server, providing the tool definition and handler function.
    // 5. searchWithJsonLogic - Search with WithJsonLogic
    this.server.tool(
      advancedSearchJsonLogicDefinition.name,
      advancedSearchJsonLogicDefinition.description,
      advancedSearchJsonLogicDefinition.schema,
      createAdvancedSearchJsonLogicTool(this.api)
    );
  • Tool definition object for 'searchWithJsonLogic' including the input schema (AdvancedSearchJsonLogicSchema), description, and name.
    export const advancedSearchJsonLogicDefinition: ToolDefinition = {
      name: "searchWithJsonLogic",
      description: `Search Obsidian notes using JsonLogic format queries.
    Using logical conditions expressed in JSON, you can flexibly filter note metadata and content.
    Suitable for programmatically generated searches, allowing complex conditions to be expressed in a structured way.`,
      schema: AdvancedSearchJsonLogicSchema,
    };
  • Handler factory that creates the execution function for the searchWithJsonLogic tool, which calls the ObsidianAPI and formats the response.
    export function createAdvancedSearchJsonLogicTool(
      api: ObsidianAPI
    ): ToolHandler {
      return async (params: { query: object }): Promise<ToolResponse> => {
        try {
          const { query } = params;
          const results = await api.searchWithJsonLogic(query);
          return formatSuccessResponse({ results });
        } catch (error) {
          return formatErrorResponse(
            `Error searching with JsonLogic: ${(error as Error).message}`
          );
        }
      };
    }
  • Core API client method that performs the HTTP POST request to the Obsidian search endpoint using JsonLogic content type header.
    async searchWithJsonLogic(query: object): Promise<AdvancedSearchResult[]> {
      try {
        const response = await this.client.post(
          "/search/",
          JSON.stringify(query),
          {
            headers: {
              ...this.defaultHeaders,
              "Content-Type": "application/vnd.olrapi.jsonlogic+json",
            },
          }
        );
        return response.data as AdvancedSearchResult[];
      } catch (error: any) {
        throw error;
      }
    }
Behavior2/5

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 mentions the tool is for 'searching' but doesn't clarify if it's read-only, what permissions are needed, how results are returned (e.g., pagination, format), or any rate limits. The description focuses on query syntax rather than operational behavior, leaving significant gaps for an agent to understand how to invoke it effectively.

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

Conciseness3/5

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

The description is three sentences long and front-loaded with the core purpose. However, the second sentence ('Using logical conditions expressed in JSON, you can flexibly filter note metadata and content.') is somewhat redundant with the first, and the third sentence ('Suitable for programmatically generated searches, allowing complex conditions to be expressed in a structured way.') could be integrated more tightly. It's not overly verbose but could be more streamlined.

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

Completeness3/5

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

Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It explains the query format well via the schema but lacks details on behavioral aspects like result format, error handling, or usage limits. For a tool that likely returns a list of notes, the absence of output schema means the description should compensate more, which it doesn't fully do.

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 schema description coverage is 100%, with the 'query' parameter fully documented in the input schema. The description adds minimal value beyond the schema by reiterating that queries use 'JsonLogic format' and are for 'advanced note searching.' However, since there's only one parameter and the schema covers it comprehensively, the baseline is high, and the description doesn't detract from that.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Search Obsidian notes using JsonLogic format queries.' It specifies the verb ('search'), resource ('Obsidian notes'), and method ('JsonLogic format queries'). However, it doesn't explicitly differentiate from sibling tools like listNotes or readNote, which might also retrieve notes but with different approaches.

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 provides implied usage guidance: 'Suitable for programmatically generated searches, allowing complex conditions to be expressed in a structured way.' This suggests when to use this tool (for complex, structured searches) but doesn't explicitly state when to choose it over alternatives like listNotes or readNote, nor does it mention any exclusions or prerequisites.

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

Install Server

Other Tools

Latest Blog Posts

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/takuya0206/obsidian-mcp'

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