Ingest a batched envelope of client-recorded env_sync mutations. HLC-skew gated, partial-success on conflict.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | No | Optional calling device id for audit attribution. The X-Ainote-Device-Id header is the canonical source; this argument is the backwards-compatible fallback for clients that predate the header. If both are sent and disagree, the request is rejected (DEVICE_MISMATCH). | |
| operations | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / device_idAdded value: +{
+ "description": "Optional calling device id for audit attribution. The X-Ainote-Device-Id header is the canonical source; this argument is the backwards-compatible fallback for clients that predate the header. If both are sent and disagree, the request is rejected (DEVICE_MISMATCH).",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive/non-read-only. The description adds useful behavioral context beyond annotations via 'HLC-skew gated, partial-success on conflict,' but does not explain what partial-success implies, side effects, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences; every phrase contributes ('Ingest...', 'HLC-skew gated, partial-success on conflict'). No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description is usable but thin: it hints at batch and conflict behavior, yet lacks expected return, error representation, and what partial-success means. Schema and annotations mitigate some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description never references device_id or operations and adds no detail beyond schema. Schema covers device_id thoroughly, but operations has no top-level description; with 50% coverage, description should compensate and doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Ingest' and resource 'batched envelope of client-recorded env_sync mutations', clearly distinguishing from single-write siblings like env_sync_write and sync_push. The HLC-skew and partial-success details further pin the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are named. 'Client-recorded batched' implies batch contexts, but the description does not contrast with env_sync_write, sync_push_batch, or env_sync_txn_rollback, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools clearly target distinct resources (tasks, docs, graph, sync, env_sync, handoffs, judgments, projects, vault). A few pairs could confuse, like sync_push vs vault_sync (which has a push action) and env_sync_write vs env_sync_txn_push, but descriptions mostly clarify boundaries.
Names are predominantly snake_case with a noun_verb pattern (e.g., sync_push, task_write), but there are notable inconsistencies: plural/singular mismatches (dev_docs_read vs dev_doc_write, tasks_read vs task_write), verb-first names (list_papers, get_setup_guide, judgment_submit), and a dotted sub-namespace (env_sync.secret_pull) mixed with flat names (env_sync_txn_push).
35 tools is a large surface for a personal note/sync server. While it spans many domains (auth, tasks, docs, sync, env_sync, graph, etc.), the sheer number feels heavy and likely overwhelms agents with too many choices, especially when several tools are consolidated sub-action surfaces.
Most domains have reasonable CRUD coverage (tasks, dev docs, graph, sync, env_sync, vault). However, noticeable gaps exist: memory has no write tool (only read), papers only support listing (no create/update/delete), assumptions have write but no dedicated read or delete, and judgment is effectively submit-and-list only.