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

With no annotations, the description carries full behavioral burden. It usefully discloses that the tool returns a creation URL without opening a browser and that projectName defaults to 'my-cosense-project'. However, it omits key mutation traits such as auth requirements and, importantly, what happens when the page already exists (overwrite vs error).

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?

Four sentences, front-loaded with the core action and closing with the most actionable constraint (default project). Slightly redundant phrasing ('Scrapbox project on cosense (scrapbox)') but no filler sentences.

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?

No output schema exists, and the description does address the return value (creation URL). For a mutation tool with no annotations, it is adequate but incomplete, missing auth/permission context and duplicate-page behavior that an agent needs before invoking a write operation.

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%, so the schema already documents all five parameters thoroughly, including the markdown/scrapbox format semantics and createActually behavior. The description reinforces title/body/projectName defaults but adds no syntax or meaning beyond the schema, so the baseline 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 gives a clear verb+resource ('Create a new page in Scrapbox project on cosense') and states scope (title + optional body). It distinguishes the tool's core action from read-only siblings like get_page, though it never explicitly names the mutation alternatives (edit_lines, insert_lines).

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 explains the default project behavior but offers no guidance on when to use create_page versus editing existing content with edit_lines or insert_lines. There is no when-not or alternative routing, leaving the agent to infer selection 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?

With no annotations, the description carries the full burden and does so well: it discloses exact-text matching semantics, newline block matching, the matchAll atomicity/refusal rule, the title-line guard, the no-match error, and the required credential (COSENSE_MCP_PAT or COSENSE_SID). Only the success return payload goes unstated, which is minor for a delete 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 with the action, then ordered by importance: matching semantics, matchAll, the title-line guard, error behavior, auth, default project. Every sentence carries information, though the trailing default-project sentence duplicates the schema and could be dropped.

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?

No annotations and no output schema, and the description still covers auth, defaults, edge cases, refusal behavior, and error signaling — enough for correct invocation. It stops short of describing what a successful call returns or whether deleted content is recoverable, which is the remaining gap given there is no 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?

Schema description coverage is 100%, so the schema already documents all four parameters including the matchAll atomicity rule and the projectName default; the baseline is 3. The description mostly restates those defaults ('my-cosense-project', first-match default) rather than adding new parameter semantics.

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 — 'Delete one or more lines from a Scrapbox page' — and immediately distinguishes itself from the closest-looking sibling by noting it refuses the title line and that delete_page is the tool for page removal. An agent can tell delete_lines apart from delete_page and edit_lines 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?

Gives explicit conditional guidance: default behavior deletes only the first match, matchAll deletes every non-overlapping occurrence, title-line targets are refused and should route to delete_page instead. It also states the failure condition ('Returns an error if no match is found'), so the agent knows both the selection condition and the exclusion.

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 burden and does disclose meaningful traits: exact/contiguous matching rules, failure behavior ('returns an error if no match is found'), required credentials (COSENSE_MCP_PAT or COSENSE_SID) and the default project fallback. It stops short of saying the replaced text is permanently overwritten or how history/reversibility works, which matters 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-loads the action and matching rule, then layers defaults, failure mode and auth. Every sentence carries information, though the matchAll sentence partly duplicates the schema and the description runs slightly long for a 6-parameter tool.

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?

Covers matching semantics, matching failure, auth requirements and defaults, which is substantial for a mutation tool with no annotations. With no output schema present, it could have said what a successful call returns, leaving one modest gap.

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%, so the baseline is 3, but the description adds value beyond the schema by documenting the default projectName ('my-cosense-project') and restating matchAll's default and non-overlap rule in prose. The format parameter and its markdown-vs-scrapbox tradeoff are left entirely to the 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?

States a specific verb and resource ('Replace one or more lines in a Scrapbox page') and pins down the matching semantics (exact text, block matching via newlines). An agent can immediately distinguish it from sibling insert_lines and delete_lines because replacement-in-place is named 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?

Gives clear operating context: default single-match behavior, matchAll for every non-overlapping occurrence, and an error when no match exists. It never names the sibling alternatives (insert_lines, delete_lines) or states when replacement is preferable to them, so routing is inferred rather than directed.

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. It discloses key behaviors: it returns 'page content and its linked pages' and specifies the format ('plain text format'). However, it misses details like error handling (e.g., what happens if the page doesn't exist), performance aspects, or authentication needs, which are important for a read operation without annotations.

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 appropriately sized with three sentences that are front-loaded: the first states the purpose, the second details returns, and the third covers defaults. There is no wasted text, but it could be slightly more structured (e.g., bullet points for returns) 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?

Given no annotations and no output schema, the description partially compensates by explaining return values ('page content and its linked pages') and format. However, for a tool with two parameters and no structured output, it lacks completeness in areas like error cases, pagination, or example usage, leaving gaps for an AI agent to infer 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%, so the schema already documents both parameters fully. The description adds minimal value beyond the schema by reiterating the default for 'projectName' ('my-cosense-project'), but does not provide additional context like examples or constraints. This meets 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 clearly states the tool's purpose: 'Get a page from Scrapbox project on cosense (scrapbox).' It specifies the verb ('Get') and resource ('page'), and distinguishes it from siblings like 'create_page' (creation) and 'list_pages' (listing). However, it doesn't explicitly differentiate from 'get_page_url' (which might retrieve a URL rather than content), leaving some ambiguity.

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 usage by stating it 'Uses my-cosense-project project as default if projectName is not specified,' which provides context for when to omit a parameter. However, it lacks explicit guidance on when to use this tool versus alternatives like 'search_pages' or 'get_page_url,' and does not mention prerequisites or exclusions, leaving usage somewhat inferred.

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 behavioral disclosure. It adds useful context: the tool generates a URL without browser interaction and has a default project. However, it does not cover potential errors (e.g., if the page doesn't exist), rate limits, authentication needs, or the exact URL format, leaving gaps in behavioral transparency for a tool with no 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.

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

The description is concise and well-structured, consisting of two sentences that efficiently convey the tool's purpose, behavior, and default parameter. Every sentence adds value: the first defines the action and context, and the second clarifies the default project and non-browser behavior, with no redundant or wasted 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?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the core functionality and default behavior adequately, but lacks details on error handling, return format (beyond 'direct URL'), and differentiation from siblings. Without annotations or output schema, more context would improve completeness for safe agent use.

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 clear descriptions for both parameters in the input schema. The description adds marginal value by reiterating the default project behavior for 'projectName,' but does not provide additional semantic context beyond what the schema already documents, such as examples or constraints on the 'title' parameter. Baseline 3 is appropriate given 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 clearly states the tool's purpose: 'Generate URL for a page in Scrapbox project on cosense (scrapbox).' It specifies the verb ('Generate URL'), resource ('a page'), and platform context ('Scrapbox project on cosense'). However, it does not explicitly differentiate from sibling tools like 'get_page' (which likely retrieves page content rather than just the URL), leaving room for improvement.

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 provides some usage context by mentioning the default project ('my-cosense-project') and that it 'Returns the direct URL... without opening it in browser,' which implies a non-interactive use case. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_page' or 'list_pages,' and does not specify prerequisites or exclusions, relying on implied understanding.

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 burden and does well: it discloses auth requirements (COSENSE_MCP_PAT or COSENSE_SID), the default project fallback, the hop-depth behavior, and that 2-hop yields a larger response. It does not, however, mention pagination, rate limits, or error behavior on a missing page.

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?

Four sentences, purpose leading, each carrying distinct information (scope, use case, auth, default project). The final sentence partially duplicates the schema's projectName default, a minor redundancy, but overall the text is front-loaded and efficient.

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?

With no output schema, the description usefully characterizes the return ('full content in AI-optimized format'), so an agent understands what it receives. Auth prerequisites and the default project are covered; only edge-case behavior (missing page, response size limits) is absent.

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%, so all three parameters are already documented, including the hopCount enum semantics and the projectName default. The description restates the default project and hop behavior without adding syntax or constraints beyond the schema, making 3 the correct baseline.

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+resource (get context for a page) and clarifies scope: returns the target page plus its linked pages at 1- or 2-hop depth. This implies differentiation from the single-page sibling get_page, but it never names or contrasts siblings 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?

Gives a clear use context: 'Useful for understanding the context and related knowledge around a specific topic.' However, it offers no explicit when-not guidance and never names the alternative (e.g., use get_page for a single page's content), leaving the agent to infer the boundary.

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. It discloses the append fallback and default project behavior, adding useful context. However, it does not mention what happens if the page does not exist, how duplicate line matches are handled, or any permission/error conditions. This is adequate but not exhaustive.

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 two sentences, succinct, and front-loaded with the core function. No unnecessary wording or repetition. Every word contributes to understanding the tool.

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 description handles the core insert behavior and fallback logic. It does not cover edge cases like missing pages or ambiguous target lines, but given the schema already documents all parameters and there is no output schema, it is reasonably complete for the tool's 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 100%, so the description adds minimal value beyond what the schema already states. It repeats the default project and append behavior, which are also in the schema. No additional parameter insights are provided, so baseline 3 is appropriate.

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 (insert text after a specified line) and resource (Scrapbox page on cosense). It distinguishes from siblings like edit_lines and delete_lines by focusing on insertion. The verb is specific and the target is unambiguous.

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 when to use the tool: when you need to insert new text after a specific line, with a fallback to appending if not found. It does not explicitly mention alternatives or when not to use it, but the wording provides clear context for typical usage.

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 behavioral disclosure. It does well by describing the return format ('Returns page metadata and first 5 lines of content'), pagination capability (implied through 'skip' parameter), and default project behavior. However, it doesn't mention rate limits, authentication requirements, or error conditions that would be helpful for a read operation.

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 appropriately sized and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds valuable information about usage, return values, sorting options, and sibling differentiation. There's minimal redundancy, though the sorting methods list could be slightly more concise.

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 read-only listing tool with no output schema, the description provides good contextual completeness by explaining what's returned, how to use it versus alternatives, and default behaviors. It covers the essential aspects an agent needs, though additional details about response format structure or error handling would make it more 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some value by listing all sorting methods and explaining the default project behavior, but doesn't provide additional semantic context beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is high.

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 tool's purpose with specific verbs ('browse and list pages') and resource ('from Scrapbox project on cosense'), distinguishing it from sibling tools by explicitly contrasting with search_pages. It provides concrete details about what the tool does, including the scope of returned data (page metadata and first 5 lines of content).

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 explicitly states when to use this tool ('to discover pages by recency, popularity, or alphabetically') and when not to use it ('Different from search_pages which finds content by keywords'), providing clear alternatives. It also includes practical guidance about default project behavior, making it easy for an agent to choose between this tool and its sibling.

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 behavioral disclosure and does so effectively. It reveals important behavioral traits: result limitation ('Limited to 100 results maximum'), search syntax capabilities ('Supports basic search...'), and default project behavior. However, it doesn't mention potential error conditions, authentication requirements, or rate limits, which prevents a perfect score.

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 efficiently structured and front-loaded with the core purpose. Every sentence adds value: purpose statement, usage guidance, return format, limitations, search syntax, sibling differentiation, and default behavior. There's no wasted text, and information is presented in a logical flow.

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 search tool with 2 parameters, 100% schema coverage, and no output schema, the description provides substantial context about behavior, limitations, and usage. It explains what the tool returns ('Returns matching pages with highlighted search terms and content snippets') and search capabilities. The main gap is lack of output format details, which would be helpful given no output schema exists.

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?

With 100% schema description coverage, the baseline is 3, but the description adds meaningful context beyond the schema. It explains the default project behavior ('Uses my-cosense-project project as default if projectName is not specified') and provides search syntax examples that help interpret the query parameter. This adds practical value for parameter understanding.

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 tool's purpose with specific verb ('Search for content') and resource ('within pages in Scrapbox project'), and explicitly distinguishes it from sibling tool list_pages ('Different from list_pages which browses pages by metadata'). This provides excellent clarity about what this tool does and how it differs from alternatives.

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 provides explicit guidance on when to use this tool ('Use this tool to find pages containing specific keywords or phrases') and when to use alternatives ('Different from list_pages which browses pages by metadata'). It also specifies the default project behavior, giving clear context for usage decisions.

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