Co-written with Claude Desktop + Obsidian MCP
Updated: Aug 9, 2025 8:35am

The Problem

I wanted Claude to open my daily note in Obsidian. Sounds simple, right? Claude could create files and search my vault through the MCP tools, but it couldn't invoke the "Daily notes: Open today's daily note" command that respects my plugin settings and templates.

When Claude tried the obvious approach - creating a file with today's date - it used the wrong naming format and put it in the wrong folder. My daily notes live in DailyNotes/ with YYYY.MM.DD.md format, not the root folder with YYYY-MM-DD.md.

The Hunt

I had this hunch: if I can run commands in Obsidian's developer console, maybe Claude could too. We tested it manually:

app.commands.executeCommandById("daily-notes")

It worked. The command exists, it's accessible, and it respects all my settings.

But here's the catch: Claude was trying to execute JavaScript in Chrome, not Obsidian. Different apps, different contexts. The MCP tools can read and write files, but they can't execute commands within Obsidian itself.

The Insight

This revealed a fundamental gap. The Obsidian MCP integration can manipulate files but can't invoke the rich command ecosystem that makes Obsidian powerful. Every plugin command, every template action, every workflow automation - all inaccessible to external tools.

The solution isn't a workaround. It's extending the MCP tools to include command execution. The API exists (app.commands.executeCommandById), it just needs to be exposed through the MCP interface.

What I Learned About Claude

Claude doesn't learn between conversations. I pointed out a formatting error (missing newlines when appending to files), Claude fixed it, but it won't remember this lesson tomorrow. Each conversation starts fresh. If you want consistent behavior, create reference materials or give explicit reminders.

Claude is methodical when it has the right tools. It systematically explored the vault structure, identified the naming patterns, and proposed a solid technical solution. But when the tools don't exist, it can't magic them into being.

Integration gaps are valuable discoveries. What started as "help me open a daily note" became a clear project plan for enhancing Obsidian's automation capabilities.

The Discovery Method That Actually Works

Here's something crucial I learned: don't read the code to understand what an MCP server provides - talk to it directly.

I could have spent hours parsing TypeScript files trying to figure out what tools were available. Instead, one JSON-RPC call told me everything:

echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}' | mcp-server | jq -r '.result.tools[].name'

This revealed 18 available tools - the actual runtime capabilities, not what the code suggested might exist. MCP servers are dynamic systems. They assemble their tool manifests at runtime based on:

• Which plugins are loaded
• What APIs are available
• Environmental conditions
• Dynamic capability detection

The available tools aren't a static list in the code - they're the result of all the registration code executing. Runtime introspection beats static analysis every time for understanding dynamic systems.

The Takeaway

Sometimes the best outcome isn't solving the original problem - it's understanding why it can't be solved and what needs to be built. I now have a roadmap for adding command execution to Obsidian's MCP tools, which will unlock much richer automation possibilities.

But more importantly: when working with dynamic systems, talk to them directly. The runtime truth is the only truth that matters.

The daily note thing? I'll just press Cmd+P and run the command manually. For now.

A quick adventure in dusting off an old PGP key, hashing a file, and giving a recipient an easy-to-follow proof path.

[written with the help of machine intelligence]

1 ? The problem that kicked it off

Last week my church sent me a rental agreement as a fill-in PDF. I filled it out, but before firing it back I wondered:

Could I send something more trustworthy than “here’s the file, trust me” without forcing the church admin (Diana) to install GPG or sign up for Keybase?

I haven’t seriously touched my PGP setup in years, but the idea of a lightweight, verifiable “signature” still appealed to the geek in me.

2 ? Taking inventory (a blast from 2013)

gpg --list-secret-keys

sec   rsa2048 2013-12-10 [SC]
      78E8E8E8B007206C2A5D9C83AA61D643ECB4CD2D
uid           Raymond Yee <raymond.yee@gmail.com>

Aha—my 2013 RSA-2048 key is still around. Keybase confirms it:

keybase pgp list
# PGP Fingerprint: 78e8e8e8b007206c2a5d9c83aa61d643ecb4cd2d

So Keybase and GPG agree: I still control the same key.

3 ? The lightweight signature plan

1. Hash the PDF
   (Because signing a small hash is friendlier than tacking a binary blob onto an email.)

   shasum -a 256 "20250830 YeeRental.Signed.pdf" \
    > pdf_hash.txt
   # ? 47a97a11…f1e4f7c  20250830 YeeRental.Signed.pdf

2. Sign the hash with my PGP key
   Using Keybase’s wrapper so I don’t have to juggle fingerprints:

   keybase pgp sign -i pdf_hash.txt -o pdf_hash.txt.asc

   Heads-up: Keybase warned me:
   Our PGP key … uses an insecure hash scheme (SHA1)
   More on that in the “Next steps” below.

3. Bundle three tiny files

   ? 20250830 YeeRental.Signed.pdf       ? the contract
   ? pdf_hash.txt.asc                   ? clear-signed hash
   ? README-verification.txt            ? human instructions

4. Give Diana the path of least resistance
   The README points her to a zero-install SHA-256 site
   (e.g., https://emn178.github.io/online-tools/sha256_checksum.html):

   1. Drag the PDF ? see the 64-char hash.
   2. Compare it with the one in my signed message.
   3. If curious, paste the signed block into https://keybase.io/verify.
      She’ll see “Good signature from rdhyee”.

That’s it: no local GPG, no Keybase account, just two web pages.

4 ? Did I actually send the signed bundle?

Of course not. In the heat of the moment I reverted to “just attach the PDF.”
But the exercise was worth it—I now have a repeatable, recipient-friendly workflow ready for next time.

5 ? What the SHA-1 warning means & my next moves

• Why the warning?
  My primary UID self-signature dates back to 2013 and was made with SHA-1. Modern GnuPG flags that as “legacy.”
  (The signatures I just created use SHA-256, so the content I sign is fine. The warning just nudges me to modernize the key itself.)

• Upgrade game-plan

  1. Generate a fresh key — ed25519 + separate encryption subkey.
  2. Sign the new key with the old one to keep a verifiable chain of custody.
  3. Upload the new key to Keybase (keybase pgp select).
     (Keybase only holds one active PGP key, so the old one will move to the “revoked” tab—or I can leave it un-revoked for legacy checks.)
  4. Set a short expiration (one-year) and renew annually.
  5. Back it up & maybe move private material to a YubiKey.

Until then, my 2048-bit RSA key is still “good enough,” but modern curves?shorter lifetimes are a cleaner future.

6 ? Take-aways

• A PGP signature doesn’t have to be intimidating—hash-then-sign keeps the process email-sized and recipient-friendly.
• Keybase’s “paste to verify” page bridges techies and non-techies nicely.
• Even a dusty 2013 key can still serve, but updating keeps the warnings away and future-proofs my identity.

Next time the church sends a form, I’ll be ready—with a shiny new ed25519 key and an even smoother README.