Skip to main content
Glama
rps321321

obsidian-mcp-pro

by rps321321
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Rename Tag

rename_tag
Destructive

Renames a tag across every note in an Obsidian vault, updating inline #tags and frontmatter tags fields, with hierarchical sub-tag rebasing and an optional dry-run preview.

Instructions

Rename a tag everywhere it appears across the vault, in both inline #tags and frontmatter tags: fields. Non-dry-run rewrites require confirmTag to match the new tag name. With hierarchical: true (default), nested tags also rebase: renaming project to client also renames project/alpha → client/alpha. With dryRun: true, returns the planned counts without writing. Strip the leading # from oldName/newName — they're tag names, not tag tokens.

Input Schema

NameRequiredDescriptionDefault
dryRunNoIf true, count matches without modifying any notes.
newNameYesNew tag name (without leading #), e.g. 'client'.
oldNameYesExisting tag name (without leading #), e.g. 'project'.
confirmTagNoRequired when dryRun is false: re-type the new tag name to confirm vault-wide tag rewriting.
hierarchicalNoAlso rename nested sub-tags (default: true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv4.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / confirmTag
      Added value: +{
+  "description": "Required when dryRun is false: re-type the new tag name to confirm vault-wide tag rewriting.",
+  "maxLength": 200,
+  "type": "string"
+}
    • removedInput schema / properties / newName / pattern
      Removed value: -"^[^#\\s/][^\\s]*$"
    • removedInput schema / properties / oldName / pattern
      Removed value: -"^[^#\\s/][^\\s]*$"
  2. Addedv2.0.0
  3. Removedv1.9.0
  4. Addedv1.8.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses vault-wide rewriting scope, both inline and frontmatter targets, the confirmation guard, hierarchical rebasing behavior with an example, and the dry-run read-only mode. This is substantial behavioral context for a destructive mutation tool.

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 and front-loaded, moving from scope to confirmation requirement, hierarchical behavior, dry-run behavior, and tag-name formatting. Every sentence adds actionable information without waste.

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?

For a destructive 5-parameter mutation tool with no output schema, the description covers the critical safety mechanism, dry-run alternative, hierarchical default, and naming format. An agent has enough context to invoke it correctly and safely.

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 the baseline is 3, but the description adds useful meaning: confirmTag must match the new tag name, hierarchical rebasing is illustrated with project/alpha → client/alpha, and oldName/newName should omit the leading #. It goes beyond the schema descriptions, though some details are still schema-owned.

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, 'Rename a tag', and clarifies vault-wide scope across inline #tags and frontmatter tags:. It is clearly distinct from sibling tag-listing/searching tools.

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?

It explains key usage conditions: non-dry-run rewrites require confirmTag, dryRun returns planned counts without writing, and hierarchical defaults to true. No sibling alternative is named, but no direct rename alternative exists in the sibling list.

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