Skip to main content
Glama
Sign In
Inkdrop MCP Server

Inkdrop MCP Server

Official
by inkdropapp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

search-notes

Searches Inkdrop notes by keyword and filters results with qualifiers like notebook, tag, status, title, or body; returns truncated snippets for use with read-note.

Instructions

List all notes that contain a given keyword. The result does not include entire note bodies as they are truncated in 200 characters. You have to retrieve the full note content by calling read-note. Here are tips to specify keywords effectively:

Use special qualifiers to narrow down results

You can use special qualifiers to get more accurate results. See the qualifiers and their usage examples:

  • book book:Blog: Searches for notes in the 'Blog' notebook. book:"Desktop App": Searches for notes in the 'Desktop App' notebook. book:kGlLniaV: Searches for notes in the notebook with the ID 'book:kGlLniaV'.

  • tag tag:JavaScript: Searches for all notes having the 'JavaScript' tag. Read more about tags. tag:pQ7xYt2R: Searches for all notes having the tag with the ID 'tag:pQ7xYt2R'.

  • status status:onHold: Searches for all notes with the 'On hold' status. Read more about statuses.

  • title title:"JavaScript setTimeout": Searches for the note with the specified title.

  • body body:KEYWORD: Searches for a specific word in all notes. Equivalent to a global search.

Combine qualifiers

You can combine the filter qualifiers to refine data even more.

Find notes that contain the word 'Hello' and have the 'Issue' tag.

Hello tag:Issue

Find notes that contain the word 'Typescript,' have the 'Contribution' tag, and the 'Completed' status

Typescript tag:Contribution status:Completed

Search for text with spaces

To find the text that includes spaces, put the text into the double quotation marks ("):

"database associations"

Exclude text from search

To exclude text from the search results or ignore a specific qualifier, put the minus sign (-) before it. You can also combine the exclusions. See the examples:

  • -book:Backend "closure functions": Ignores the 'Backend' notebook while searching for the 'closure functions' phrase.

  • -tag:JavaScript: Ignores all notes having the 'JavaScript' tag.

  • -book:Typescript tag:work "Data types": Ignores the 'Typescript' notebook and the 'work' tag while searching for the 'Data types' phrase.

  • -status:dropped title:"Sprint 10.0" debounce: Ignores notes with the 'Dropped' status while searching for the 'debounce' word in the note with the 'Sprint 10.0' title.

  • -"Phrase to ignore" "in the rest of a sentence": Ignores the 'Phrase to ignore' part while searching for 'in the rest of a sentence'.

Note that you can't specify excluding modifiers only without including conditions.

WARNING: Make sure to enter a text to search for after the exclusion modifier.

  • ✅ Will work -book:Backend "closure functions"

  • ⛔️ Won't work -book:Backend. There's no query. Inkdrop doesn't understand what to search for.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "keyword": "<keyword>"
    },
    "name": "search-notes"
  }
}

Input Schema

NameRequiredDescriptionDefault
keywordYesKeyword to search for.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that note bodies are truncated to 200 characters and that `read-note` is required for full content, but it omits result limits, pagination, sorting, permissions, and read-only guarantees.

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 long but well structured: purpose and truncation behavior are front-loaded, followed by clearly organized query syntax sections with examples. Some examples and warnings are repetitive, but the length is largely justified by the complex search syntax.

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?

For a one-parameter search tool with no output schema, the description covers the most important gaps: query syntax, truncation behavior, and the required follow-up call to `read-note`. It still lacks details about result shape, pagination, and maximum results, but those are secondary for this tool's main usage.

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 schema already documents the single `keyword` parameter at 100% coverage, so the baseline is 3. The description goes far beyond the schema by explaining qualifiers such as `book:`, `tag:`, `status:`, `title:`, and `body:`, plus phrase search and exclusion syntax, making the parameter semantics substantially richer.

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 states a specific verb and resource: 'List all notes that contain a given keyword.' It clearly distinguishes the operation from full note retrieval by explaining that bodies are truncated and directing the agent to `read-note` for complete content.

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 makes the primary use case clear: find notes containing a keyword, then call `read-note` for full content. It does not explicitly compare against `list-notes` or other sibling search/list tools, but the keyword-based condition provides clear selection guidance.

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

Deploy Server

Other Tools