Skip to main content
Glama
Sign In
Kybase

Kybase

by Kyrzin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

replace_in_note

Replaces exact text in a Kybase note without resending the whole note, with ordered batch edits and count-checked all-or-nothing writes.

Instructions

Replace exact text in a note without resending the rest. Either find/replace or old_string/new_string — the same pair, either spelling.

For several replacements pass edits rather than the singular fields (one lock and one re-embed for the batch, not one per call); the two forms cannot be combined in one call. Edits apply in order, and each find is matched against the note as the edits before it already changed it — an earlier edit can create the text a later one needs, or destroy it, so sequence them. If any step's count is wrong the whole batch is refused and the note is left untouched, and the error names the failing index.

Input Schema

NameRequiredDescriptionDefault
idNoThe note's UUID. Alternative to title
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_countNoHow many times `find` is expected to occur (default 1). The edit is refused if the real count differs, so a loose `find` cannot quietly rewrite more than intended
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. Changed4 schema fields changedv1.3.1
    • addedInput schema / allOf
      Added value: +[
+  {
+    "anyOf": [
+      {
+        "required": [
+          "id"
+        ]
+      },
+      {
+        "required": [
+          "title"
+        ]
+      }
+    ]
+  },
+  {
+    "anyOf": [
+      {
+        "required": [
+          "edits"
+        ]
+      },
+      {
+        "required": [
+          "find"
+        ]
+      },
+      {
+        "required": [
+          "old_string"
+        ]
+      }
+    ]
+  }
+]
    • addedInput schema / properties / expected_count / description
      Added value: +"How many times `find` is expected to occur (default 1). The edit is refused if the real count differs, so a loose `find` cannot quietly rewrite more than intended"
    • addedInput schema / properties / id / description
      Added value: +"The note's UUID. Alternative to title"
    • removedInput schema / properties / id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
  2. First observedv1.3.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses ordering semantics between edits, that earlier edits can create or destroy later match text, and atomic all-or-nothing failure with the failing index named in the error. It omits what a successful call returns and any permission/authorization expectations.

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?

Two tight paragraphs, purpose and pairing rule front-loaded, batch guidance second. The parenthetical about lock/embed count is the only flourish and it earns its place by justifying the batch form.

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 9-parameter mutation tool with no annotations and no output schema, the key semantics (atomicity, ordering, count validation, form exclusivity) are covered. The main gap is that without an output schema the description never says what a successful call returns.

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 100%, so baseline is 3, but the description adds constraints not expressible in the schema — notably that `edits` and the singular fields cannot be combined, and that each `find` in a batch is evaluated against the progressively modified note. The alias equivalence it repeats is already in the 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?

States a specific verb+resource ('Replace exact text in a note') and immediately scopes it against the obvious alternative behaviour ('without resending the rest'), which implicitly distinguishes it from update_note/append_to_note. An agent can tell what this does without opening the schema.

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?

Explicit routing between the singular find/replace form and the batched `edits` form, including that the two cannot be combined, plus the efficiency rationale (one lock, one re-embed). It stops short of naming when to reach for this tool versus update_note or append_to_note.

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