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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuinely useful traits beyond them: it is deterministic with no model call (predictable, no LLM cost), it 'Reports only; never edits', and it supports both Korean and English. These are non-obvious behavioral facts worth stating.

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?

Core purpose is front-loaded in the first clause, followed by a tight enumeration and two short constraint sentences. Slightly dense in the middle list, but every sentence carries information 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?

With no output schema, the description must convey the nature of the result, and it does: it reports findings and never edits, and it names the categories it detects. It could say more about the report's shape, but for a single-parameter read-only lint the coverage is adequate.

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 there is a single required 'text' parameter, so the description must carry the semantics. It characterizes the input as a 'creative draft', which clarifies content type, but says nothing about length, format, or constraints. Baseline 3 for compensating only partially on one obvious parameter.

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 (lint/check) and resource (creative draft) and enumerates exactly what it flags: quality/benefit words, buzzword filler, template phrasing, aesthetic tropes, and impersonation of a named person. No sibling tool does linting, so it is clearly differentiated from the retrieval-oriented siblings (get_framework, search, trace, etc.).

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 'no model call' implies when to prefer this over a model-based review (cheap, deterministic pass), which is implicit usage guidance. However there is no explicit when-to-use/when-not statement and no named alternative or workflow context, so the agent must infer the trigger condition.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that the response is the document's full text; it says nothing about behavior for unknown/foreign ids or size limits.

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 sentence, front-loaded with the action and return payload, with examples folded in parenthetically. No wasted clauses.

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

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

With no output schema, the description still tells the agent what comes back (full text of one document), and the annotation set covers the safety semantics for a single-param read tool. Adequate for such a simple signature.

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 lone `id` param is untyped beyond string, so the description carries the burden and does so well by giving the id's source (search results) and three concrete format examples with namespace prefixes. It stops short of a general format rule for other prefixes.

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?

Specific verb (Fetch) plus a precisely scoped resource: the full text of exactly one document, keyed by id. The examples of id prefixes ('principle:P08', 'note:MHJ-EV-00412', 'checklist:launch') distinguish it from the specialized getters (get_principle, get_checklist) that clearly do not take ids.

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?

States the prerequisite workflow explicitly: the id must come from `search`, naming a concrete sibling tool as the entry point. It does not spell out when to prefer a specific getter (get_principle/get_checklist) over fetch, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds that the return is plain text rather than structured data, which is mild context, but says nothing about size, caching, or how the checklist should be applied.

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: purpose first, then the value enumeration. Dense but with no filler. Slightly weakened by the appositive-heavy enumeration that would read better as a structured list.

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 annotations cover the safety profile. The remaining gap is usage routing — for a tool sharing a namespace with get_framework, get_principle, and get_mode, the description gives no basis for choosing between them.

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 there is no enum, so the description carries the full burden of parameter semantics — and it does, enumerating all ten accepted 'kind' values with parenthetical explanations. The text is in quotes so values are usable verbatim; the gap is that 'concept', 'launch', 'conventions', 'taste', and 'limits' are listed without any gloss and it never states the values are exhaustive.

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 ('Return a working checklist as text') and enumerates the kinds available. However, it never distinguishes this from siblings like get_framework, get_principle, or get_mode, leaving the agent to guess which retrieval tool applies.

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 conditions, and no named alternatives. The agent must infer from the kind labels alone that this is the right tool versus get_framework or get_principle. Some glosses ('brief interrogation', 'critique pass') hint at intent but are not routing 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?

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's burden is lower. It adds useful output context by listing what the overview contains, though it does not detail response format or pagination 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?

Two tight sentences with no waste. The content overview is front-loaded, followed by the usage instruction, making the description easy to scan and act on.

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 simple read-only, parameterless nature of the tool and the absence of an output schema, the description is complete enough: it explains what the overview returns and when to call it. No critical behavioral or usage information 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?

The tool takes zero parameters, so there is nothing for the description to clarify. The baseline for a parameterless tool is 4, and the description does not need to compensate for any schema gaps.

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 scope: an overview of the lens, the Frame → Make → Edit → Deliver loop, eight stages, and every principle's id, title, status, and evidence support. This differentiates it from get_principle by covering all principles at once, though it does not explicitly name sibling tools for 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?

It gives a clear usage cue: 'Call first when starting creative work.' This establishes when to use it relative to other tools, but it does not state when not to use it or explicitly name alternatives such as get_principle.

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 annotations already declare this as read-only, idempotent, non-destructive, and not open-world, so the safety profile is covered. The description adds the list of valid modes and the empty-input behavior, but says nothing about return shape or content of a mode guide.

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 very concise and front-loads the tool's topic before listing modes and the empty-value behavior. The long mode list is necessary, and no sentence is wasted, though the opening phrase could be slightly more informative.

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-only lookup with no output schema, the description gives enough to invoke the tool with a valid mode or empty value. However, it does not explain what kind of content a mode guide returns or how this tool relates to sibling retrieval tools, leaving selection ambiguity.

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 carry parameter meaning. It usefully enumerates all valid mode values and explains that an empty value lists all modes, compensating well for the missing schema documentation, though it does not specify case sensitivity or exact matching rules.

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 says 'Working mode guide' and lists possible mode names, but it does not clearly state what the tool retrieves or how a 'guide' differs from sibling tools like get_framework or get_principle. The purpose is inferable but vague and lacks a specific verb+resource framing.

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 get_mode versus the many sibling retrieval tools. The only usage note is 'Empty = list all,' which explains parameter behavior rather than tool 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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds valuable content-shape context: what the returned text contains (rule, limits, guards against, tensions, evidence support, claim IDs). It doesn't discuss behavior like auth, rate limits, or behavior on unknown IDs, but the content disclosure is a genuine addition.

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 front-loaded sentence with a parenthetical example, no waste. The list of returned fields is dense but earns its place by signaling the response's richness. Slightly heavy for a one-liner, but structure is clear.

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 read tool with no output schema, the description tells the agent what it gets back and how to identify the item. Annotations cover the safety profile. The main gap is guidance on how to obtain a valid principle_id, which the agent must infer from siblings.

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% and the single parameter is undocumented in the schema. The description compensates by implying the format ('e.g. P08'), telling the agent what an identifier looks like. It stops short of stating the full accepted format or error behavior for invalid IDs, so not a 5.

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?

Specific verb ('Full text of one principle') plus resource and an example identifier ('P08'). It makes clear this is a single-item retrieval distinct from siblings like get_framework (whole framework), list_tensions, or search_evidence.

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 explicit when-to-use or when-not-to guidance. The example 'P08' hints at the ID format but never states that a principle ID must be known beforehand or that search/framework should be used first to discover IDs. Context is implied at best.

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?

Annotations already declare readOnly=true, idempotent=true, destructive=false, and openWorld=false, covering safety and behavior. The description adds context about the kind of content returned (tensions, contradictions, myths) and the dual filtering modes. No return format, pagination, or error behavior is described, but annotations carry the safety profile.

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: the first states the content type with examples, the second describes parameter usage. Front-loaded with the core purpose and no 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?

Given no output schema and sparse annotations, the description covers what the tool returns (tensions, contradictions, myths) and how to filter. It's nearly complete, missing only minor details like what happens when no parameters are passed (apparently returns all tensions).

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. It explains the effect of principle_id (filter to one principle's tensions) and query (text search), giving semantic meaning beyond the parameter names. It doesn't specify format or default behavior (both default to empty string), but the usage is clear.

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+resource: it lists documented tensions, contradictions, and myths associated with a lens. The examples help clarify the domain. However, it doesn't explicitly differentiate from siblings like get_principle or search_evidence, though the resource is distinct enough.

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 gives clear guidance on how to use parameters: pass a principle id to filter to that principle's tensions, or pass a text query. No explicit when-not-to-use or alternative tool references, but the parameter behavior is well indicated.

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 annotations declaring readOnly, idempotent, non-destructive, and closed-world, the safety profile is fully covered by structured data. The description usefully clarifies output behavior (returns result ids, not content) which is not in the annotations. However, it doesn't mention result limits, ranking, or empty-result 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?

Two short sentences, front-loaded with the core purpose and followed by the key output detail. Every clause earns its place with 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 description covers what is searched and what is returned (ids for fetch), which is sufficient for basic invocation. But it omits the query parameter semantics and any guidance on scope vs. the many similar sibling retrieval tools, leaving the agent with ambiguity about when this tool is the right choice.

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 single 'query' parameter is undocumented in the schema. The description implies a query-based search but adds no syntax, format, or interpretation guidance for the query parameter, leaving a gap that should be filled given the 0% coverage. Baseline 4 for zero params doesn't apply since there is one param.

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 (the always-okay lens, enumerating its content types: principles, evidence notes, tensions, checklists) with clearly stated goal (creative-direction guidance). This makes it distinguishable from siblings like search_evidence. However, the scope overlap with get_principle, list_tensions, and get_checklist isn't addressed.

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?

Implies usage via 'Returns result ids to pass to `fetch`' which hints at a two-stage workflow, but there is no explicit when-to-use guidance or when to choose this over siblings like search_evidence or get_principle. The agent must infer the intended workflow.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still adds real value beyond that: it discloses the result cap ('at most `limit` notes') and explains what the returned records actually contain (paraphrased statements with source and locator).

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

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

Three short sentences, front-loaded with what is being searched, then filters, then intended use, then return behavior. No filler or restated boilerplate.

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

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

With no output schema, the description should sketch the return shape, and it does note that hits are notes with source and locator and that results are capped. Missing only minor details like default limit, ordering, or whether an empty query returns everything.

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 schema has no enums, so the description must carry the burden – and it does: free-text `query`, example domains ('launch', 'brand', 'collaboration'), and the era vocabulary (E0–E8 or 'cross'). Only `limit`'s default of 10 is left to the schema.

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

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

States a specific verb and resource ('search the evidence notes') and even characterizes the resource as 'paraphrased statements with source and locator,' which an agent can't get from the schema. It doesn't explicitly distinguish itself from the sibling `search` tool, but the corpus is named precisely enough to be actionable.

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

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

Gives an explicit intended use ('Use to answer "what is the evidence for…"') and enumerates the filtering dimensions, which is clear context for when to reach for it. It stops short of stating when not to use it or when to prefer the generic `search` sibling.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world). The description adds real behavioral context beyond them: it discloses that the tool resolves downward to evidence notes and public sources, i.e. it performs provenance traversal rather than a flat lookup. It stops short of describing depth, limits, or output shape, so it is not a 5.

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, zero filler. The what-it-does sentence leads and the when-to-use sentence follows, so the purpose is front-loaded.

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

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

For a single-parameter read-only lookup with no output schema, the description supplies the input format and the nature of the returned material (evidence notes, public sources). What is missing is any sense of result granularity or pagination, but nothing essential to correct invocation is absent.

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

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

Schema coverage is 0% and item_id has no description in the schema, so the description carries the full burden. It compensates well by specifying the accepted ID formats (P## for principles, MHJ-CL-### for claims), which is precisely the semantic an agent needs to form a valid argument.

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?

Specific verb ('Trace') plus the exact resources it operates on ('a principle (P##) or claim (MHJ-CL-###)') and their target ('evidence notes and public sources'). This clearly distinguishes it from siblings like get_principle and search_evidence, which retrieve rather than resolve provenance.

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

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

Gives an explicit trigger: 'Use when the user asks why a recommendation holds or where it comes from.' That is a clear use context, but it does not contrast against alternatives such as get_principle or search_evidence, which an agent might otherwise reach for first.

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