Windows Microsoft Sticky Notes MCP Server

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

With no annotations, the description carries the full behavioral burden. It does usefully disclose side effects of the flags — is_open "Display note window immediately on Windows desktop" and is_always_on_top "Pin note always on top" — plus defaults. It says nothing about platform/account requirements, error behavior, or what happens on duplicate content, which leaves meaningful gaps for a mutation tool.

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?

Front-loaded purpose sentence followed by a compact Args block; every line carries meaning and nothing is padded. The only mild redundancy is restating defaults that also appear in the schema, though that is justified given 0% schema coverage.

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?

An output schema exists, so return values need not be described. The four parameters are fully covered, and the Windows desktop hint covers the platform nuance for is_open. What is missing is failure/permission behavior and any note-creation side effects like where notes are persisted.

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?

Schema description coverage is 0%, so the description must compensate, and it does: all four parameters are explained with meaning and defaults, and theme enumerates the seven allowed values (Yellow, Green, Pink, Purple, Blue, Grey, Charcoal) that the schema does not constrain via enum. This adds real value beyond the bare property titles.

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?

The description opens with a specific verb+resource: "Create a new Microsoft Sticky Note." That immediately separates it from list/get/search/update/delete/restore siblings. It stops short of naming an alternative or scope boundary (e.g. vs. update_note), so it is clear but not sibling-differentiating.

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?

The body is entirely a parameter list; there is no statement of when to use this tool versus update_note or restore_note, and no prerequisites such as needing an existing notebook or signed-in account. An agent must infer the context from the name alone.

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

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

No annotations are present, so the description carries the full burden, and it does disclose the key behavioral traits: the operation is soft-delete by default and recoverable, while permanent=True is a hard delete that removes the record from SQLite. It omits secondary behavior such as permission requirements, idempotency, or what happens when the note_id does not exist.

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?

The core behavior is front-loaded in the first sentence, and the Args block is compact. The Args section slightly duplicates the schema but is justified here because the schema carries no parameter descriptions.

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?

An output schema exists, so return values need not be described. For a two-parameter mutation with no annotations, the description covers the destructive/recoverable distinction adequately, with only minor gaps around failure modes and permissions.

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?

Schema description coverage is 0%, so the description must compensate, and it does: note_id is described as the note's UUID and permanent is explained in terms of the concrete effect of each boolean value (trash vs SQLite removal). This meaningfully exceeds the bare schema types, though it is only two parameters and the explanation is brief.

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?

The description states a specific verb and resource ('Delete a Sticky Note') and immediately clarifies the two operating modes (soft vs permanent). It is unambiguous about what the tool does, though it never names sibling tools like restore_note to sharpen the boundary between them.

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?

The default-to-soft-delete behavior implies the common case and hints that recoverable deletion is the norm, which loosely connects to the restore_note sibling. However, there is no explicit when-to-use guidance, no stated prerequisites, and no direction toward alternatives such as restoring or updating a note instead.

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

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

Annotations are absent, so the description carries the full behavioral burden. It discloses that only 'active' notes are exported (useful scope info) and the default formats/directory, but says nothing about whether existing files are overwritten, file naming, permissions, or error behavior for a tool that writes to disk.

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?

The summary sentence is front-loaded and each param line adds concrete information. The 'Args:' block is slightly boilerplate but contains no filler.

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?

For a simple two-optional-parameter export tool with an output schema present, the description covers purpose, both parameters, and their defaults. The only gap is file-write side-effect behavior, which is minor at this complexity.

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?

Schema description coverage is 0%, so the description must compensate, and it does: it names the allowed export_format values ('markdown' or 'json') plus the default, and explains output_dir as the target path defaulting to the user's Documents folder. That adds real meaning beyond the bare schema types.

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?

States a specific verb (Export) and resource (all active Sticky Notes) plus the output forms (Markdown file or JSON dump), so the operation is unambiguous. It does not explicitly differentiate itself from siblings like list_notes or get_note, but the intent is clear enough to select it over them.

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?

The description says what is exported but never states when to choose export_notes over list_notes/get_note, or any prerequisites. 'All active' implies a scope filter but there is no when-to-use or when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read, but the description is silent on permissions, not-found behavior, and whether soft-deleted notes (a restore_note sibling exists) are returned; it adds only the modifier 'full content and details' beyond the schema.

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?

The description is short and front-loaded with the core action in the first sentence. The trailing 'Args:' block restates the parameter in a slightly redundant way but does no harm.

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?

For a single-record read with an output schema present, return values need not be described. Still, with no annotations, the definition leaves unaddressed whether missing/deleted notes raise an error and what the caller must have to read the note, which is thin for the surrounding CRUD toolset.

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?

Schema description coverage is 0% and the single parameter is documented only as 'Note Id'. The description adds the meaningful detail that note_id is a UUID, which the schema does not convey, but includes no format example, source, or error semantics for a bad ID.

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?

States a specific verb and resource ('Get full content and details of a single Sticky Note by its UUID'), and the word 'single' plus the UUID lookup implicitly separates it from list_notes/search_notes. It does not explicitly name a sibling or contrast scopes, so it falls just short of a 5.

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?

There is no guidance on when to call this versus list_notes, search_notes, or get_stats. The only inference an agent can draw is that a UUID is required, which the schema already makes mandatory; no alternatives or prerequisites are stated.

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

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

No annotations are provided, so the description carries the behavioral burden, but it only does so implicitly: 'Get' signals a read-only, side-effect-free operation, which is the main trait that matters here. It does not disclose what the statistics cover (e.g., whether deleted or restored notes are counted, whether the scope is the whole database or a filtered subset), leaving a modest gap for a zero-argument tool.

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?

A single front-loaded sentence with no filler or repetition of the title. It is efficient, though so terse that it could have absorbed one more clause of scope without losing conciseness.

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?

An output schema exists, so the description is not obligated to enumerate return values, and for a simple zero-arg read tool the current text is nearly sufficient. However, with no annotations and no statement of what 'high-level summary statistics' comprises or over what scope, an agent cannot predict the contents beyond the schema shape.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly implies the call needs no input, matching the empty schema.

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?

The description gives a specific verb ('Get') and resource ('high-level summary statistics of Microsoft Sticky Notes database'), which is clearly distinct from the note-level CRUD siblings. It stops short of explicitly contrasting itself with siblings like list_notes or search_notes, which could also surface aggregate-ish information, so it is clear but not fully differentiated.

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?

There is no guidance on when to reach for get_stats versus list_notes, search_notes, or export_notes. For a tool that exists purely to answer 'how many / how much' questions, a single sentence saying it is the aggregate-view entry point would have been easy and valuable, but it is absent.

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

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

No annotations are supplied, so the description carries the full burden. It usefully explains pagination (limit/offset), the soft-delete toggle (include_deleted default False), and the shape of returned data, and 'List' implies read-only. It says nothing about authorization requirements, rate limits, or result ordering, so it is helpful but not complete for a zero-annotation tool.

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?

Front-loaded one-line summary followed by a compact per-parameter block. It repeats default values already encoded in the schema, which is minor redundancy, but nothing is buried or verbose.

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?

An output schema exists, so return values need no further explanation, and the description correctly stays focused on filters, pagination, and soft-delete behavior. The only real gap is routing guidance against sibling tools, which the other dimensions already flag.

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?

Schema description coverage is 0%, so the description must compensate, and it does: all five parameters get meaning, defaults are stated, and theme gains an explicit enum list (Yellow, Green, Pink, Purple, Blue, Grey, Charcoal) absent from the schema. The is_open gloss ('on desktop') is slightly vague but the other four are well specified.

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?

States a specific verb (List) and resource (Microsoft Sticky Notes) and even previews the returned fields (summary metadata, theme, text preview). It does not, however, explicitly disambiguate itself from search_notes or get_note, which an agent must infer from the verb alone.

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 when-to-use, when-not-to-use, or alternative routing is provided. The presence of search_notes as a sibling makes the omission notable, since the agent gets no signal on when to filter via search_notes instead of enumerating here.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that this only operates on soft-deleted notes and returns them to active desktop notes, but omits error behavior (note not found, note not deleted, idempotency) and permission requirements for a mutation tool.

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?

Very short and front-loaded, with the core action stated before the Args block. It is efficient, though the Args block is slightly formal for a single self-evident parameter.

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?

An output schema exists, so return values need no explanation, and the action plus its one parameter are covered. However, the description leaves preconditions, error cases, and permission needs unstated for a mutation, which leaves clear gaps for an agent.

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?

Schema description coverage is 0%, so the description must compensate, and it does document the sole parameter as the UUID of the note to restore. That adds meaning beyond the schema's bare 'Note Id' title, though it gives no format example.

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?

States a specific verb (restore) and resource (a soft-deleted Sticky Note), and clarifies the end state back to active desktop notes, which separates it from update_note/delete_note. It does not explicitly name or contrast a sibling, so it falls short of the top tier.

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?

The 'soft-deleted' qualifier implies the required precondition, so usage is reasonably inferable, but there is no explicit when-to-use guidance, no statement that the note must already be soft-deleted, and no pointer to a sibling for finding deleted notes.

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

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

No annotations exist, so the description carries the burden, and it does disclose two useful traits: matching is case-insensitive and results can include soft-deleted notes, revealing the deletion model. It omits ordering, pagination/result-window behavior, and any read-only safety statement.

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?

Front-loaded single-sentence purpose followed by a compact Args block; every line maps to a parameter. The parentheticals (case-insensitive, defaults) are informative rather than padding.

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?

An output schema exists, so return values need not be explained, and all three parameters are covered. With zero annotations, however, the description should say more about result ordering, paging past the limit, and that the operation is read-only.

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?

Schema description coverage is 0%, so the description must compensate, and it does: it defines query, limit (default 50), and include_deleted (default False) with the soft-delete meaning spelled out. It does not clarify pattern syntax, e.g., substring vs. token vs. wildcard matching.

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?

States a specific verb and resource ('Search Sticky Notes') plus matching semantics ('keyword or text pattern, case-insensitive'). It is clearly distinct from list_notes in intent, though it never names that sibling to explain the difference explicitly.

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 guidance on when to prefer this over list_notes or get_note, which are adjacent siblings. The only usable cue is implicit in the word 'Search' and the presence of a query parameter; no exclusions or prerequisites are given.

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

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

With no annotations, the description carries the full behavioral burden. It does add real value: it discloses the destructive overwrite semantics of 'text', and the precedence rule that 'append_text' is ignored when 'text' is supplied. However it never states that unlisted fields are left unchanged (partial vs. full update), nor anything about permissions or reversibility of visibility/theme changes.

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?

The one-line purpose is front-loaded, followed by a compact per-argument list with no filler. Slightly list-heavy, but every line maps to a distinct parameter, so nothing is wasted.

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?

For a six-parameter mutation tool with an output schema (so return values need no explanation), the definition covers every argument and its semantics. The remaining gap is the partial-update contract — whether omitted fields are preserved — which an agent would want confirmed before calling.

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?

Schema description coverage is 0%, so the description must compensate — and it documents all six parameters, including the note_id UUID format, the overwrite-vs-append interaction, the enumerated theme values, and the True/False meaning of the two boolean flags. This is meaning the schema itself does not provide.

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?

States a specific verb ('Update') and resource ('an existing note') and enumerates exactly which attributes can be changed (text, appended lines, theme, visibility). The word 'existing' plus the sibling set (create_note, get_note) makes the scope unambiguous without opening any schema.

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?

Usage is implied — you need a note_id, presumably obtained from list_notes/get_note/search_notes — but there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. Nothing misleading, but nothing that routes the agent among siblings either.

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