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

With no annotations, the description carries the burden and discloses important behaviors: default notebook ('Claude Notes'), Markdown content support, and the inability to set tags or edit existing notes. This goes well beyond a bare statement of intent, though it omits any detail about the response or whether a duplicate note is always created.

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?

Three short sentences: the first says what it does, the second gives use cases, the third captures key constraints and defaults. Every sentence earns its place and the most important behavioral facts are front-loaded.

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 create tool with three parameters, full schema coverage, and no annotations, the description covers purpose, usage context, default value, content format, and limitations. Nothing essential is missing for an agent to invoke it correctly.

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 coverage is 100% with sensible param descriptions, and the description adds extra meaning by clarifying that content is Markdown and restating the default notebook behavior for the optional notebook parameter. This enriches the schema without redundancy.

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 ('Create a new note in UpNote') and clearly distinguishes itself from sibling tools by explicitly noting it cannot edit existing notes or set tags, unlike the search, open, and list tools in the sibling set.

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?

Provides concrete use cases ('save a summary, plan, snippet or session output') and states a key constraint ('Cannot ... edit an existing note'), implying when not to use it. Does not explicitly name alternatives but the create-vs-search/open/list distinction is clear.

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 present, the description carries the full burden of behavioral disclosure. It only says 'Create a new notebook' and provides no details on side effects, duplicate handling, uniqueness constraints, authentication needs, or what response to expect, which is minimal for a mutating 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?

The entire description is a single, front-loaded sentence with no filler or repetition. Every word earns its place, making it as concise as possible for a simple create operation.

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 very simple one-parameter create tool, the description is minimally viable: the agent knows what to do and what resource is affected. However, the absence of any information about return values, duplicate behavior, or potential failures leaves a few gaps that are not covered by annotations or an output schema.

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 schema has 0% description coverage, and the tool description does not explicitly explain the 'title' parameter. While it is inferable that title is the notebook's name from the context, the description adds no direct semantic value beyond the schema's bare property name.

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 clear action, 'Create', and a specific resource, 'notebook' in UpNote. This distinguishes it from sibling tools like upnote_create_note and upnote_list_notebooks because the resource is explicitly 'notebook' rather than 'note'.

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 gives no guidance on when to use this tool versus alternatives such as upnote_create_note or upnote_list_notebooks. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer appropriate usage solely from the name.

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 claims 'full text' but the schema reveals max_chars truncates the body by default at 20000, so the description is somewhat misleading. It also does not mention read-only behavior, errors for missing ids, or the response format.

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. Every word contributes to the core meaning: get, full text, one note, by id.

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-parameter getter, the description plus schema is mostly adequate, but there is no output schema or annotation coverage and the 'full text' wording conflicts with the default truncation behavior. Missing behavior on invalid ids and exact return shape leave minor 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 schema documents max_chars including its default and truncation behavior, but the id parameter has no schema description. The tool description only says 'by id,' which adds minimal meaning beyond the parameter name, and it does not mention max_chars at all.

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 clearly states the action (get), the resource (one note), and the selection criteria (by id), and 'full text' sets it apart from list/search siblings. However, it does not explicitly differentiate from upnote_open_note or name alternatives, so sibling differentiation is left somewhat to inference.

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 phrase 'by id' implies this tool is for fetching a specific known note after search or listing, but there is no explicit when-to-use guidance or comparison with alternatives like upnote_search_notes or upnote_list_notes. The usage context is reasonable but not 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?

With no annotations, the description carries the behavioral burden. It conveys that the operation is read-only ('List') and that the note count is dynamic ('live'), which is genuinely useful. It does not mention pagination or return formatting, but for a zero-parameter listing tool this is sufficient.

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 a single tightly worded sentence that leads with the action and resource, then adds the key output detail. Every word earns its place with no redundancy.

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 zero-parameter, read-only listing tool, this description is complete enough: it identifies the resource and the notable returned attribute (live note count). It does not specify the exact response shape, but no output schema exists and the user intent is fully served.

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 has zero parameters, so there is no schema burden for the description to compensate for. The description fully covers what the agent needs to know; no parameter-level context is required.

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 ('List'), a clear resource ('every UpNote notebook'), and a concrete output detail ('with its live note count'). This immediately distinguishes it from sibling tools like upnote_list_notes or upnote_list_tags.

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 intended use is clear: call this when you need an enumeration of all notebooks with their current note counts. It does not explicitly mention alternatives or exclusions, but the tool name and description make the appropriate context obvious among the sibling list tools.

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 behavioral disclosure burden. It adds the 'newest first' ordering behavior, which is useful. But it does not state whether the limit caps results, whether it returns full note content or metadata, or how missing/incorrect notebook titles are handled.

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 a single, front-loaded sentence: 'List the notes in one notebook, newest first.' Every phrase earns its place, with no filler or repetition of schema details.

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?

The core invocation is clear, but with no output schema and a minimal description, an agent may not know what fields are returned or how the limit interacts with ordering. The description is adequate as a minimum viable definition but leaves gaps that would help a caller fully predict behavior.

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 100%, with both 'notebook' and 'limit' documented. The description adds little beyond the schema, only reinforcing that notes are scoped to a single notebook. This matches the baseline for high schema coverage.

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 uses a specific verb ('List') with a clear resource ('the notes in one notebook') and an ordering qualifier ('newest first'). It distinguishes the tool from siblings like upnote_recent_notes by scoping to a single notebook, though it does not explicitly name or contrast an alternative.

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 intended use is implied: call this when you want notes from a specific notebook. However, there is no explicit guidance on when to choose this tool over upnote_recent_notes or upnote_search_notes, nor any exclusions or alternative conditions.

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 burden. 'List all tags' clearly indicates a read-only, non-destructive operation, but it does not disclose details like ordering, return format, pagination, or potential side effects. For such a simple operation this is acceptable, but not rich.

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 a single concise sentence with no filler. It states exactly what the tool does and does so in an immediately understandable way.

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?

This is the simplest possible tool shape: no parameters, no required inputs, no output schema, and no nested structures. The description 'List all tags in UpNote' provides everything needed for an agent to select and invoke the tool correctly.

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 has zero parameters, and the input schema is empty. The baseline for no-parameter tools is 4, and the description does not need to explain parameter meaning because there are none to explain.

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 uses a specific verb and resource: 'List all tags in UpNote.' This clearly distinguishes it from sibling tools like upnote_list_notes and upnote_list_notebooks, so there is no ambiguity about what resource this tool operates on.

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 implies the tool should be used when the agent needs to enumerate all tags, but it does not explicitly state when to use it versus alternatives or mention any exclusions. Since no sibling tool handles tags, the lack of explicit exclusions is acceptable, but the guidance is still only implicit.

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 provided, the description carries the full burden of disclosing behavioral traits. It only says 'Open a note in the UpNote app by id' and does not mention side effects, whether it launches a UI, what happens for invalid IDs, or whether it requires a locally installed app. The agent is left to guess.

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 a single, direct sentence with no filler. It conveys the essential action and input efficiently.

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 very simple one-parameter tool, the description provides the minimal viable information: what happens and which input is needed. However, it lacks guidance on distinguishing it from upnote_get_note and any behavioral expectations, so it is not fully complete.

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 schema only defines 'id' as a required string, and the description offers no additional meaning beyond 'by id'. It does not explain where the ID comes from, its format, or how to obtain it, so the 0% schema coverage is not compensated.

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 clearly states the action ('Open a note'), the resource ('a note'), and the required input ('by id'), so an agent knows what the tool does. It does not explicitly contrast with the sibling upnote_get_note, though 'in the UpNote app' hints at opening the UI rather than just fetching data.

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 use this tool instead of alternatives like upnote_get_note or upnote_search_notes. The description simply states the action without any context about preferred use cases or exclusions.

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?

There are no annotations, so the description carries the full burden of disclosing behavior. It only restates the primary action and does not say whether the notebook must already exist, whether opening creates anything, what happens on a missing title, or whether the operation has side effects.

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 sentence of ten words that front-loads the action and object with no filler or repetition. Every word contributes necessary information.

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?

The tool is simple and the description covers purpose and the one parameter, so an agent can make a plausible call. However, with no annotations and no output schema, the lack of failure behavior, exact-title requirements, and relationship to sibling tools leaves clear 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?

Schema coverage is 0%, but the phrase 'by title' gives meaning to the sole required parameter 'notebook' — it is the notebook's title rather than an ID or object. The description does not specify exact-match behavior or format, but for a single string parameter it provides enough semantic grounding.

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 action ('Open'), a specific resource ('a notebook in the UpNote app'), and the selection method ('by title'). The resource term clearly distinguishes it from the sibling upnote_open_note, which handles notes rather than notebooks.

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 gives no explicit when-to-use guidance, no alternatives, and no exclusions. The agent must infer from the name and sibling list that this is for notebooks rather than notes; it never says to use list_notebooks to resolve titles or open_note for 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?

With no annotations, the description carries the full disclosure burden, but it only states scope and recency. It does not say what fields are returned, whether full note content is included, how the limit applies, or the ordering direction beyond the phrase 'most recently updated'.

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 a single compact phrase with no filler, which is appropriately sized for a simple tool. It is concise but could be restructured as a sentence with a verb without losing brevity.

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?

Without an output schema, the description should clarify what the returned notes contain, but it gives no indication of output structure or whether it returns metadata versus content. It also does not explain the recency semantics or the relationship to get_note for fetching full content.

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 only parameter, limit, is documented in the input schema with its default, so schema description coverage is 100%. The description adds no extra meaning about limit behavior, so the baseline of 3 applies.

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 identifies the resource (most recently updated notes) and the scope (whole library), which distinguishes it from search and list siblings. However, it is a noun phrase rather than an explicit verb+resource sentence, so agents must infer the action of listing or retrieving.

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 offers no guidance on when to choose this tool over upnote_list_notes or upnote_search_notes, and it names no alternatives. The 'whole library' scope is a contextual hint, but there is no explicit when-to-use or exclusion criteria.

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 must bear the transparency burden. It explains what is searched and the optional scope, but doesn't describe result ordering, pagination, matching behavior, or the read-only nature beyond the word 'search'.

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 covers the tool's core purpose and optional scoping. No filler or redundant restatement of the tool name.

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 search tool, the description plus schema covers invocation: required query, optional limit, optional notebook. The lack of an output schema or return-format details is a minor gap rather than a blocker, given the tool's low 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 coverage is 67%, and the description adds meaning to the undocumented 'query' parameter by defining what full text matches (titles and bodies). It also reinforces the optional notebook scope. The limit default remains schema-only, but the essential query semantics are compensated.

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 names a specific verb ('Full text search') and resource ('note titles and bodies'), and notes optional notebook scoping. This clearly distinguishes it from siblings that list, open, or create notes.

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?

It says when to use it: when full-text content search across titles/bodies is needed, with optional notebook scoping. It doesn't explicitly mention alternatives or conditions to avoid it, but the use case is unambiguous.

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