knowledge

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 conveys the conceptual output (coverage facts, occupations without evidence) but discloses no detail about side effects, return format, or how the optional locale parameter affects results. The description is semantically informative but behaviorally 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?

Two tightly written sentences with zero filler. The core purpose is front-loaded in the first sentence, and the usage trigger is delivered immediately in the second. 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?

For a simple coverage-query tool with one optional parameter and no output schema, the description handles purpose and usage adequately. The main gap is the unexplained locale parameter, which leaves the agent to guess whether locale is required or how it alters the result; no output schema exists to compensate.

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 never mentions the lone 'locale' parameter, so an agent receives no guidance on what locale values are valid or how it shapes the coverage answer. Although the parameter is optional (likely has a default), the description fails to compensate for the undocumented 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?

The description states a clear purpose: it reports what VOLO covers and what it does not, including occupations lacking evidence. The phrase 'a fact about this site rather than a guess about their job' implicitly distinguishes it from sibling data-lookup tools like get_occupation or find_evidence, though it does not name any sibling explicitly.

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

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

Gives explicit when-to-call guidance: 'Call this when someone asks whether their job is covered.' This is actionable and clear. However, it does not state when not to use it or name the alternative tools (e.g., resolve_occupation_or_major, find_evidence) that would be more appropriate for specific occupation lookups.

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 behavioral burden. It implies a read-only query operation but does not disclose any edge cases, required permissions, output behavior, or what happens when a change record has no affected occupations or tasks.

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 short and contains no wasted words, but it is under-specified as a sentence fragment. It lacks the structure needed to convey usage, parameter details, or behavioral context, so 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 tool with two undocumented parameters, no annotations, and no output schema, the description is not complete enough. The sibling list contains several similar find_* tools, and without clearer context or parameter guidance, an agent may struggle to invoke this tool correctly or disambiguate it from alternatives.

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 adds almost no parameter meaning. It does not explicitly state that 'id' is the change record ID, and 'locale' is entirely unexplained despite being a parameter. The tool name and description weakly imply the role of 'id' but not its format or the purpose of 'locale'.

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 the specific purpose: identifying which occupations and tasks are affected by a change record. This distinguishes it from sibling tools like get_change (change record details) and find_evidence (evidence lookup), though it does not explicitly name them.

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 rather than stated: the agent can infer to use this tool when it needs affected occupations/tasks for a change record. However, there is no explicit guidance about when not to use it or how it differs from alternatives like find_evidence or get_change.

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 meaningful work: it enumerates what each record contains (scope, stage, whether the stage can move a judgement, source tier) and gives a specific data-shaping instruction ('Repeat the scope rather than smoothing it away'). This reveals behavior that would otherwise be unknown.

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, front-loaded with the core purpose, and each sentence contributes: the first defines scope, the second defines record contents, and the third gives a distinctive behavioral instruction. The final sentence is slightly cryptic but still purposeful.

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

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

For a read-only lookup with no output schema and no annotations, the description provides a reasonable picture of return contents and filtering scope. It falls short on documenting the locale parameter and on giving any clarity about how slug should be formatted or resolved, leaving some ambiguity 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 0%, so the description must compensate. It maps 'occupation' to the required slug and 'optionally for one task' to taskId, which adds meaning beyond the bare parameter names. However, the locale parameter is not mentioned, and no format or value constraints are given for any 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?

The description identifies the resource ('verified evidence records') and its primary scope ('for an occupation, optionally for one task'), which sets it apart from note- or transition-related siblings like find_notes or find_transition_paths. It lacks an explicit verb like 'list' or 'retrieve', but the noun phrase clearly implies a lookup operation.

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 gives no explicit guidance on when to choose this tool over alternatives, and it does not name any sibling tools or exclusions. The intended usage is only implied by the phrase 'for an occupation, optionally for one task'; there is no 'use when...' or 'not for...' 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the basic purpose and provides no information about return format, ordering, filtering, locale behavior, or any other operational characteristics.

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 text is very concise and front-loaded with the core purpose, with no wasted words. However, it is a fragment rather than a structured explanation and is too sparse to be considered appropriately sized for a tool with two parameters and no annotations.

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 conveys the essential occupation-to-degree mapping but leaves crucial operational details unexplained, especially the 'locale' parameter and the meaning of 'slug'. With no output schema or annotations, this description is not sufficient for fully reliable 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 either the 'slug' or 'locale' parameters. The agent must guess what 'slug' refers to and has no basis for understanding the role of 'locale'.

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: mapping an occupation to the degrees/majors that lead into it. It is specific enough to distinguish itself from most siblings, though it does not explicitly differentiate from similar tools like find_transition_paths.

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 gives no guidance on when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. The intended use case is only weakly implied by the phrase 'which degrees lead into this occupation.'

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 that each result carries the note's own limits, which is useful context. However, it does not state read-only behavior, query/locale semantics, or result format.

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 front-loaded and readable, but the list of example questions and the repeated emphasis on evidence make it longer than strictly necessary. Still, each sentence carries some 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?

Given no annotations, no output schema, and 0% parameter coverage, the description leaves important gaps: parameter semantics, optional-parameter behavior, and return shape. It provides usage guidance and a caveat, but an agent needs more 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 description coverage is 0%, and the description never mentions the query or locale parameters. 'Question' is referenced conceptually, but there is no mapping to the parameter names, types, or expected values, so the description adds no parameter meaning.

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 identifies the resource as VOLO's long-form notes/evidence for big-picture questions and distinguishes these from occupation-specific notes. The verb is indirect ('Call this FIRST' rather than 'search' or 'get'), but the resource and scope are clear.

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 explicitly says to call this first for questions about the whole picture rather than one occupation, and warns that these are questions an agent might otherwise answer without evidence. It implies exclusion of occupation-specific queries, though it does not name sibling 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 behavioral disclosure. It does not explain whether the tool requires any authentication, what the output format is, or whether it is read-only. The phrase 'argue from this occupation's own records' hints at the tool's logic but is not enough to inform an agent about side effects, performance, or error behavior. The description adds some context but leaves significant behavioral aspects undisclosed.

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

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

The description is extremely concise: one sentence that names the tool's function and its intended use case. It is front-loaded with the key purpose, and every word adds value, with no filler or repetition. This is an exemplary concise 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?

Given the tool's simple schema (2 params, no enums, no output schema), the description still lacks important context: it does not define what 'own records or task judgements' means, nor does it reference the sibling tools that might be competitors or complements. It also doesn't explain any return format. For a tool with zero annotations and no output schema, the description should provide more context beyond a single sentence to be considered 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 for the two parameters (slug and locale). The description does not explain that 'slug' is the occupation's identifier or that 'locale' might affect the language of results collecter. However, the parameter names are self-explanatory to some extent. Given the low coverage, the description falls short of fully clarifying the parameters' semantics, but it is not entirely absent—so I grant a 3 as the baseline for minimal compensation.

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 ('find notes for an occupation') and adds a distinctive qualifier ('argue from this occupation's own records or task judgements'), which distinguishes it from the generic 'find_notes' sibling. It is clear enough for an agent to understand the tool's focused scope, though it could be more explicit about the exact nature of the notes.

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: 'Use it to point someone from their own page to the wider answer' gives a clear context. However, it does not explicitly compare with sibling tools like 'find_notes' or 'find_evidence', and there are no exclusions or criteria for when not to use this tool. The guidance is better than nothing but lacks explicit routing.

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 provides some behavioral guidance by instructing that every path must include real constraints (time, pay cut, seniority) and one actionable step. This gives the agent an idea of output expectations. However, it does not disclose other behaviors like whether this is read-only, any side effects, or pagination. It is a partial but useful disclosure.

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 brief (two sentences) and front-loaded with the core idea, but it is cryptic and mixes behavior instructions with the purpose. It is not structured for clarity; the directive 'Never present a path without its constraint' is an instruction to the agent rather than a descriptive statement, making it less concise in 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 tool with 2 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the tool returns, how to interpret 'options,' or what 'slug' and 'locale' are. The behavioral note is the only redeeming part, but it does not cover the basic contract an agent needs to invoke 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?

Schema description coverage is 0%, so the description must compensate for the two parameters (slug, locale). It does not mention either parameter or give any hint about their meaning or format. The description is entirely disconnected from the input schema, leaving the agent to guess what 'slug' and 'locale' refer to.

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 'Options for someone in this occupation' which is vague and does not explicitly state it finds transition paths, despite the tool name. It fails to name the resource or distinguish from sibling tools like find_majors_for_occupation or find_evidence. The purpose is only implied.

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. It does not mention any conditions, exclusions, or compare with sibling tools. The description assumes the agent knows when to call it, which is not the case among 15 find/get 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?

No annotations are provided, so the description carries the burden. It discloses that the record is 'verified' and that the response includes VOLO's reading, what it does not establish, and what a reader can verify. This gives useful behavioral context about the nature of the output. However, it does not disclose any side effects, error behavior, or access requirements, and 'verified' is somewhat ambiguous.

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, compact sentence that front-loads the core action ('One verified change record by id') and then adds the distinctive interpretive value. It is concise and readable, though the phrasing 'with VOLO's reading' is slightly jargon-heavy.

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 get-by-id tool with two parameters and no output schema, the description conveys the core purpose and the unique nature of the response. However, it lacks parameter semantics and any guidance on locale, which is a required context for correct invocation. It is adequate 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?

Schema description coverage is 0%, and the description does not explain the 'id' or 'locale' parameters. The description mentions 'by id' but does not clarify what the id refers to (e.g., change record id vs. occupation id) or how locale affects the response. With zero schema coverage, the description must compensate, and it does not.

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 ('get') and resource ('one verified change record by id'), and adds a distinctive scope: it returns VOLO's reading of the change, including meaning, limitations, and what a reader can verify. This distinguishes it from siblings like get_change_history and find_affected, though it does not explicitly name a sibling.

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: use when you need a single verified change record by id and VOLO's interpretive reading. It does not explicitly state when not to use it or name alternatives like get_change_history or find_affected. The context is clear enough for an agent to infer the primary use case, but exclusions are absent.

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 states the output is a verified timeline, but does not mention whether the call is read-only, any pagination, error conditions, or what constitutes a 'change'. This is insufficient.

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 with no redundancy. It is concise and front-loaded, but its brevity sacrifices necessary detail.

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 definition is critically incomplete: it lacks parameter explanations, output shape, and any usage nuances. Given two parameters with no descriptions and no output schema, an agent would not be able to call this tool reliably.

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 description coverage, and the tool description does not explain the meaning of 'slug' or 'locale'. An agent cannot infer how to set these parameters correctly, making the tool effectively unusable without external knowledge.

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 indicates the tool returns a change timeline for an occupation, ordered oldest first. It is specific enough to distinguish it from a single-change tool like get_change, though it doesn't 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 given on when to use this tool versus its siblings (e.g., get_change, get_occupation). The description doesn't mention prerequisites, context, 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that there is no score and never will be, but it does not describe the returned structure, what 'what transfers' means operationally, pagination, locale effects, or any side effects. This is a meaningful gap for a read tool with zero annotation support.

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

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

Two short sentences with no filler. The 'no score' disclaimer is purposeful and prevents a common misconception. Slightly more explicit structure could improve it, but it is appropriately sized and 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 tool with no annotations, no output schema, and 0% parameter coverage, the description is too sparse to serve as a complete call contract. It gives a useful mental model but leaves required parameters, response shape, and the meaning of 'transfers' unexplained.

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 mention slug or locale at all. It only implies that a degree/major is being looked up, leaving both parameter formats and meaning entirely to inference.

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 names the resource (a degree/major) and what it returns ('the occupations it feeds'), and explicitly disclaims scoring. It distinguishes itself from occupation-centric siblings by focusing on the major, though it uses a noun phrase rather than a clear imperative verb.

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 provides a concrete trigger: answer 'should I switch majors' by pointing at where the major leads and what transfers. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to recognize when get_major is the intended lookup.

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 meaningfully reveals the return composition: full note text, section-by-section, each section tied to verified records. It does not mention locale behavior, missing-note errors, or permissions, but it goes well beyond a bare restatement of the tool name.

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 with no filler. The core behavior is front-loaded, and the usage guidance is a single clear clause. 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 two-parameter retrieval tool with no output schema, the description adequately conveys what the response contains and when to use the tool. The main gaps are undocumented parameter semantics and no statement about error conditions or locale defaults, but these are modest for this tool's complexity.

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

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

Schema description coverage is 0%, and the description does not explain what 'slug' or 'locale' mean or how they affect the result. It implies the note is identified by some single-key parameter, but the agent must infer that slug is the identifier and locale is an optional filter.

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 that the tool retrieves the full text of a single note, organized section by section, with the verified records backing each section. This is a specific verb-resource-scope combination and distinguishes it from sibling tools like find_notes or search.

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 explicitly says to use the tool when quoting or citing rather than summarizing, giving an agent a clear decision rule. It does not name the sibling alternative to use for summaries or state explicit exclusions, so it stops short of a perfect 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?

With no annotations, the description carries the full behavioral burden and adds valuable caveats: task judgments have limits, the impact index is not a probability of job loss, and it always appears with confidence and assessment date. This meaningfully reduces misinterpretation, though it does not describe return shape or side effects.

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

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

Two sentences with no filler, front-loaded with the core purpose. The second sentence earns its place by preventing misuse of the impact index and clarifying what the assessment does not establish.

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 provides strong conceptual context about the assessment's content and caveats, which is important given no output schema or annotations. However, it omits parameter semantics, especially locale, and does not clarify the return structure, leaving an agent unable to confidently construct a correct call from the description alone.

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 never mentions slug or locale. It only implies that the slug identifies the occupation; locale semantics are entirely absent. The description does not compensate for the schema 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?

The opening phrase 'Full task-level assessment of one occupation' clearly identifies the resource and deliverable. It distinguishes get_occupation from the sibling find/search tools by emphasizing a single occupation's full task-level detail, though it does not name a specific alternative.

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 given on when to use this tool versus siblings like get_role_tasks or find_transition_paths. The description implies a use case, but it never states exclusions, prerequisites, or when an alternative would be more appropriate.

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 disclose behavioral traits. It mentions that the unit of assessment is the task, which is a useful clarification, but it omits other important behaviors such as whether the result is a list, pagination, error conditions, or side effects. The description is too sparse to fully inform an agent about the tool's 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 two sentences with no wasted words. The first sentence states the core purpose, and the second adds a relevant behavioral nuance. However, it is too terse given the tool's complexity, but as a standalone text it is concise and 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 tool with no output schema, no annotations, and two undocumented parameters, the description is severely incomplete. It does not explain the parameters, return format, usage context, or how it relates to other occupation-related tools. An agent would struggle to call it correctly without additional information.

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 provides no explanation for the two parameters, 'slug' and 'locale.' The agent must guess what 'slug' refers to or how locale affects results. The description completely fails to compensate for the schema 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?

The description clearly identifies the resource as 'task breakdown for one occupation,' which matches the tool name and implies the return of task data. It distinguishes it from siblings like get_occupation by focusing on tasks rather than job details, though it does not explicitly name a sibling. The unit-of-assessment note adds clarification but does not fully differentiate from all 16 siblings.

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 offers a semantic caution ('unit of assessment is the task, never the job title') but does not specify contexts, prerequisites, or exclusions. With a large sibling set, explicit routing or conditions are absent.

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, and it does convey the main behavior: returning the functions a company is organized into and which occupations sit in each. It stops short of explaining locale handling or response details, but for a simple listing tool the disclosure is reasonably complete.

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 filler: the first states the subject matter and output, the second gives the usage trigger. It is front-loaded and 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?

For a straightforward list tool, the description covers purpose and usage context well. However, with no output schema and no explanation of the optional locale parameter, an agent lacks some information needed to call it optimally, so it is only minimally 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%, and the description does not mention the 'locale' parameter at all. Since the description must compensate for the missing parameter documentation and does not, there is no added semantic meaning for the tool's only 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?

The description clearly identifies the resource: business functions and the occupations that belong to each. The phrase 'rather than themselves' and 'business side' distinguishes this tool from personal/occupation-oriented siblings, giving an agent a precise sense of what it does and when it 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?

It gives an explicit trigger condition: 'Use this when someone describes a company rather than themselves.' This is clear usage context, though it does not name alternative tools or provide explicit when-not-to-use guidance, so it stops 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?

No annotations provided, so description carries the burden. It discloses that matches can be exact or approximate, instructs to state the entity read when approximate, and clarifies that null indicates a gap in VOLO coverage rather than a statement about the job. This is transparent about potential ambiguity and the meaning of null.

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 sentences, each serving a distinct purpose: purpose, usage priority, and return behavior. No redundancy or filler. Front-loaded with the core action.

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

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

Covers the essential aspects for a resolver: what it resolves, when to use it, what it returns (exact/approximate/null), and how to interpret results. No output schema exists, so description compensates by describing the match field. Minor omission: locale parameter is not explained, and the match field structure could be more explicit, but overall sufficient for an agent to call 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 description coverage is 0%, so description must explain parameters. It explains that the query can be a job title, internal name, nickname, or degree name, adding meaning to the query parameter. However, the locale parameter is not mentioned at all, leaving its purpose and format unspecified. Given only two parameters, this is a partial 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 'resolve' and the resource (job title, internal name, nickname, degree name) to canonical VOLO entity. Clearly distinguishes from siblings by instructing to call first when a person names their job, implying it's the entry point for name resolution.

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?

Explicitly instructs 'Call this FIRST whenever a person names their job,' which is a direct when-to-use guideline. Also provides guidance on handling approximate matches and null returns, which informs the agent's follow-up behavior. Does not explicitly mention alternatives, but the 'FIRST' gives a strong priority.

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

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

With no annotations provided, the description carries the full burden. It does disclose one behavioral trait: it returns entries, not judgements, which is useful. However, it does not clarify whether the operation is read-only (implied but not stated), how results are paginated or limited, or any potential side effects. The single behavioral note is insufficient given the lack of 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 exceptionally concise: two short sentences that immediately state the action and a key boundary. There is no redundancy or filler. The most important information is front-loaded, making it easy for an agent to parse quickly.

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 has no annotations, no output schema, and no parameter descriptions, the description is far too minimal. It does not explain what 'entries' entails, how 'verified change records' are defined, how limit and locale affect results, or how this search relates to the sibling getters. An agent would struggle to use it correctly without additional information.

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 zero descriptions for any of the three parameters (limit, query, locale). The description only implies that 'query' is the search keyword via 'by keyword,' but it does not explain the purpose or format of 'limit' or 'locale.' It fails to compensate for the complete lack of parameter documentation in 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?

The description clearly states the tool's purpose: it searches occupations, majors, and verified change records by keyword. It uses a specific verb and resource, and adds a boundary ('Returns entries, not judgements') that distinguishes it from judgment-oriented tools like find_evidence or resolve_occupation_or_major. This is a precise, non-tautological statement.

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 guidance on when to use this tool versus the many sibling tools (get_occupation, get_major, find_evidence, etc.). It does not mention when to prefer this broad search over a specific getter, nor does it state any exclusions or alternative conditions. The usage context is only implied by the search verb.

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