Skip to main content
Glama

Save knowledge

save_knowledge
Destructive

Save a Markdown knowledge file. THE tool to capture a sitting debrief, end-of-hour notes, or save-this-conversation into company Knowledge (searchable later — never claim saved until this returns a slug). Speak the slug; that is the proof it is saved. Desktop memory and remember are not a save. Use also for guidelines, SOPs, strategies, meeting notes, contact lists, trackers, or any reference material other operators must find later. The result includes slug + open. Do not use for a Play or Playbook — those are create_playbook / list_playbooks / run_playbook (growth_tactics, Plays rail). SOP/reference copies may still live here. Pass scope="personal" to save private notes visible only to the current user (e.g., notes tied to their commitments). Sitting debriefs are company scope.

Routing: Sitting/conversation/end-of-hour capture → this (company scope); speak the slug. list_knowledge first; merge if similar. Do not invent save_this_conversation. Play → create_playbook. Deadlines → add_commitment. remember is one-line learning.

[write-tier — first use may require a manager's approval; a from-now-on approval makes future calls seamless, a just-once approval re-asks next time. Call it on the first clear ask; the card is the yes — do not re-ask in chat.]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugNoOptional custom slug for the filename. If omitted, auto-generated from the title.
scopeNoWhere to save: "company" (default) = shared with the whole company; "personal" = private to the current user only. Use "personal" for notes tied to a specific person (e.g., context for the user's commitments, 1:1 notes, personal preferences, gift ideas, family info). Use "company" for shared SOPs, brand guides, strategy docs.
titleYesDescriptive title for this knowledge file (e.g., "Acme Mascot Guidelines", "Content Strategy Q1")
folderNoOptional folder to save the file in (e.g., "acme-deal", "partners/acme"). Folders are auto-created. Use for organizing related files, especially for deal rooms or shared contexts.
contentYesThe knowledge content in Markdown format. FORMATTING RULES: Use ## headers for sections (NOT **bold**). Put a blank line between every paragraph and before/after lists. Use - for list items. Use > for callouts or important notes. Structure: ## Section > ### Sub-section > paragraph > - list items. Without blank lines, content renders as a wall of text.
companyIdYesFreedomOS company id to act within (you must be a member). Required for company-scoped tools.
override_duplicate_reasonNoONLY after the canon gate refused this save as a duplicate: a specific reason why this file is NOT a duplicate of the canonical file the refusal named. Overrides are logged and visible to the operator — never use this to bypass the gate casually.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / content / description
      Previous value: -"The knowledge content in Markdown format. FORMATTING RULES: Use ## headers for sections (NOT **bold**). Put a blank line between every paragraph and before/after lists. Use - for list items. Structure: ## Section > ### Sub-section > paragraph > - list items. Without blank lines, content renders as a wall of text."New value: +"The knowledge content in Markdown format. FORMATTING RULES: Use ## headers for sections (NOT **bold**). Put a blank line between every paragraph and before/after lists. Use - for list items. Use > for callouts or important notes. Structure: ## Section > ### Sub-section > paragraph > - list items. Without blank lines, content renders as a wall of text."
    • changedInput schema / required
      Previous value: -[
      -  "title",
      -  "content"
      -]New value: +[
      +  "title",
      +  "content",
      +  "companyId"
      +]
  2. Changed2 schema fields changed
    • changedInput schema / properties / folder / description
      Previous value: -"Optional folder to save the file in (e.g., \"conduit-deal\", \"partners/conduit\"). Folders are auto-created. Use for organizing related files, especially for deal rooms or shared contexts."New value: +"Optional folder to save the file in (e.g., \"acme-deal\", \"partners/acme\"). Folders are auto-created. Use for organizing related files, especially for deal rooms or shared contexts."
    • changedInput schema / properties / title / description
      Previous value: -"Descriptive title for this knowledge file (e.g., \"Bakty Mascot Guidelines\", \"Content Strategy Q1\")"New value: +"Descriptive title for this knowledge file (e.g., \"Acme Mascot Guidelines\", \"Content Strategy Q1\")"
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With destructiveHint=true, the description adds substantial behavioral context: 'never claim saved until this returns a slug', 'Speak the slug; that is the proof it is saved', the write-tier approval flow ('first use may require a manager's approval'), and the instruction 'the card is the yes — do not re-ask in chat.' These go beyond annotations and tell the agent exactly how to handle confirmation and approval.

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 description is long but dense and well-organized, front-loading the core purpose before routing and approval details. Every sentence carries useful information, though there is minor redundancy (e.g., 'Play → create_playbook' appears both in the exclusions sentence and again in the Routing paragraph).

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 write tool with no output schema, the description covers everything an agent needs: what counts as a save, what does not, alternatives, routing, approval behavior, scope choice, duplicate-override cautions in the schema, and the success signal ('The result includes slug + open'). This is complete even for a tool with many siblings and special cases.

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 description coverage is 100%, so the schema already documents all parameters. The description adds value on top by clarifying scope semantics: 'Pass scope="personal" to save private notes visible only to the current user' and 'Sitting debriefs are company scope.' It also connects slug to the confirmation behavior, which is a useful tie-in beyond the schema's technical definition.

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 opens with a specific verb and resource: 'Save a Markdown knowledge file.' It then names concrete use cases (sitting debrief, end-of-hour notes, save-this-conversation) and explicitly distinguishes itself from siblings by saying 'Do not use for a Play or Playbook — those are create_playbook / list_playbooks / run_playbook.' An agent can immediately tell what this tool is for and what it is not for.

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?

The description gives explicit routing: 'Sitting/conversation/end-of-hour capture → this (company scope)', 'list_knowledge first; merge if similar', 'Deadlines → add_commitment', and 'remember is one-line learning.' It also names alternatives and warns not to invent save_this_conversation. This is exemplary when-to-use guidance.

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