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

With no annotations, the description carries the full burden. It does disclose key side effects: 'Creates Zettelkasten notes for context content and stores references in user profile.' This reveals the write operations and integration. However, it doesn't mention reversibility, permissions, or the behavior of auto-classification failure. It adds some context beyond the schema but remains incomplete.

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 concise sentences that front-load the primary action and then explain key outcomes. No redundant or filler content; every clause contributes value.

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

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

The tool has no output schema, so the description should ideally explain return values or expected results. It covers the main behavior and side effects but omits return format, error cases, and edge behaviors. Given the tool's moderate complexity and lack of annotations, this is only partially 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal parameter semantics—only mentioning 'auto-classification' which relates to the autoClassify parameter, but doesn't elaborate on category or context formats. Baseline 3 is appropriate as schema does the heavy lifting.

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 function: 'Add user context from natural language with auto-classification.' It specifies the resource (user context) and the action (add), and adds behavioral details (creating Zettelkasten notes, storing references). However, it doesn't explicitly differentiate from sibling tools like createZettelkastenNote, though the 'from natural language' and 'user profile' aspects help distinguish.

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

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

No guidance is provided on when to use this tool versus alternatives. The description implies usage for adding user context but does not mention exclusions, prerequisites, or alternative tools. It lacks the 'use this when' clarity needed for a tool with many siblings.

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 burden of disclosing behavior. It explains that archived notes remain searchable but have lower priority, and that they are preserved. This gives meaningful insight into the post-archive state, though it does not mention reversibility or effects on links.

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 exactly two sentences with no filler. The first sentence states the action, and the second provides key behavioral context. Every word earns its place.

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

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

For a simple tool with two well-documented parameters and no output schema, the description adequately covers what the tool does and its behavioral impact. It communicates the core concept of archiving without needing additional return-value details.

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 noteId and reason. The description adds no parameter-specific detail beyond the schema, matching the baseline of 3.

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 function: 'Archive note (move to archived status) in Zettelkasten lifecycle.' It specifies the verb (archive), resource (note), and lifecycle context, distinguishing it from siblings like promoteToLongTerm and deleteGuideNote.

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 clear usage context: 'Archives rarely accessed notes while preserving them for future reference.' It also clarifies the continued searchability and lower priority, which helps differentiate from deletion. However, it does not explicitly name alternative tools for when not to use this.

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 full burden for behavioral disclosure. It does state the promotion and archival actions and the triggering criteria, but it omits side effects, reversibility, destructive nature, permission requirements, or return value. For a tool that mutates note storage, this is a significant transparency gap.

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?

Two sentences, front-loaded with the main purpose and immediately followed by concrete behavioral detail. Every word earns its place; no fluff or redundancy.

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

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

The tool has no annotations, no output schema, and zero parameters, but the description explains its core purpose and behavior. Still, it lacks details about invocation expectations, what 'long-term memory' and 'archive' concretely mean, whether the operation is reversible, and what the result looks like—leaving the description only partially complete for an agent.

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

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

The input schema is empty with zero parameters, so there are no parameter semantics to explain. The description's mention of access count and recency adds context about internal decision criteria but is not required to document parameters. Baseline of 4 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?

Description uses specific verb 'Auto-manages' with resource 'notes' and clearly scopes behavior to Zettelkasten lifecycle: promoting frequently accessed notes to long-term memory and archiving rarely used notes based on access count and recency. This clearly distinguishes it from sibling tools like promoteToLongTerm and archiveNote by describing an automated aggregate behavior.

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

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

Usage is implied through 'based on usage patterns in Zettelkasten lifecycle'—the agent can infer this is for automatic lifecycle management. However, there is no explicit statement of when to choose this over manual alternative tools, nor exclusions or prerequisites.

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 full responsibility for behavioral disclosure. It only states that it checks connection status, without explaining side effects, return values, or error behavior. The description adds little beyond what the tool name implies, offering minimal transparency.

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

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

The description is a single sentence, highly concise and front-loaded with the action and subject. There is no unnecessary content, making it appropriately sized for a simple health-check 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 is incomplete for an agent to fully understand the tool's behavior. Since there is no output schema, the description should mention what the tool returns or whether it throws on failure, but it does not. The zero parameters simplify the tool, but the lack of return information leaves a significant 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?

The tool has zero parameters, so there are no parameter meanings to convey. The baseline score of 4 is appropriate because the description does not need to compensate for missing parameter documentation.

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 checks MongoDB connection status, using the specific verb 'Check' and the resource 'MongoDB connection status.' This distinguishes it from all sibling tools, which are knowledge base operations like retrieving, creating, or updating notes and pages.

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

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

There is no guidance on when to use this tool versus alternatives. The description provides no context for when a connection check is needed, how it relates to other tools, or any prerequisites for calling it.

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 burden of behavioral disclosure. It explains the Zettelkasten method and auto-linking by tags, which is valuable. However, it omits specifics such as whether existing notes are modified, the impact of missing tags, or how guide notes differ from regular notes.

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 three sentences, with the first sentence stating the core action. The second and third sentences provide context on the Zettelkasten method and intended use, though there is some redundancy (e.g., 'interconnected knowledge networks' repeats the auto-linking idea). Overall, it is efficiently written.

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

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

The tool is moderately complex with auto-linking side effects, yet the description does not explain what auto-linking does to existing notes, prerequisites, or the difference from the sibling 'createZettelkastenNote'. With no annotations and no output schema, the description is adequate but leaves notable gaps.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that tags drive auto-linking and that notes are atomic, which clarifies the purpose of the 'tags' and 'content' parameters.

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 creates a 'Zettelkasten guide note' with auto-linking by tags, using a specific verb and resource. However, it does not distinguish itself from the sibling tool 'createZettelkastenNote', which appears to serve a similar purpose.

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 mentions 'Use for creating interconnected knowledge networks,' which gives a general usage context. However, it does not provide guidance on when to use this tool over alternatives like 'createZettelkastenNote' or mention when not to use it.

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. 'Create a new project' does not mention possible side effects, duplicate handling, required permissions, or return values, leaving the agent without critical operational details.

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

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

The description is a single, concise, front-loaded sentence that immediately conveys the core function. It contains no unnecessary words or repetition.

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

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

For a simple create tool with two parameters and no output schema, the description is minimal but adequate. However, it lacks behavioral context (e.g., error conditions, idempotency, return format) that would fully prepare an agent, especially given the lack of annotations.

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

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

Schema description coverage is 100%, with both 'name' and 'description' documented in the schema. The description adds no extra semantic meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description 'Create a new project' clearly states the action (create) and the target resource (project). It effectively distinguishes itself from sibling tools like deleteProject, listProjects, and updateProjectStatus.

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 through its name and action, but provides no explicit context about when to use this tool versus alternatives. There is no mention of prerequisites, such as needing an existing user or workspace, nor exclusions for when not to use it.

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 full disclosure burden. It mentions auto-linking, usage tracking, and status management, which are important behavioral traits, but remains vague about specific side effects like whether existing notes are modified or whether permissions are required. This provides moderate transparency without contradicting any 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 compact at two sentences and front-loads the core purpose. However, the second sentence partially restates the first, adding some redundancy. It is still concise and easy to parse, earning a strong score.

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 moderate complexity (5 parameters, no output schema), the description covers the tool's primary function and key behaviors like auto-linking and lifecycle management. It lacks details on return values or post-creation effects, but the schema covers parameter meanings, so the description is adequate but not exhaustive.

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 explains all five parameters. The description adds thematic context about tag-based linking and lifecycle management but does not introduce parameter-specific details beyond the schema, matching 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 a specific verb ('Create') and resource ('strategic Zettelkasten note') with unique features like auto-linking and lifecycle management. It distinguishes itself from sibling tools such as createGuideNote by emphasizing Zettelkasten note-specific behavior, making its purpose 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 focuses on what the tool does but provides no explicit guidance on when to use it over alternatives like createGuideNote or createProject. It does not mention exclusions or context where this tool is preferred, leaving the agent to infer usage solely from the 'Zettelkasten' keyword.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly warns that deletion is irreversible and that links are removed, which are critical side effects. However, it does not explain the exact nature of 'remove its links' or potential error states, leaving some gaps.

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

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

The description is a single sentence that front-loads the primary action, includes a parenthetical danger warning, and contains no unnecessary words. Every element earns its place in a highly compact structure.

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

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

The tool is simple (one parameter, no output schema), and the description communicates the core destructive behavior and irreversibility. It omits details about error conditions or the full impact on linked notes, but for a delete operation, the coverage is largely sufficient.

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 already provides 100% coverage of the single parameter noteId, described as 'Guide note ID to delete'. The description adds no additional parameter semantics beyond what the schema already supplies, so the baseline score of 3 applies.

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

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

The description clearly states the action (delete), the target resource (guide note), and a key side effect (remove its links). This distinguishes it from sibling tools like archiveNote or deletePage, making the tool's purpose 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 provides no explicit guidance on when to use this tool versus alternatives such as archiveNote or deletePage. It warns that the action is irreversible but does not mention any conditions, prerequisites, or cases where an alternative should be preferred.

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 full responsibility for behavioral disclosure. It only says 'Delete a page,' implying a destructive operation but omitting whether deletion is permanent, cascades to children, requires special permissions, or can be undone. This is a significant gap 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?

The description is a single, concise sentence with no wasted words. It is efficiently front-loaded, though it lacks structural elements that could provide additional context. For a simple tool, this level of conciseness is acceptable.

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 destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain return values, error behavior, side effects on related data, or what constitutes a successful deletion. The two parameters are documented, but the overall operational context is missing.

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?

Both parameters are fully described in the schema ('Page ID' and 'Project ID'), so the baseline is 3. The description adds no additional meaning, such as the relationship between projectId and pageId or any constraints, but the schema already covers the basics.

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 deletes a page, using a specific verb and resource. It distinguishes from siblings like getPage and upsertPage, but doesn't clarify whether 'page' includes guide notes or other entity types, so it's not fully differentiated.

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

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

No guidance is provided on when to use this tool versus alternatives like archiveNote or deleteProject. It lacks prerequisites, exclusions, and example scenarios, leaving the agent without contextual decision support.

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 transparency burden. It directly discloses the irreversible nature ('DANGER: Irreversible') and the extent of deletion ('entire project and all its pages'). However, it does not detail side effects on related data or permissions beyond the irreversible warning.

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

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

The description is a single, front-loaded sentence that wastes no words. It communicates the core action and the critical warning efficiently.

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

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

For a simple delete-by-ID tool with one parameter and no output schema, the description captures the essential scope and risk. It could mention the outcome on success or any prerequisites, but the current information is sufficient for an agent to decide whether to invoke it.

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 input schema fully documents the only parameter (projectId) with a clear description. The tool description does not add additional meaning, so the baseline score of 3 applies.

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

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

The description clearly states the action (delete) and the resource (entire project and all its pages), distinguishing it from sibling tools like deletePage by explicitly including all pages. The DANGER warning also signals the destructive scope.

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 when you want to remove a whole project including its pages, but it does not explicitly mention alternatives such as deletePage for single-page deletion. No exclusionary guidance is provided, so it relies on the tool's name and scope rather than explicit when-to-use/when-not-to-use instructions.

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?

The description includes a 'DANGER: Irreversible' warning, which is a useful behavioral disclosure. However, with no annotations, it fails to explain the scope of deletion (e.g., what categories cover, whether clearAll wipes everything) or side effects beyond irreversibility.

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

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

The description is a single, front-loaded sentence with a prominent danger warning. Every word earns its place, achieving maximum 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?

Despite full schema coverage, the description is incomplete for a destructive tool with no annotations or output schema. It does not specify behavior when both parameters are provided, what happens with no parameters, or what the return value indicates.

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 fully documents both parameters with descriptions. The tool description adds no additional semantic meaning beyond what the schema provides.

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 deletes user context data with a specific verb and resource. However, it does not explicitly differentiate itself from sibling tools like deleteUserContextItem, which deletes a single item rather than a category or all data.

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

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

No guidance is provided on when to use this tool versus alternatives such as deleteUserContextItem or resetUserProfile. The only additional information is the danger warning, which is not usage direction.

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. It discloses that the operation is a soft delete, preserves content, and updates Zettelkasten note status and access tracking, adding behavioral detail beyond the tool name. It could mention permissions or idempotency but is reasonably transparent.

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

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

Three concise sentences with front-loaded main action followed by behavioral details. No redundant or unnecessary content.

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

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

For a single-parameter soft-delete tool with no output schema, the description covers the core purpose, behavior, and lifecycle context. It lacks explicit differentiation from sibling delete tools but is otherwise 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?

Schema description coverage is 100%, with itemId described as 'Guide Note ID or item ID to soft delete'. The tool description adds no additional parameter semantics beyond referencing 'by ID', 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 (soft delete), the specific resource (user context item by ID), and the lifecycle context (Zettelkasten). It distinguishes from siblings like deleteUserContext by emphasizing 'specific item' and 'soft delete', and from undeleteUserContextItem by its deletion nature.

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 for removing a single user context item while preserving restorability, but it does not explicitly state when to use this tool versus alternatives like deleteUserContext or deleteGuideNote. No exclusions or alternative guidance are provided.

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 of behavioral disclosure. It describes the high-level actions (merge, split, refine) but fails to disclose whether the operation is destructive, how it affects associated notes, or whether it can be reversed. The behavior on invocation without parameters is also unclear.

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, two sentences, with the purpose front-loaded. Every sentence contributes meaningful detail without repetition or fluff.

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

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

The tool's complexity (optional parameters, nested objects, no output schema) demands more context. The description does not explain what happens when no parameters are provided, what the tool returns, or the operational scope (entire knowledge base vs. specific note). This is a notable gap for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description's mention of merging and splitting tags aligns with mergeTags and splitTags parameters, but it adds no extra insight into parameter semantics, such as interaction when multiple are provided or behavior when noteId is specified. The schema descriptions alone are sufficient.

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: 'Evolve and optimize Zettelkasten tags' and lists specific actions (merges similar tags, splits overly broad tags, refines taxonomy). This distinguishes it from sibling tools, which focus on other knowledge base operations.

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 for tag reorganization, mentioning 'merges similar tags, splits overly broad tags,' but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No alternative tools are referenced, and prerequisites are omitted.

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 must carry the full burden of behavioral disclosure. It does not explicitly state that the operation is read-only, nor does it mention authentication, rate limits, or potential costs of fetching the complete network. The word 'Get' implies a read operation, but that is only implicit.

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

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

A single, front-loaded sentence states the action and result with no filler. It earns a high score for efficiency.

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

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

The tool has no output schema and no annotations, but its low complexity (zero parameters) reduces the burden. The description conveys the shape of the response (nodes/edges representing notes and relationships) and the full-network scope, though it could mention whether isolated notes are included.

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 input schema has zero parameters, so there is nothing to explain; the description correctly offers no parameter guidance, earning the baseline for a parameterless tool. It adds meaningful output context by mentioning nodes/edges and relationships.

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?

Description opens with the specific verb 'Get' and a concrete resource: 'guide note graph'. It further specifies the graph contains nodes/edges and represents the 'complete Zettelkasten knowledge network', clearly distinguishing it from sibling tools like getTree or getPage.

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

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

The phrase 'for visualization and analysis' gives a clear intended use case, but it does not compare with sibling tools such as getTree or getZettelkastenInsights nor state when not to use it. This is clear context but lacks explicit exclusions or alternatives.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does reveal the get-or-create side effect, but lacks details on idempotency, authentication, or what happens if creation fails.

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

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

The description is a single concise sentence that avoids redundancy. However, it is under-specified in other dimensions, though this dimension only evaluates 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 the simplicity of the tool (no parameters, no output schema), the description should nevertheless clarify what a 'user key' is and what the return value represents. It also fails to place the tool within the knowledge base context.

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 input schema has zero parameters, so there are no parameter semantics to explain. The description does not need to add parameter information; baseline 4 for no-param tools 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 identifies the tool's purpose: retrieving an existing user key or creating one if it doesn't exist. It uses a specific verb-resource pairing, though it doesn't distinguish from sibling tools or provide scope.

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 no guidance on when to use this tool versus alternatives like getUserProfile or addUserContext. There is no mention of prerequisites or typical use cases.

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 must carry the full burden of disclosing behavioral traits. It implies a read-only operation via 'get' but does not explicitly state its safety, permissions, rate limits, or behavior for missing pages, offering minimal transparency beyond the verb.

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

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

The description is a single, direct sentence with no wasted words. It front-loads the core action and resource, making it immediately readable and efficiently structured.

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

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

For a simple retrieval tool with fully documented parameters, the description is minimally sufficient. However, it omits any mention of return format, error behavior, or how projectId scopes the request, which would be helpful given the absence of an output schema.

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

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

Schema description coverage is 100% for both parameters ('Page ID' and 'Project ID'), so the baseline is 3. The description adds no additional meaning beyond the schema, such as the relationship between projectId and pageId, but the schema already provides adequate per-parameter clarity.

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 gets a page by its ID, using a specific verb and resource. It implicitly distinguishes from sibling tools like getTree or search by specifying the retrieval method, but it does not explicitly contrast itself with 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?

There is no guidance on when to use this tool versus others. The description provides no prerequisites, use cases, or exclusions, leaving the agent to infer usage from the action 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 provided, the description must disclose behavioral traits itself. It only says 'Get page tree structure', without explaining return format, recursion depth, read-only nature, or side effects. Minimal value beyond the verb.

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 in length but essentially restates the tool name with minimal added detail. It is front-loaded but under-specified, limiting its usefulness.

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 output schema and no annotations, the description should explain what the tree structure contains, how depth is handled, and how it complements other tools. It does not, leaving significant gaps for an agent.

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

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

Schema description coverage is 100% with projectId described as 'Project ID'. The tool description adds no additional meaning to the parameter, so the baseline score of 3 applies.

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

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

The description clearly states the verb 'Get' and the resource 'page tree structure', indicating a read operation for hierarchical page data. It is distinguishable from getPage (single page) and getGuideNetwork (network), but lacks explicit scoping or contrast.

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

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

There is no guidance on when to use this tool versus siblings like getPage or getGuideNetwork. The description provides no usage context, prerequisites, or alternative recommendations.

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 must disclose behavior on its own. It reveals the 'get or create' side effect, which is important. However, it does not explain the meaning of 'memory context', creation conditions, or return behavior, leaving gaps.

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

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

The description is a single, clear sentence of seven words. It front-loads the action and resource without any wasted words.

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

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

For a simple tool with no parameters, the description is adequate but thin. It leaves 'memory context' undefined and does not clarify when a profile is created versus returned or how this relates to other user profile tools.

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

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

The tool has zero parameters, so the baseline is 4. The schema is empty and there is nothing to document beyond what the description implies.

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

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

The description clearly states the action (get or create) and the resource (user profile) with memory context. It distinguishes from sibling tools by targeting the user profile itself, though it does not explicitly name 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?

No guidance is provided on when to use this tool versus related tools like getOrCreateUserKey or updateUserProfile. The description lacks any context for selection.

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 describes the analysis dimensions and that recommendations are produced, but it does not disclose whether the tool is read-only, what the output format is, or any side effects. This leaves significant gaps for an agent considering the 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?

Two concise sentences that front-load the primary action ('Extract insights') and then detail the key analysis areas. There is no filler or redundant information, making it highly 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?

The tool is an analytics function without an output schema, so the description should clarify return values. It does mention 'strategic recommendations' as the outcome, but it does not describe the structure or nature of the insights. Given the complexity and lack of schema richness, the description is adequate but leaves room for more detail about the response format and how to best apply the filters.

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 descriptions cover all 3 parameters, so the baseline is 3. The description's references to 'usage patterns' and 'tag evolution' loosely relate to the filters, but it does not add specific meaning beyond the schema, such as how the filters affect the analysis.

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 identifies the tool's function: extracting insights and patterns from the Zettelkasten knowledge base. It enumerates specific analysis areas (note relationships, usage patterns, tag evolution, knowledge gaps) and a distinct outcome (strategic recommendations), which differentiates it from sibling CRUD/search tools, though it does not explicitly name 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 a clear context for when to use the tool: for knowledge management optimization. It states the purpose is to obtain strategic recommendations, which implies a use case. However, it lacks explicit exclusions or alternative tool guidance, 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.

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

The description discloses that the linking is bidirectional, which is a key behavioral trait not captured in the schema. However, with no annotations provided, it does not disclose important behaviors such as whether the notes must already exist, whether existing links are replaced/updated, or what the operation returns on success or failure. The bidirectional detail adds some value but the description does not fully carry the transparency burden.

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 and front-loads the primary action. The first sentence is direct and specific. The second sentence, while explaining the benefit, is somewhat redundant with the first (creating explicit connections is effectively the same as linking). Still, the overall length is appropriate and there is no filler.

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

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

The tool has no output schema and no annotations, yet the description does not mention return values, error conditions, or prerequisites such as whether the notes must already exist. For a mutation-like operation that creates links, this is a significant gap. The description tells what the tool does but not what the agent should expect after calling it.

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

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

The schema has two required string parameters with no descriptions (0% coverage). The description adds that the parameters refer to 'two guide notes' and that the operation is bidirectional, which helps clarify the role of sourceId and targetId. However, it does not explain ID formats, how to obtain valid IDs, or any constraints, so it only partially compensates for the schema's lack of detail.

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 ('Link two guide notes bidirectionally') and the specific resource ('Zettelkasten network'), making it highly distinguishable from sibling tools that create, search, or manage notes but not explicitly link them. The verb and resource 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.

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 want to create explicit connections between notes for better navigation) but does not explicitly state when not to use it or mention alternative tools. There are no exclusions or alternative references, leaving usage guidance to be inferred rather than spelled out.

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 of behavioral disclosure. It merely states 'List all projects,' which implies a read-only operation but does not disclose whether it returns all projects for the user, what fields are included, pagination behavior, or permission requirements. This is a significant gap for a tool with no annotation coverage.

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

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

The description is a single terse sentence, 'List all projects,' with no unnecessary words. It is appropriately sized for the tool's simplicity and every word earns its place.

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?

Despite the low complexity, the description is too bare to fully inform the agent about the response. With no output schema, the description should at least hint at what a 'list' returns (e.g., project IDs, names, statuses), whether archived projects are included, or if there's any scoping. The current text leaves too much to inference.

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

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

The tool has zero parameters and an empty schema, so the description does not need to add parameter-level meaning. The baseline for zero-parameter tools is 4, and the description appropriately avoids inventing parameters.

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 lists all projects, using a specific verb and resource. It doesn't explicitly differentiate from sibling search or getTree tools, but the resource (projects) is unambiguous enough to distinguish it from create/delete/update actions.

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 no guidance on when to use this tool versus alternatives like search or getTree. There are no exclusions, prerequisites, or context about filtering capabilities, so the agent receives no usage direction.

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, and the description only states the basic action without disclosing side effects (e.g., child pages, order changes), permission requirements, or reversibility.

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

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

The description is a single concise sentence, front-loaded with the essential action, but it could be more informative 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?

For a tool with no annotations or output schema, the description is too minimal to understand implications like hierarchy changes or cascading effects; schema exists but doesn't explain behavioral context.

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 input schema covers 100% of parameter descriptions, so the baseline is 3. The description adds no additional parameter context.

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 'Move a page to a new parent' clearly identifies the action (move), resource (page), and destination (new parent), distinguishing it from sibling tools like deletePage or upsertPage.

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

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

No guidance on when to use this tool versus alternatives like upsertPage or getTree; no prerequisites or exclusions are mentioned.

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 the core state transition and consequences like 'permanent retention' and 'enhanced discoverability', but does not explain whether the candidate status is removed, if the operation is reversible, or any authorization requirements.

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, front-loaded with the action verb, and every word adds value. No filler or redundant 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?

For a simple state-transition tool with well-documented parameters and no output schema, the description provides the lifecycle rationale, expected outcome, and tagging context. Minor omissions like idempotency or handling of non-candidate notes do not significantly impact completeness.

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 input schema already fully describes both parameters (noteId and additionalTags) with 100% coverage. The description adds no additional parameter-level context, 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 uses a specific verb 'promote' and clearly identifies the resource ('candidate note') and its target state ('long-term memory'), set within the Zettelkasten lifecycle. This distinguishes it from siblings like archiveNote or autoManageNotes, which have different purposes.

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 a clear condition for when to use the tool: 'Moves frequently accessed notes' from candidate to long-term status. It implies the use case but does not explicitly mention alternatives or exclusions relative to sibling tools.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly warns 'DANGER: Irreversible', which is a key behavioral trait beyond what the schema or name conveys. However, it does not explain what 'default values' encompass or the role of the keepUserKey parameter, leaving some ambiguity.

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

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

The description is a single, front-loaded sentence that states the action and includes a prominent danger warning. Every word earns its place, making it highly concise and effective.

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?

While the description is adequate for a simple reset tool, it lacks context about the user key (keepUserKey) and the exact effects of resetting. Given the irreversible nature and optional parameter, more detail would improve completeness, but the tool is relatively simple.

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

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

Schema coverage is 100% with the only parameter keepUserKey already fully described in the schema. The tool description does not add any parameter-specific information, so the baseline score of 3 applies.

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

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

The description 'Reset user profile to default values' clearly states the action and resource, distinguishing it from sibling tools like updateUserProfile and getUserProfile. The 'DANGER: Irreversible' warning adds further clarity about the operation's nature.

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 this tool is for resetting a user profile to defaults, but it does not explicitly state when to use it versus alternatives like updateUserProfile. The danger warning serves as a caution, but no concrete usage context or exclusions are provided.

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 full behavioral disclosure burden. It only states the search scope but does not mention matching behavior (exact/substring), case sensitivity, pagination, result format, or any side effects. This is minimal for an agent to anticipate tool behavior.

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

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

The description is a single, front-loaded sentence with no wasted words. Every term ('Search', 'pages', 'title', 'content') adds distinct meaning.

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

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

For a simple two-parameter search with full schema coverage and no output schema, the description covers the core purpose but omits return-value expectations and how results are ordered or limited. It is minimally adequate but lacks completeness for an agent to fully predict outcomes.

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 covers both parameters with basic descriptions. The tool description adds value by clarifying that the 'query' parameter searches both title and content, which is not evident from the schema's 'Search query' description.

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

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

The description uses a specific verb ('Search') and resource ('pages'), and identifies search fields (title or content). It clearly distinguishes from the sibling tool 'searchByTag', which searches by a different dimension.

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 use for text-based page search, but does not explicitly state when to use this tool versus alternatives like 'searchByTag' or 'getPage'. No exclusions or alternative tool references are provided.

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

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

No annotations are present, so the description must disclose behavior. It mentions an important side effect: 'Updates access tracking for discovered notes', which signals the tool mutates tracking state. However, it does not describe the return format, potential errors, or permission requirements, leaving some 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.

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

The description consists of three concise sentences: the primary action, the scope, and the side effect. It is front-loaded with the main verb and resource, with no redundant information.

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

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

The tool is relatively simple (2 params, no output schema, no annotations), and the description covers the search scope and side effect. However, it does not state what the tool returns, which is a gap given the absence of an output schema.

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

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

Both parameters have full schema descriptions ('Tag to search for' and 'Filter by status...'), and the tool description does not add additional semantics beyond the schema. Since schema coverage is 100%, baseline is 3.

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

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

The description uses the specific verb 'Search' with the resource 'all notes by tag across all types in the unified Zettelkasten knowledge base', and explicitly notes it searches user context, project notes, and guide notes simultaneously. This distinguishes it from sibling tools like 'search' and 'getPage'.

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 indicates the tool's scope (all note types simultaneously) but does not explicitly say when not to use it or name alternative tools. It implies usage for tag-based searching across all types, providing clear context but no exclusions.

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

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

No annotations are present, so the description carries the full burden. It discloses the key behavioral trait (status changes from 'deleted' to 'candidate'), which is useful. However, it does not mention permissions, error behavior (e.g., if the item isn't found or isn't in 'deleted' state), or reversibility (though it is itself a reversal).

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?

Two sentences, front-loaded with the action, and zero filler. Every word contributes to conveying purpose and effect. Excellent conciseness and structure.

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

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

For a simple single-parameter tool with no output schema and no annotations, the description covers the core purpose and effect. However, it lacks mention of return values, error cases, or prerequisites (e.g., item must be in 'deleted' state), leaving some gaps for a fully contextual understanding.

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 input schema covers 100% of the parameter with a clear description ('Guide Note ID or item ID to restore'). The tool description adds minimal extra meaning beyond the schema, mostly clarifying that the item is a soft-deleted user context item. 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 uses a specific verb ('Restore') and resource ('soft deleted user context item') and clearly states the state transition from 'deleted' to 'candidate' in the Zettelkasten lifecycle. This distinguishes it from sibling tools like deleteUserContextItem and archiveNote.

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 usage context is implied: it is for undoing a soft deletion and restoring access/usage tracking. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites beyond the item being soft deleted.

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 of behavioral disclosure. It identifies the operation as an 'update' (mutation), but does not disclose what happens to existing data, whether updates are partial or full overwrites, or any permissions/requirements. This is thin 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?

The description is a single, front-loaded sentence with no fluff. It is concise and to the point, but its brevity comes at the cost of substance, which is reflected in other dimensions. Still, for structure and conciseness alone, it earns a 4.

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 complexity (6 parameters, nested object, no output schema), the description is far too sparse. It does not explain the update behavior, how milestones are structured, or what the response contains. A mutation tool like this needs at least a note about overwriting semantics or return values.

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 six parameters. The description adds no parameter details and actually underrepresents the schema by only mentioning 'status and milestones' while omitting notes, techStack, and description. It neither compensates nor contradicts, so 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 uses a clear verb ('Update') with a specific resource ('project status and milestones'). It distinguishes from sibling tools like createProject, deleteProject, and listProjects. However, it omits other updatable fields (notes, techStack, description) from the schema, making it slightly narrower than the actual capability.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., project existence), nor does it contrast with createProject or deleteProject. The only implied usage comes from the tool's name, but the description itself offers no context.

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 for behavioral disclosure. 'Merge behavior' provides a hint about partial updates, but it does not explain side effects, return values, shallow vs deep merging, or whether unspecified fields are preserved.

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

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

The description is a single concise sentence with no filler or redundant phrasing. It is front-loaded and efficient, though it could benefit from a bit more detail without becoming verbose.

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

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

For a simple one-parameter tool, the description and schema together cover the core action and parameter semantics. However, the lack of annotations, output schema, and details about merge depth or return behavior leaves some gaps, making this minimally acceptable but not 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 has 100% description coverage for the only parameter ('updates' described as 'Profile updates to merge'). The description's 'merge behavior' adds no new meaning beyond the schema, 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 uses a specific verb and resource ('Update user profile') and adds 'merge behavior' which distinguishes it from sibling tools like resetUserProfile and getUserProfile. It clearly states what the tool does.

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 'merge behavior' implies that this tool is for partial updates rather than full replacement, giving some context for use. However, there are no explicit exclusions or references to alternatives, such as when to use resetUserProfile instead.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Create or update a page' but doesn't explain whether the operation is idempotent, how update is triggered (pageId), what happens to missing or conflicting fields, or whether it overwrites content. This is a significant transparency gap 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?

The description is a single, short sentence that is easy to parse and front-loaded. However, the brevity borders on under-specification, which limits its usefulness. It is concise, but the conciseness comes at the cost of essential behavioral details.

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

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

The tool has 7 parameters, no output schema, and no annotations, yet the description provides only the minimal 'Create or update a page'. It fails to explain the upsert semantics, required field relationships, or update-vs-create conditions, making it incomplete 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.

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

Since schema description coverage is 100%, the baseline is 3. The description adds no parameter-level meaning beyond what the schema already provides, and it fails to highlight the role of optional parameters like pageId for updates or tags/order for metadata. It neither compensates nor detracts.

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

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

The description states a clear action ('Create or update') and resource ('a page'), which aligns with the tool name and distinguishes it from read/delete page tools. However, it doesn't explicitly say 'knowledge base page' or differentiate from createProject, so it's clear but not fully distinctive.

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

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

No guidance is provided on when to use this tool versus alternatives like getPage, deletePage, or createProject. There is no mention of the upsert behavior (when to create vs. update) or any conditions or prerequisites.

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