Skip to main content
Glama
farena-ai

Sara

by farena-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Add a note

add_note

Save a titled Markdown note in Sara's planner, optionally filed under a project. Returns a note ID for later reading, updating, or deleting.

Instructions

Save a new note (a title and free text, Markdown welcome) in the owner's planner in Sara, optionally in a project. Use update_note to change an existing note and remember_fact for a single fact about the owner. Returns "Saved note #id: title" (the #id works with read_note, update_note and delete_note). Only listed when the owner turns on "Let other apps change things" in Sara. Follows the owner's approval setting for her note tool (allowed, ask first, or off): when it asks first, it returns "Waiting for approval in Sara" and nothing changes until the owner presses Allow there; when it is off, it returns that it's turned off.

Input Schema

NameRequiredDescriptionDefault
bodyYesThe note's text (Markdown is fine). Up to 20,000 characters.
titleYesThe note's title. Up to 200 characters.
projectNoPlanner project name to file it under, e.g. "Garden" or "Sara". Created if it doesn't exist. Up to 80 characters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.1.1
    • addedInput schema / properties / body / description
      Added value: +"The note's text (Markdown is fine). Up to 20,000 characters."
    • addedInput schema / properties / body / examples
      Added value: +[
+  "ssh in, git pull, restart the service"
+]
    • addedInput schema / properties / body / maxLength
      Added value: +20000
    • addedInput schema / properties / project / description
      Added value: +"Planner project name to file it under, e.g. \"Garden\" or \"Sara\". Created if it doesn't exist. Up to 80 characters."
    • addedInput schema / properties / project / examples
      Added value: +[
+  "Garden"
+]
    • addedInput schema / properties / project / maxLength
      Added value: +80
    • addedInput schema / properties / title / description
      Added value: +"The note's title. Up to 200 characters."
    • addedInput schema / properties / title / examples
      Added value: +[
+  "Deploy steps"
+]
    • addedInput schema / properties / title / maxLength
      Added value: +200
    • addedInput schema / properties / title / minLength
      Added value: +1
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the mutation profile (readOnly=false, idempotent=false, destructive=false); the description adds real operational context beyond that: the approval workflow ('Waiting for approval in Sara' and no change until Allow), the off-state response, and the availability gate. It also discloses the return string format and that the #id works with read_note/update_note/delete_note.

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?

Front-loaded with purpose in the first sentence, then alternatives, then return value, then gating — a logical progression with nothing clearly redundant. The final sentences are long and multi-clause, but each clause carries distinct behavioral information about approval modes.

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?

Covers everything an agent needs for a non-idempotent creation tool with no output schema: side effects, return strings, ID reuse across sibling tools, availability precondition, and the three approval outcomes. Little is left to inference.

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 title, body, and project are already fully documented, including the 20,000/200/80 character limits and the create-if-missing project behavior. The description only restates 'title and free text, Markdown welcome' and that project is optional, adding no format or semantic detail beyond the schema. Baseline 3 applies.

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 ('Save a new note ... in the owner's planner in Sara, optionally in a project') and immediately distinguishes itself from update_note and remember_fact. An agent can pick this over its siblings without inspecting any 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: use update_note to change an existing note and remember_fact for a single fact. It also states the availability precondition ('Only listed when the owner turns on "Let other apps change things"') and the approval-mode behavior, which tells the agent exactly what to expect in each mode.

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