Server Quality Checklist

Tool Scores

• note_update_draft_bundleB
  3/5.0
  Behavior2/5

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

  With no annotations provided, the description must fully disclose behavioral traits. It indicates mutation ('Updates') and optional eyecatch upload, but does not mention authentication requirements, whether existing data is overwritten, effects of omitting optional fields, or any side effects. This is a significant gap for a write operation.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the primary action, optional behavior, and output. Every word adds value, and there is no redundancy or irrelevant detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 parameters, no output schema, no annotations, and a complex sibling context, the description is too brief. It does not explain the output structure, authentication needs, or how this bundle differs from using note_update_draft and note_upload_eyecatch separately. An agent would lack critical information for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 13% (only bodyHtml is documented), so the description should compensate. It adds meaning for noteKey and eyecatch, but leaves title, verify, hashtags, responseFormat, eyecatchImageUrl, and eyecatchImagePath unexplained. The compact ids/URLs hint relates to responseFormat but does not detail it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool updates a draft by noteKey, optionally uploads an eyecatch, and returns compact ids/URLs. This specific verb+resource combination is understandable, though it does not explicitly differentiate itself from sibling tools like note_update_draft or note_upload_eyecatch.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through 'optionally uploads an eyecatch' and 'returns compact ids/URLs for AI agents', suggesting when you might want both operations in one call. However, it does not explicitly state when to use this over note_update_draft or note_upload_eyecatch, nor does it provide exclusions.

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

• note_set_cookieB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits on its own. It states the cookie is stored and verified by default, but fails to mention whether an existing cookie is overwritten, what happens on verification failure, or any authentication 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.

  Conciseness5/5

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

  Two concise sentences with no redundant detail, front-loaded with the primary action. Every word contributes to understanding the tool's function.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool, the description covers the core action and default behavior, but it lacks usage context relative to sibling authentication tools and does not address failure modes or the effect on existing cookies. This leaves it minimally adequate.

  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?

  The input schema has no parameter descriptions (0% coverage), so the description's mention that verification happens by default adds some meaning to the `verify` parameter. However, it does not elaborate on the `cookie` parameter beyond its name, leaving the semantics partially implicit.

  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 clearly states it stores a note.com Cookie header in the local config file, using the specific verb 'stores' and identifying both the resource and target location. This distinguishes it from sibling tools like note_clear_cookie, which removes the cookie.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool over alternatives such as note_auth_login or note_clear_cookie. It mentions the verification behavior but does not explain contexts, prerequisites, or exclusions for using this tool.

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

• note_auth_statusB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It does disclose a behavioral trait: a read-only check for the presence of a cookie from env or config. However, it omits details about return value, whether it performs network calls, or how it treats missing cookies. For a simple 0-param tool, this is adequate 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.

  Conciseness5/5

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

  The description is a single concise sentence that fully conveys the tool's core function without any redundant words. It is appropriately sized for a 0-parameter tool and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (0 params, no output schema), the description is mostly complete but has gaps. It lacks explanation of the return value or status representation, which would be useful for an agent invoking the tool. It also does not clarify the relationship to the sibling `note_auth_check`, leaving potential ambiguity in tool selection.

  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?

  The tool has zero parameters, so per the rubric the baseline is 4. The description does not need to add parameter semantics since there are none. It correctly focuses on behavior, and the empty input schema is self-explanatory.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: checking whether note-mcp-community has a note.com cookie from env or config file. It uses a specific verb ('Checks whether') and resource (cookie presence), which distinguishes it from writing/auth-related siblings. However, it does not explicitly differentiate itself from the similarly named `note_auth_check` sibling, so it misses the full 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like `note_auth_check` or `note_auth_login`. It implies it is a status check but gives no context on when to prefer it over similar auth-related tools. No exclusions or alternative references are present.

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

• note_markdown_to_note_htmlA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'conservative' and 'not a full Markdown engine,' which hints at limited handling, but it does not specify what happens with unsupported Markdown (e.g., whether it is passed through, stripped, or causes an error), nor does it describe the return format or any 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.

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main function and followed by a key limitation. Every sentence earns its place; there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with no output schema and no annotations, the description covers the core purpose and a significant limitation (not a full engine). However, it does not explain the return value type (e.g., HTML string) or error behavior, which would be necessary for the agent to invoke it confidently in a larger workflow.

  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?

  The schema has 0% description coverage, so the description must compensate. While it does not directly describe the `markdown` parameter, it implies the acceptable input by listing supported Markdown constructs (headings, paragraphs, etc.). This adds some semantic meaning beyond the raw schema, but it does not provide details on formatting, size limits, or edge-case behavior.

  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 specifies a clear verb ('Converts') and resource ('Markdown to simple note.com HTML'), and lists the supported constructs (headings, paragraphs, lists, emphasis, links). It clearly distinguishes itself from sibling tools by being a helper conversion tool, none of which are converters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states it is a 'helper, not a full Markdown engine,' which implies it should be used for simple conversions and not for complex Markdown. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any workflow context or exclusions beyond the limitation.

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

• note_prepare_draftA
  3.5/5.0
  Behavior3/5

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

  The description discloses the main actions (create draft, optionally upload eyecatch) and the return type (compact ids/URLs), which is helpful. However, with no annotations, it does not disclose potential side effects, authentication requirements, idempotency, or what happens to intermediate resources if the eyecatch upload fails.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that immediately states the action and purpose. It is concise with no filler, and every phrase contributes meaning—creating, optional upload, and the output format.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is a compound operation with 7 parameters and no output schema, yet the description gives only a high-level overview. It fails to specify what the returned 'ids/URLs' refer to, how responseFormat affects them, or the likely prerequisite of converting Markdown to HTML (given the sibling note_markdown_to_note_html). The overall workflow is under-explained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 14%, so the description must compensate for undocumented parameters. It provides only a vague hint that eyecatch is optional and that a compact id/URL-based response is returned, but it does not explain the roles of title, bodyHtml (already in schema), hashtags, verify, or responseFormat variants. This is insufficient for a 7-parameter tool.

  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 uses a specific verb ('Creates') with a clear resource ('a draft'), and adds distinct outcomes ('optionally uploads an eyecatch' and 'returns compact ids/URLs'). It distinguishes itself from siblings like note_create_draft and note_upload_eyecatch by bundling these actions, and mentions the target audience (AI agents).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for creating a draft with optional eyecatch upload and compact output, which gives some usage context. However, it does not explicitly state when to choose this over alternative tools such as note_create_draft or note_upload_eyecatch, nor does it mention any exclusions or prerequisites.

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

• note_get_noteA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description discloses that the default response is compact summary fields and that responseFormat:'full' or includeBody:true yields the full body. This adds behavioral context beyond the schema, but it does not cover permissions, error handling, or nuances of the return payload.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the primary action, followed by a useful clarification. No filler or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers core behavior and the summary/full distinction, which is sufficient for basic use. However, it omits the 'fields' parameter, does not describe return structure or error cases, and lacks guidance for alternative tools, leaving gaps for a fully autonomous agent.

  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?

  The description explains noteKey with a concrete example and clarifies how responseFormat and includeBody affect output. Given 0% schema coverage, this meaningfully compensates, though the 'fields' parameter remains undocumented and unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Fetches a note by note key' with an example key, identifying the action and resource. Although there is a sibling note_get_draft, the description doesn't explicitly differentiate between published notes and drafts, but the tool name and context make the purpose reasonably clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a note key is available, but provides no explicit guidance on when to use this tool versus alternatives like note_get_draft or note_list_my_notes. It does not mention exclusions or alternative tool recommendations.

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

• note_update_draftA
  3.6/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the disclosure burden. It reveals the API endpoint, HTML requirement, and response format options, which adds useful behavioral context. However, it does not clarify whether the update replaces or merges existing content, nor does it mention authentication requirements, so transparency is partial.

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

  Conciseness5/5

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

  The description is three concise sentences, with the primary action and endpoint in the first sentence, followed by key payload guidance and response format. No redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 parameters and no output schema, but the description does not explain how the target draft is identified when draftId is optional, nor the role of noteKey, and it omits any mention of authentication or error behavior. This leaves important operational gaps for the agent.

  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 coverage is only 17%, and the description adds meaning to responseFormat (summary vs full) and draftId (via endpoint), and reinforces the body requirement. However, title, noteKey, and hashtags remain undocumented in both schema and description.

  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 clearly states it updates a note.com draft using a specific API endpoint, distinguishing it from sibling tools like create/publish/delete. The verb and resource are explicit, and the API path adds concreteness.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides usage guidance about converting Markdown to HTML and choosing responseFormat, but it does not explicitly state when to use this tool over alternatives like note_update_draft_bundle. The usage context is implied rather than explicit.

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

• note_list_draftsA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It adds useful context: it names the exact endpoint, the default status=draft and without_magazines=true, and the output modes (summary vs. full). However, it does not explain the response structure, pagination behavior beyond defaults, or the purpose of includeBody, leaving behavioral transparency moderate.

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

  Conciseness5/5

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

  The description is compact: two sentences that convey the core purpose, endpoint, and output defaults. Every element is relevant, and the structure front-loads the key action and resource before diving into technical details. No fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and absent output schema/annotations, the description covers the main action and default behavior. However, it omits the meaning of includeBody, does not describe what the summary vs. full output contains, and does not mention pagination handling or how many drafts are returned. It is adequate but not fully complete for an agent to predict all behaviors without extra context.

  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 0%, so the description must compensate. It explains the 'fields' parameter (summary vs. full) and reveals default values for page and limit via the endpoint URL. However, the 'includeBody' parameter is completely unexplained, and page/limit semantics are only implied by their position in the URL, not explicitly defined.

  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 clearly states the tool lists drafts for the authenticated note.com account, using a specific HTTP endpoint. It distinguishes from sibling tools like note_list_my_notes by explicitly mentioning the status=draft parameter. The verb 'lists' and resource 'drafts' are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it clear this tool is for listing drafts, which is an implied use case. However, it does not explicitly tell when to use this instead of note_get_draft or note_list_my_notes, nor does it provide any exclusions or alternative tool recommendations. Usage is inferred from the name and description rather than explicitly specified.

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

• note_list_my_notesA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the safety and behavioral disclosure burden. It reveals the HTTP method (GET), output modes (summary vs full raw payload), and includes pagination defaults via the URL. However, it does not mention the includeBody parameter behavior or potential rate limits.

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

  Conciseness5/5

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

  Two sentences with zero waste: the first states the action and endpoint, the second clarifies the key output parameter. It is appropriately concise and front-loaded with the verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema and 4 parameters, yet the description covers the main listing behavior and output modes. However, it omits the semantics of 'includeBody' and does not describe the return structure beyond 'summary' vs 'raw internal API payload', leaving noticeable gaps for full functional understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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. It only explains the 'fields' parameter (summary default, full for raw payload). The 'page' and 'limit' parameters are only indirectly visible in the URL, and 'includeBody' is entirely unexplained, leaving a significant semantic gap.

  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 uses the specific verb 'Lists' with a clear resource ('notes for the authenticated note.com account') and includes the exact endpoint. It distinguishes from siblings like note_list_drafts by specifying 'my notes' and the authenticated account context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context (reads notes for the authenticated user via a specific GET endpoint) but does not explicitly state when to use this tool over alternatives like note_list_drafts or note_get_note. It lacks exclusions or alternative tool references.

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

• note_auth_loginA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses the browser automation side effect and the persistent write to a config file, which is useful. However, it does not clarify whether existing cookies are overwritten, whether manual user interaction is required, or what happens on failure.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the primary action, then the intended environment and alternatives. Every sentence adds value with no redundancy.

  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 a login-flow tool with no output schema and minimal parameters, the description is largely complete: it states what happens, where cookies are stored, and when to use alternatives. It falls short only by not explicitly describing success/failure return behavior or the headless parameter's effect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and the description adds no meaning to the single 'headless' boolean parameter. The passing phrase about 'remote/headless servers' is indirect and does not explain how the headless parameter behaves or what values are appropriate.

  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 uses a specific verb+resource structure: 'Opens a local Playwright browser login flow and saves note.com cookies to the note-mcp-community config file.' It clearly differentiates from sibling tools by naming the alternative (note_set_cookie) and specifying the local-browser scope.

  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?

  Explicit usage context is provided: 'Intended for desktop/local agents; remote/headless servers should use env or note_set_cookie.' This tells the agent when to use this tool and which alternatives to prefer in other environments.

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

• note_delete_noteA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full burden of behavioral disclosure. It does state that the operation is destructive, which is useful, but it does not explain consequences like permanence, authorization requirements, or what happens to associated data. Adding details about irreversibility or required permissions would improve transparency.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the verb and resource, and contains no redundant information. Every phrase contributes to understanding the purpose and cautions, making it highly efficient.

  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 a simple 1-parameter delete operation, the description covers the core purpose and destructive nature. However, it could be more complete by explaining the distinction between 'published' and 'deleted-capable' notes and whether deletion is permanent. Given the absence of annotations and output schema, a bit more context would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, and the description only references 'note key' without explaining what it is, how to obtain it, or its format beyond the schema's minLength. The description adds no meaningful value over the schema, so it fails to compensate for the lack of parameter documentation.

  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 clearly states the action ('Deletes'), the resource ('a published or deleted-capable note'), and the specific endpoint ('DELETE /v1/notes/n/{noteKey}'). This distinguishes it from sibling tools like note_delete_draft, which deletes drafts rather than published notes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context by warning that it is destructive and should only be used when the caller explicitly wants deletion. However, it does not mention alternatives or conditions when a different tool (e.g., note_delete_draft) would be more appropriate, so it stops short of explicit when/when-not guidance.

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

• note_upload_eyecatchA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses helpful behaviors: noteKey resolution 'through draft detail', default dimensions 1280x670, and the verify option to 'read back compact note state after upload.' However, it omits side effects (e.g., overwriting an existing eyecatch), authentication requirements, or the response structure when verify is false. Thus it is moderately transparent but leaves significant gaps.

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

  Conciseness5/5

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

  The description is four sentences, each adding value: purpose + endpoint, input options, size defaults, and verify behavior. It is densely informative with no filler, and key information is front-loaded in the first sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 10 parameters, no annotations, and no output schema. The description explains the core workflow well but leaves out parameter semantics for fit, targetSize, and responseFormat, and never describes the default response (only verify's read-back). This incompleteness is notable given the tool's complexity, though the description is otherwise strong for the main use case.

  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 0%, so the description must compensate. It explains noteId/noteKey, imagePath/imageUrl, and width/height defaults. But it does not clarify the meaning of 'fit' (none/center-crop/contain), 'targetSize' (only note-eyecatch), or 'responseFormat' (summary/full). Given 10 parameters, the description covers only about half, so it does not fully compensate for the schema's lack of descriptions.

  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 clearly states the tool's function: 'Uploads an eyecatch/cover image for a note via POST /v1/image_upload/note_eyecatch.' This is a specific verb+resource and distinguishes it from sibling note management tools. The title 'Upload note.com eyecatch image' reinforces the purpose unambiguously.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear input guidelines: 'Provide numeric noteId or noteKey' and 'Provide imagePath or imageUrl,' which indicates how to select identifiers and image sources. It also explains that noteKey is resolved through draft detail, implying usage on drafts. However, it does not explicitly contrast with alternative tools or state when not to use it, but given the absence of similar upload tools, this is acceptable.

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

• note_clear_cookieA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavior. It explicitly states the scope (config file cookie deletion) and clarifies what is not modified (environment cookies), providing valuable transparency about side effects and boundaries.

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

  Conciseness5/5

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

  The description is two concise sentences with no filler. The key action is stated first, and the clarifying exclusion is provided in the second sentence, making it minimally sized and well-structured.

  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 a zero-parameter destructive tool with no output schema, the description is largely complete. It covers what is deleted and what is preserved. Missing, though minor, is any note about re-authentication or impact on the current session, but the simplicity of the tool makes this adequate.

  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?

  The tool has zero parameters, and schema coverage is 100%. The description does not need to explain parameters, and the baseline of 4 applies since no parameter information is missing.

  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 clearly states the tool deletes a specific resource (the note-mcp-community config file cookie) and distinguishes it from sibling tools by noting that environment cookies are not modified. The verb 'Deletes' is specific and the resource is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 versus alternatives like note_set_cookie or note_auth_login. The description only states what the tool does, leaving the use case entirely implied.

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

• note_login_helpA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full transparency burden. The word 'Explains' signals an informational, non-mutating behavior, which is useful. However, it does not detail the output format or any caveats about the help content, so disclosure remains minimal.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that wastes no words. It states the verb and resource directly, achieving maximum conciseness.

  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?

  Given the tool's simplicity (no parameters, no output schema, no annotations), the description adequately conveys its purpose. It could be more specific about what 'authentication setup paths' includes (e.g., cookie vs. API key), but for a help-oriented tool, this is sufficient for an agent to select and invoke it.

  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?

  The tool has zero parameters, so schema description coverage is trivially 100%. With no parameters to document, the description does not need to add parameter-specific semantics. The baseline of 4 for zero-parameter tools 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?

  The description uses a specific verb 'Explains' and names the resource 'supported note-mcp-community authentication setup paths', clearly distinguishing it from sibling tools that perform auth actions (note_auth_login, note_auth_status). The purpose is immediately obvious.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for gaining an understanding of authentication setup paths, but it does not explicitly state when to use it instead of related tools like note_auth_login or note_auth_status. No alternatives or exclusions are mentioned, leaving usage inferable but not explicit.

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

• note_delete_draftA
  4.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden for behavioral transparency. It states the action 'deletes' but does not disclose potential side effects such as permanence, authentication requirements, or rate limits. The only additional behavior disclosed is the id format, which is more of a parameter constraint.

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

  Conciseness5/5

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

  The description is concise, with two sentences that each add value: the first states the action and endpoint, the second provides critical id constraints and sources. There is no redundant or filler content.

  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 a simple one-parameter delete tool with no output schema, the description provides the endpoint, id format, and id sources, which is sufficient for correct use. It lacks an explicit note on irreversibility or return value, but these are not critical for a straightforward delete operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides only a generic string parameter, but the description compensates significantly by specifying that the id must be numeric, that note keys like 'n...' are not accepted, and by pointing to exact sources for valid ids. This is essential for correct invocation and goes well beyond the schema.

  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 clearly states the tool deletes a note.com draft, includes the specific endpoint, and differentiates from the sibling tool note_delete_note by focusing on drafts rather than published notes. The action, resource, and scope are all precise.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The context is clear: this tool is for deleting drafts, not published notes. It also provides guidance on obtaining the correct numeric id from other tools. However, it does not explicitly mention when not to use it or name alternatives like note_delete_note, so it falls short of a 5.

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

• note_auth_checkA
  4.2/5.0
  Behavior4/5

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

  The description transparently conveys a read-only verification action through the verb 'checks,' and it clearly identifies that the check is performed against internal APIs using pre-configured cookies. With no annotations provided, this description carries the full burden and does so without contradiction, though it does not detail the exact return format or error handling.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that uses an active verb ('checks') and conveys all essential information without redundancy. Every word serves a purpose, balancing clarity with brevity.

  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 a no-parameter check tool, the description is largely complete—it states the action and target. However, it does not explicitly mention the return value (e.g., boolean indicating success) or prerequisites like cookie configuration, which would make it fully self-contained. Given there is no output schema, this slight omission leaves minor ambiguity, but the simplicity of the tool mitigates the gap.

  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?

  The tool has zero parameters, so the schema is trivially fully covered. The description adds context about 'configured cookies' but does not need to explain parameters. Baseline for 0 params is 4, and the description satisfies it without requiring additional parameter-level detail.

  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 precisely states the tool's function—validating whether configured note.com cookies can access internal APIs—which is a specific verb-resource pairing. It also distinguishes itself from siblings like note_auth_login (which performs login) and note_auth_status (which likely reports status), by focusing on access verification.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage as an authentication pre-check but does not explicitly state when to use it over alternatives. There is no mention of prerequisites (e.g., 'use after setting cookies') or exclusions, leaving the intended context to be inferred from the tool's purpose.

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

• note_get_draftA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It honestly describes the HTTP endpoint and query parameters, and notes that it's 'authenticated', providing some useful context. However, it omits error handling, rate limits, or response format, leaving significant behavioral aspects undisclosed.

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

  Conciseness5/5

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

  Two sentences, each earning its place. The first describes the action and endpoint; the second provides a necessary prerequisite. There is zero filler.

  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 a simple GET operation with a single parameter, it covers purpose, endpoint, auth requirement, and key sourcing. It doesn't describe the response shape, which would be helpful given no output schema, but it remains adequate for a low-complexity tool.

  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 coverage is 0% for noteKey, but the description compensates by explaining that the parameter is a 'note key' and directing the agent to note_list_drafts to find it. This adds practical meaning beyond the bare schema 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 states a specific action ('Fetches an authenticated draft detail') with a clear resource ('by note key') and endpoint. It distinguishes from siblings like note_get_note by explicitly mentioning 'draft=true', making the draft focus unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives a clear prerequisite: 'Use note_list_drafts to find the draft key first.' This tells the agent how to obtain the key. However, it doesn't explicitly contrast with note_get_note or other sibling tools, so it misses a point for lacking an explicit alternative exclusion.

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

• note_create_draftA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the 'unofficial internal API' nature, default LLM-friendly summary return, and the responseFormat switch. It does not mention failure modes or auth requirements, but the provided context is valuable.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the core purpose, followed by a critical caveat (Markdown conversion) and output behavior. Every sentence adds value with no redundancy.

  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?

  Despite lacking an output schema, the description thoroughly covers the tool's behavior: it lists the returned fields (id/noteId/key/noteKey/editUrl/publicUrl/nextActions), explains the default vs raw response, and gives practical guidance on content format. It is sufficient for an agent to invoke correctly.

  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 only 25%, but the description compensates by explaining that body must be note-compatible HTML (not Markdown) and by clarifying responseFormat's 'summary' default. Hashtags and title are less deeply explained, but they are straightforward and partially implied by the description.

  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 clearly states the tool's function with a specific verb and resource: 'Creates a note.com draft with title/body/hashtags'. It distinguishes itself from siblings like note_publish_draft and note_update_draft by emphasizing draft creation via an 'unofficial internal API'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage guidance: converts Markdown to HTML before calling, explains the default response format, and mentions the responseFormat option for raw API payload. However, it does not explicitly state when to choose this over sibling tools like note_prepare_draft, leaving some ambiguity.

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

• note_publish_draftA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and excels. It discloses internal fetch/publish sequence, the crucial fact that Markdown is not converted (saved body sent as editor HTML), and the response format options (summary vs full). This gives the agent essential behavioral expectations without any annotation support.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the primary action, then essential internals, then response behavior. No wasted words; each sentence adds critical information without redundancy.

  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?

  Given two params, no output schema, and no annotations, the description is quite complete. It explains the default return summary and how to get the raw payload, plus a key transformation caveat. It does not describe error cases or post-publish state (e.g., whether draft remains), but this is not essential for invocation, so it is adequate for a tool of this complexity.

  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 coverage is 0%, so the description must compensate. It explains the responseFormat parameter in detail ('pass responseFormat: "full" for the raw API payload') and implies the role of noteKey. While noteKey's semantic is left implicit, the description adds meaningful context for responseFormat, which the schema enum alone does not convey.

  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 action ('Publicly publishes a draft') with a clear resource ('by note key'). This clearly differentiates from sibling tools like note_create_draft or note_delete_draft, whose purposes are distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: this is the tool for publishing a draft to make it public. It does not explicitly name alternatives or exclusions, but the context is unambiguous given the description and sibling tool names, so it meets the 'clear context, no exclusions' bar.

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