Skip to main content
Glama

Create Note

post_notes

Create a BlackOps note, or update one in place when source_id resolves to a known note. Requires content_markdown (or transcript/conversation). Prefer this over post_notes_write — richer metadata, dedup, search/list visibility, auto-vault-sync.

source_id is the idempotency key: pass it (content hash, agent-defined string, or note UUID) so repeat calls update instead of forking. Already know the note? Use patch_notes with id instead. Check response warnings — an auto-suffixed slug ("my-note-2") with code SLUG_COLLISION means an intended update forked instead.

Site is OPTIONAL (resolves explicit → account default intake → the user's only site); pass domain/site_id only for a note tied to one site.

BRAINS: pass a named brain's UUID as brain_id — the server derives site/target/folder from it, and this always skips auto-routing below. Never infer site_id or guess target_id from topic keywords. brain_alignment in the response confirms the compile will pick the note up.

WITHOUT brain_id, a site that has opted into brain auto-routing resolves one itself instead of leaving the note unfiled with a guess-and-ask: an Auto verdict files the note straight into that brain's Triage lane (routing: { band: "auto", filed: true, brain_id, brain_name, probability, verdict_id }); a Suggest or No-home verdict saves the note unfiled and the response carries needs_brain_choice — present its question and up to 3 options (each with a one-line reason) as ONE single-choice question, the way your host renders a question or choice card if it has one, alongside the also entries ("Leave unfiled" / "Create a new brain"), then call resolve_with (patch_notes with the chosen brain_id) with the pick. Never choose a brain from that list yourself. A site that has not opted in behaves exactly as before — the note is saved unfiled, no brain is queried. suggest_brain: true is a separate, unrelated opt-in: a keyword-based unassigned-brain match surfaced as suggested_brain, not auto-routing.

TAGS outside the vocabulary still apply and stay queryable, with an UNKNOWN_TAG warning naming it — ask the user before calling propose_note_tags.

VAULT SYNC is automatic but DEFERRED: the commit runs after the response, so sync is { status: "queued" }. The note IS saved — do NOT re-call. Confirm a landed commit with get_note, never vault_sync_queued_at; pass wait_for_sync: true only for commitSha/filePath inline. override_folder_path bypasses the workspace taxonomy, though a brain's source_folder_path still wins.

phase/priority/position are Big Board columns (High|Medium|Low for priority); phase is free text.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "post_notes"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNo
phaseNo
titleNo
domainNo
statusNo
confirmNo
excerptNo
site_idNo
brain_idNo
metadataNo
positionNo
priorityNo
auto_syncNo
note_typeNo
source_idNo
target_idNo
transcriptNo
conversationNo
triage_stateNoSet to 'pending' to file this note into a brain's Triage lane (unreviewed) instead of committing it to the vault right away. Leave unset for an ordinary note.
allow_secretsNo
assign_targetNo
suggest_brainNo
wait_for_syncNo
conversation_idNo
content_markdownNo
override_folder_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare destructiveHint=false, so the description carries the burden and does so richly: upsert-by-source_id dedup, SLUG_COLLISION fork warnings, brain auto-routing verdicts with the exact routing payload, needs_brain_choice handling, deferred vault sync with { status: "queued" } and an explicit 'do NOT re-call' instruction. This is behavior an agent could not infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and alternatives are front-loaded and the paragraphing separates concerns, but the BRAINS section is a dense wall of prose carrying host-rendering instructions ('the way your host renders a question or choice card') that are tangential to tool selection. At roughly 450 words for a create tool it is longer than needed for invocation correctness.

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?

With no output schema, the description usefully describes return signals (routing, brain_alignment, needs_brain_choice, UNKNOWN_TAG warning, sync status), which is exactly what an agent needs to react after calling. It falls short of complete only because several real parameters that affect write semantics (allow_secrets, confirm, auto_sync, metadata) are never mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 4% across 26 parameters, so the description must compensate — and it does explain the high-risk ones (source_id, brain_id, site_id/domain, target_id, suggest_brain, tags, wait_for_sync, override_folder_path, phase/priority/position, content_markdown, transcript/conversation). However, a substantial set remains undocumented in both schema and description: allow_secrets, confirm, auto_sync, assign_target, metadata, note_type, status, excerpt, conversation_id, and title.

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?

Opens with a specific verb+resource ('Create a BlackOps note, or update one in place when source_id resolves to a known note') and immediately distinguishes itself from two named alternatives, post_notes_write and patch_notes. An agent can identify the tool and its dual create/upsert nature 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: prefer this over post_notes_write for richer metadata/dedup, use patch_notes with an id if the note is already known, pass source_id for idempotency, and only pass domain/site_id when the note is tied to one site. It also gives concrete when/when-not rules for brain_id versus auto-routing versus suggest_brain.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources