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

With no annotations, the description carries the full burden. It discloses the active-bug fallback for path, which is useful, but says nothing about return behavior, whether append is idempotent, error conditions (e.g., invalid section), or whether the entry is validated. For a mutation tool with no annotations, this is thin.

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?

One tight sentence with a parenthetical enumeration of section values. Front-loaded with the action, no filler, every clause adds 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?

An output schema exists, so return values needn't be described. The description covers the optional path behavior and valid sections, but with 0% schema coverage for parameters and no annotations, it leaves gaps around the required 'entry' parameter and operational constraints. Adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate but does so only partially. It clarifies that path is optional (active bug fallback) and lists valid section values, but 'entry' is not described at all – its format, length, or content expectations are entirely absent.

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

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

The description states a specific verb ('Append') and resource ('bug note section') and enumerates the valid sections (Timeline, Hypothesis, Fix, Symptom, Root cause), which is informative. It distinguishes from siblings like bug_start and bug_close, though it doesn't explicitly say it's a bug-note-append tool versus the generic daily_append.

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 implies usage by explaining the 'uses active bug if path omitted' behavior, which tells the agent when path is optional. However, it provides no explicit when-to-use guidance, no mention of prerequisites (e.g., must a bug be active?), and no comparison to alternatives like notes_read or capture_quick.

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 it does disclose the key side effects: it writes Fix and Root cause and mutates status to 'fixed'. It does not cover permissions, reversibility, or what happens when no active bug exists, so the disclosure is partial for a state-changing 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 compact sentences with zero filler; the action and scope are front-loaded and the side effect follows immediately. Every clause 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?

The output schema exists, so return values need not be explained, and the core behavior is stated. For a mutation tool with no annotations, though, more context would help: whether it fails when no active bug is present and how the optional target is resolved.

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

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

Schema description coverage is 0%, so the description must compensate. It names 'Fix' and 'Root cause' (matching the two required params) and hints at the optional target via 'active (or given)', but gives no format, length, or selection semantics for any of the three 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?

States a specific verb ('Close') and resource ('bug note') plus scope ('active (or given)'), which is enough to distinguish it from bug_start and bug_append by verb alone. It stops short of explicitly naming the sibling it complements, so it is clear but not maximally 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?

'After confirmation' implies a workflow precondition (a confirmation step must precede the call), which is useful implied guidance. However, there is no explicit when-to-use vs when-not, nor any statement of what to do if no bug note is active.

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 behavioral burden. It usefully discloses that it creates a note in Inbox and sets an active bug state, which goes beyond schema fields. However, it omits key behavior such as what happens if an active bug already exists, permissions needed, or whether the note is mutable or deletable.

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 compact sentence with no filler, front-loading the action and outcome. Every word contributes to the stated purpose.

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?

Although an output schema exists for return values, the description is incomplete for a mutation tool with no annotations and 0% schema description coverage. It omits parameter meaning and usage context, which are important for correct invocation.

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

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

Schema description coverage is 0% and the description does not explain any of the three parameters. Required fields title and symptom are not described, and the optional domain parameter is entirely unexplained, leaving an agent no semantic guidance beyond the parameter names.

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 (start) and resource (bug-session note), with scope details (in Inbox) and state intention (remember as active bug). It does not explicitly distinguish itself from close siblings like bug_append or bug_close, but the purpose is clear from the wording.

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 saying 'Start a bug-session note,' but gives no explicit when-to-use guidance, no conditions for choosing this over bug_append, bug_close, or other capture tools, and no prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral trait — that summarization depends on client LLM sampling support — which is useful for an agent to know before invoking. It still omits where the note lands, whether an existing note is overwritten, and any permission requirement.

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 short blocks: purpose first, then parameter notes. Front-loaded and free of filler, though the parameter lines are terse enough to read as a fragment rather than a coherent sentence.

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?

Output schema exists, so return-value explanation is rightly omitted, and the enum-like detail for kind is helpful. But for a tool whose siblings are near-duplicates, the missing selection criteria and the undisclosed destination/overwrite behavior leave a real 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 description coverage is 0%, so the description must compensate, and it does: it enumerates the valid kind values (learning | work | quick) and explains topic_or_domain conditionally per kind with examples. The remaining two parameters (title, source_text) are self-evident from their names.

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 concrete two-step verb sequence (summarize via client LLM sampling, then save as a vault note) with clear resource. However it never distinguishes itself from the very similar siblings capture_quick, capture_learning, and capture_work, so an agent cannot tell why it would pick this one.

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

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

No when-to-use guidance at all, and no exclusions. The sibling set is nearly identical in name (capture_quick/capture_learning/capture_work), which is exactly where a routing hint is needed most, yet none is given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the knowledge/* tag convention and topic-to-folder mapping (e.g., 'fastmcp' → 03-Knowledge/FastMCP), but says nothing about permissions, idempotency, overwrite behavior, or error handling for a write operation.

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

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

Two short sentences with no filler, front-loading the core action before the routing detail. Every sentence 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?

An output schema exists, so return values need not be explained. However, against sibling capture_* tools the description lacks when-to-use context, and it only partially compensates for the 0% schema coverage on title and body.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for the topic parameter by explaining its routing effect, but title and body are left undocumented beyond their obvious names.

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

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

The description states a specific verb ('Create') and resource ('learning note'), and describes the tagging and routing behavior. It distinguishes the tool from generic capture siblings by naming the note type, though it does not explicitly contrast with capture_quick, capture_work, or capture_distill.

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 choose this tool over the other capture_* siblings. The phrase 'learning note' implies a context, but no explicit when-to-use or when-not-to-use conditions 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 does not state whether the operation is a write, whether it requires authentication, whether it is append-only or idempotent, or what happens on success. The only behavioral signal is the inferred write nature of 'Create', which is minimal 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 with no waste and the action/resource/destination front-loaded. It is appropriately sized, though its brevity comes at the cost of completeness.

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 three-parameter mutation tool with zero schema description coverage and no annotations, the description is too sparse. A note-capture tool typically requires auth context, persistence behavior, tags semantics, and a reason to prefer it over the other capture_* siblings, none of which are addressed.

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

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

Schema description coverage is 0%, so none of the three parameters (title, body, tags) are documented in the schema. The description adds no parameter-level meaning either. It does not explain the title/body split, note the optional tags/default, or clarify any format expectations.

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 verb (Create) and resource (quick capture note) with a destination (00-Inbox), which distinguishes it from some siblings. However, the sibling set contains capture_learning, capture_work, and capture_distill, and the description offers no criteria for choosing this quick-capture variant over those. The core purpose is understandable but lacks differentiation within a dense capture family.

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 explicit when-to-use guidance, no when-not-to-use, and no mention of alternatives. The presence of capture_learning, capture_work, capture_distill, and daily_append in the sibling set makes routing unclear, and the description does not resolve this ambiguity at all.

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 does add useful context beyond the schema: the note is written to Inbox, tagged #work/<domain>, and is intended for a separate Auto Note Mover process. However, it says nothing about permissions, overwrite/collision behavior, or how the domain is validated, leaving real behavioral 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?

A single efficient sentence with the destination and tag convention front-loaded. It earns its place, though the terse phrasing leaves semantic gaps that a slightly longer description could have filled.

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

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

An output schema exists, so return values need not be explained. Still, for a three-parameter mutation tool with zero annotation coverage and 0% schema description coverage, the description only documents the domain/tag behavior and says nothing about title/body expectations or what happens on write.

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

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

Schema description coverage is 0% and all three parameters (title, body, domain) are required. The description only hints at the shape of domain via the #work/<domain> tag format; title and body are entirely unexplained, so the description only partially compensates for the coverage gap.

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 (Create), resource (work note), destination (Inbox) and a tagging convention (#work/<domain>), which makes it clearly distinguishable from siblings like capture_learning and capture_distill. It stops short of explicitly naming those siblings as alternatives, so it lands at 4 rather than 5.

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

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

The mention of Inbox and the #work/<domain> tag implies usage (capture a work-domain note for later processing by Auto Note Mover), but there is no explicit when-to-use or when-not-to-use guidance versus capture_quick, capture_learning, or capture_distill. Usage is inferable but not stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Append' implies a mutation, but the description does not state whether the daily note is created if it does not exist, whether appends are idempotent or reversible, or what permissions are required.

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

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

A single sentence with no wasted words, and the resource ('today's daily note') is front-loaded ahead of the parenthetical detail. Appropriately sized for a simple append 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?

An output schema exists, so return values need not be described. However, for a mutation tool with no annotations, the description omits note-creation behavior and permission requirements, leaving meaningful gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that the 'section' parameter falls back to 'Notes' when unset, which adds real meaning beyond the schema's bare null default, but it says nothing about the required 'text' parameter's format or constraints.

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

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

The description states a specific verb and resource: append a bullet to today's daily note. It is clearly distinguishable from siblings like bug_append or capture_quick, though it does not name any alternative 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?

There is no when-to-use guidance and no mention of alternatives such as capture_quick or notes_read. Usage is only implied by the phrase 'today's daily note', leaving the agent to infer when this tool is preferred over the several sibling capture 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?

The readOnlyHint annotation already indicates the tool is non-destructive. The description adds valuable context beyond this by explaining the output structure (JSON with resource metadata) and the key distinction between static 'uri' fields and templates with 'uri_template' placeholders. This extra detail about the return format and resource types exceeds what the annotation provides, though the read-only behavior itself is not elaborated further.

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 highly concise, consisting of two short sentences. It front-loads the primary action and object ('List all available resources and resource templates') and then provides necessary detail on return format and resource types without any redundant or vague phrasing. Every sentence adds meaningful 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?

Given the tool's simplicity (no parameters, clear output schema present), the description is sufficiently complete. It explains what the tool returns (JSON metadata) and the critical distinction between static and template resources, which is essential for understanding the tool's behavior. The presence of an output schema means the description does not need to enumerate all return fields, and it covers the key context an agent would need to use the tool correctly.

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

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

The tool has zero parameters, and the schema coverage is 100% (vacuously). There are no parameter semantics to explain, so the description does not need to add any meaning. The description fully aligns with the input schema, and there is no ambiguity or missing parameter information.

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 ('List') and the target ('all available resources and resource templates'). It distinguishes between static resources and templates, making the purpose unambiguous even without opening the schema. This is a precise, specific statement of 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 description does not explicitly state when to use this tool over siblings like read_resource or legal_list_laws. It implies that this is for discovery (listing all resources), but it does not provide direct guidance on selection criteria. The information about static vs. template resources is helpful but does not constitute explicit 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, so the description carries the full burden. 'Read' implies a non-destructive operation, but nothing is said about failure behavior for missing paths, permission requirements, or whether the note is returned raw. An output schema exists, so return-shape disclosure is not required, but operational behavior is sparse.

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

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

A single front-loaded sentence with zero filler. The verb, resource, and scoping constraint all land immediately.

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 one-parameter read tool with an output schema, the description covers the essentials. It omits what 'relative' is relative to and what happens on a bad path, which are the main remaining gaps for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate for the single 'path' parameter. It does add one meaningful detail: the path is relative, which implies resolution against the vault root. It stops short of specifying the base, format, or extension handling.

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 (read) and resource (a markdown note from the vault) with a scoping qualifier ('by relative path'). It is clear enough to act on, but it does not distinguish itself from the sibling read_resource, leaving ambiguity about which reader to pick.

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 notes_read versus list_resources, read_resource, or search_query. The description states what it does but gives no context, prerequisites, or alternatives to route the agent correctly.

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 readOnlyHint annotation is consistent with the described read-only behavior. The description adds useful details about return content and base64 encoding, going beyond the annotation without contradicting it.

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 and well-structured, with no unnecessary words or repetition. It delivers all essential information in two 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?

For a simple read operation, the description is complete: it covers input format, output type, and encoding. No further details are needed for correct usage.

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 single parameter 'uri' is described in the schema, but the tool description adds important nuance about static vs. templated URIs, which is not present in the schema. This additional guidance improves 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?

Clearly states the verb 'Read' and the object 'resource by its URI.' It distinguishes from sibling tools such as list_resources (listing) and legal_* tools (specific legal actions) by focusing on reading a single resource.

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

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

Provides guidance on static vs. templated URIs and explains output encoding. Does not explicitly contrast with alternatives, but the purpose is straightforward and the instructions are sufficient for correct invocation.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the tag may be given with or without a leading '#', but says nothing about read-only nature, result ordering, pagination, or how many results are returned.

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

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

A single front-loaded sentence with no filler; the parenthetical format hint is placed right after the parameter it qualifies. It is efficient, though very terse for a tool with two undocumented parameters.

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

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

An output schema exists, so return values need not be described. The tag format is covered, but the limit parameter, result ordering, and pagination behavior are absent, leaving the definition only minimally adequate for a search tool.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the 'tag' parameter's accepted format (with or without leading '#'), which is genuinely useful, but the 'limit' parameter (default 20) is left completely unexplained.

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 (search) and resource (notes) with the filter criterion (containing a tag), so an agent immediately knows the operation. It does not differentiate itself from the sibling search_query, leaving the tag-vs-general-query distinction to inference.

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

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

There is no when-to-use guidance, no mention of when to prefer this over search_query or notes_read, and no stated prerequisites. The tag filter implies a use case but nothing routes the agent between 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, the description carries the full behavioral burden but discloses almost nothing: no ranking/scoring semantics, no result ordering, no indication of whether it is read-only across the vault or scoped, and no pagination behavior. 'Full-text' hints at matching scope but nothing operational.

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

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

A single front-loaded sentence with zero wasted words and the core action stated immediately. It is efficient, though arguably too terse given the gaps elsewhere.

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

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

An output schema exists, so return values need not be explained, and the tool is a simple 2-parameter read. Still, for a search tool with sibling alternatives and 0% parameter coverage, the description is only minimally viable.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate, but it adds no meaning about the 'query' string (syntax? boolean operators?) or the 'limit' parameter (default 20, but semantics unexplained). It fails to fill the coverage gap.

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 ('Full-text search markdown notes in the vault'), so the agent knows what it retrieves. However, it does not distinguish itself from the sibling search_by_tag, leaving the agent to infer which search to pick.

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

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

No when-to-use guidance, no exclusions, and no mention of the sibling alternatives (search_by_tag, notes_read) that also surface notes. The agent must guess when full-text search is preferable.

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