Skip to main content
Glama

replace_in_note

Replace specific text in a note only when it matches the expected occurrence count, preventing unintended rewrites. Submit multiple edits in one call for efficient batch updates.

Instructions

Replace exact text in a note without resending the rest. Refuses unless find occurs exactly expected_count times (default 1) — protects against a loose find rewriting more than intended. Accepts either find/replace or old_string/new_string (same pair, either naming works).

For several replacements in one note, pass edits (array of {find/old_string, replace/new_string, expected_count}) instead of the singular fields — one row lock and one re-embed for the whole batch instead of one per call. Edits apply in order, and each one's find is matched against the note as already changed by the edits before it, not the original content — an earlier edit can create the text a later one needs, or remove the text a later one expects to find; sequence them accordingly. If any step's count does not match, the whole batch is refused and the note is left completely untouched — the error names which edit index failed and how many times its find text actually occurred. Do not combine edits with the singular find/replace/old_string/new_string/expected_count fields — use one form or the other.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
findNoText to replace. Alias: old_string
editsNoMultiple find/replace steps applied in order in a single call — see main description.
titleNoAlternative to id; resolved like get_note
replaceNoReplacement text. Alias: new_string
new_stringNoAlias for replace
old_stringNoAlias for find
expected_countNo
expected_updated_atNoISO updated_at from when you read the note; refuses the write if it changed since

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

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 behavioral burden and excels: it discloses the expected_count safety guard, the aliasing equivalence, the ordering semantics of batch edits, the atomicity of the batch (whole batch refused, note untouched), and the error behavior that names the failing index. This goes well beyond what annotations could have provided.

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 dense but every sentence earns its place. It is front-loaded with the core behavior, then progressively explains the safeguard, aliases, batch usage, sequencing, atomicity, and the prohibition on combining forms. No redundancy or filler exists.

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 thoroughly covers the tool's behavior and edge cases, but does not state that a note must be identified via `id` or `title` (even though the schema lists required as zero). For an API call, that is a meaningful omission; otherwise the operational details are complete.

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?

Though schema coverage is high at 78%, the description adds substantial meaning beyond the schema: it explains the alias equivalence (find/old_string, replace/new_string), the semantic difference between singular and batch forms, the order-dependent matching ('each one's find is matched against the note as already changed by the edits before it'), and the all-or-nothing batch result. These are not evident from parameter definitions alone.

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 opens with a specific verb and resource: 'Replace exact text in a note without resending the rest.' It clearly distinguishes this targeted operation from siblings like update_note and append_to_note by emphasizing exact-match replacement and avoiding a full rewrite.

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 gives clear context for when to use the tool ('without resending the rest') and provides detailed internal guidance on choosing between singular fields and the `edits` array. However, it does not explicitly name sibling tools as alternatives or state when not to use this tool.

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