Skip to main content
Glama
arctop

Seamless

by arctop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

notes_create

Create standalone work notes for research findings, decisions, or meeting summaries with tags and optional plan/project links. Use for long-form artifacts; keep compact durable lessons separate.

Instructions

Create a work note -- a research finding, decision record, meeting summary, or any artifact long enough to deserve its own file. Auto-tagged created-by:agent. Notes carry the long form; memory_write carries the compact durable knowledge a future session must not miss, so put the write-up here and the one-line lesson there rather than duplicating either. Pass plan= when the note is a plan's narrative or supporting context, so it joins that plan's composition beside its tasks. Do not use this for what the repo, AGENTS.md/CLAUDE.md, or the current conversation already records, and use notes_append to extend an existing note rather than creating a near-duplicate of it.

Input Schema

NameRequiredDescriptionDefault
bodyYesmarkdown body (aliases: content, text)
planNooptional plan slug (plan:<slug> convention): tags this note into that plan's composition so it surfaces on the Plans screen alongside its tasks_add plan=<slug> steps. Use it whenever this note is a plan's narrative or supporting context.
tagsNotags (a comma-separated string is also accepted)
titleYesnote title
projectNoproject slug; defaults to the bound/ambient session's project. An unknown slug CREATES that project -- naming a new one is normal and never an error. Pass project=global ONLY for knowledge that belongs in EVERY project's briefing; it is not a neutral default. With no session and no explicit project the call is rejected as ambiguous. A session bound to a confidential or sealed project can write ONLY into that project.
sessionNothe session to act as: the name session_start returned, the cc/<id> or cx/<id> on your briefing's 'Seam session' line, or a session ULID. It scopes and credits this call. Defaults to this connection's session; pass it on every call when session_start reports the connection as stateless
source_urlNooptional source URL
descriptionNooptional one-line summary

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.4
    • addedInput schema / properties / session
      Added value: +{
+  "description": "the session to act as: the name session_start returned, the cc/<id> or cx/<id> on your briefing's 'Seam session' line, or a session ULID. It scopes and credits this call. Defaults to this connection's session; pass it on every call when session_start reports the connection as stateless",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.4.11
    • changedInput schema / properties / project / description
      Previous value: -"project slug; defaults to the bound/ambient session's project. An unknown slug CREATES that project -- naming a new one is normal and never an error. Pass project=global ONLY for knowledge that belongs in EVERY project's briefing; it is not a neutral default. With no session and no explicit project the call is rejected as ambiguous."New value: +"project slug; defaults to the bound/ambient session's project. An unknown slug CREATES that project -- naming a new one is normal and never an error. Pass project=global ONLY for knowledge that belongs in EVERY project's briefing; it is not a neutral default. With no session and no explicit project the call is rejected as ambiguous. A session bound to a confidential or sealed project can write ONLY into that project."
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare the write/safe/non-idempotent profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds behavior the annotations do not carry: notes are auto-tagged created-by:agent, and passing plan=<slug> enrolls the note into that plan's composition. It does not describe the return value or whether the created note's identifier is needed for later notes_append calls.

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

Conciseness4/5

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

The first sentence front-loads purpose, followed by sibling routing, plan usage, and exclusions in a logical order with no filler. It is dense and slightly overpacked in a single paragraph, but every sentence carries a distinct instruction.

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 an 8-parameter create tool with full schema coverage, no nested objects, and no output schema, the description covers purpose, routing, and the plan-composition side effect adequately. The only gap is what the call returns (e.g., a note handle/ULID a follow-up notes_append would need), which matters for the chained workflow the description itself encourages.

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 100%, so every parameter including plan, project, and session is already documented in the schema, which sets the baseline at 3. The description's plan=<slug> guidance largely restates the schema's own plan description ('tags this note into that plan's composition'), adding intent framing but no new syntax or constraints.

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 and resource ('Create a work note') and then enumerates the kinds of artifacts it produces (research finding, decision record, meeting summary), which lets an agent classify the intended payload immediately. It also explicitly contrasts itself with memory_write and notes_append, so it is distinguishable from siblings without opening their schemas.

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?

Gives explicit routing rules: put the long-form write-up here, the one-line durable lesson in memory_write, and extend an existing note with notes_append instead of duplicating it. It also adds a clear negative condition ('Do not use this for what the repo, AGENTS.md/CLAUDE.md, or the current conversation already records'), which is rare and valuable in exclusion guidance.

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