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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered; the description adds real behavioral context beyond them by specifying sort order and that intra-company promotions and education are folded into the result. It stops short of noting gaps or how companies with no promotions appear.

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 resource and scope, with the parenthetical example doing concrete work rather than padding. Nothing is wasted and nothing essential is buried.

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 zero parameters, full annotation coverage, and an output schema that carries the return shape, the description is nearly sufficient. The only residual gap is its relationship to the experience/education siblings, which an agent would have to work out from names 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly avoids inventing filter options that the empty schema does not support.

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 resource — every title Kyle has held — with a defined ordering (most recent first) and an explicit inclusion rule (promotions within a company, plus education). That is far more informative than a name restatement, though it never names a sibling to distinguish itself from get_experience or list_experience.

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 only implied: the phrase 'every title ... including promotions ... and education' signals this is an aggregated career view rather than a single-role lookup, which nudges an agent away from get_experience. But there is no explicit when-to-use statement or named alternative, so the agent must infer the 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful detail that a vCard link is included, but says nothing about authentication, whether the contact data can be absent, or pagination/link expiry, and output schema exists to cover return shape.

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 short fragment with zero padding, and the enumerated profile types are front-loaded. It is telegraphic rather than a full sentence, but every element carries information.

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

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

For a zero-parameter read-only tool with annotations and a full output schema, most of the burden is lifted, so the missing verb and missing sibling routing are the only real gaps. Still, without any statement of when to call this versus get_profile, the definition is only minimally sufficient.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description cannot add parameter meaning that does not exist.

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 is a noun phrase that lists the returned content (contact details, LinkedIn, GitHub, Keyoxide profiles, vCard link) but never states a verb or explicitly says it retrieves the owner's contact information. It hints at a distinction from siblings like get_profile, but with a dozen sibling 'get_*' tools, the agent must infer that this is the contact-info endpoint rather than a general profile endpoint.

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 prerequisites, and no reference to any alternative tool. The closest sibling, get_profile, is never contrasted, so the agent has no rule for choosing between them.

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, and closed-world scope, and an output schema describes the return shape, so the bar is lower. Still, the description adds nothing beyond them — nothing about what is returned when no education data exists, ordering, or completeness of the record.

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 words with zero padding, so there is no waste to trim. However, its brevity is under-specification rather than economy — nothing is front-loaded because nothing is stated beyond a fragment.

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

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

The tool is trivially simple (no parameters, output schema present), so the missing return documentation is not a real gap. What is missing is sibling differentiation — an agent cannot tell from this description why it would call get_education rather than get_career_timeline or get_profile.

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 the baseline of 4 applies; there is nothing for the description to clarify about inputs. The empty schema is self-explanatory.

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?

"Degrees and schools" is a noun fragment that largely restates what the name get_education already implies; there is no verb and no scope statement. It offers only marginal specificity (education = degrees + schools) and does nothing to separate it from siblings like get_profile or get_career_timeline, which plausibly overlap.

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 condition that selects this tool over get_profile, get_career_timeline, or get_experience, and no stated prerequisites. The agent must infer everything from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered without the description's help. The description does add one non-obvious behavior: lookup is a case-insensitive partial match on company or position name, not just an exact id. It says nothing about what happens on ambiguous or zero matches, though the output schema covers the return shape.

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 lead sentence is front-loaded and contains no filler, and the parameter block is short and example-driven. The raw 'Args:' formatting is slightly schema-like, but it does not bloat the description.

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 single required parameter is described in detail. What is missing is fail-mode behavior for ambiguous or missing matches, which matters for a fuzzy name lookup. Otherwise the definition is sufficient 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 carries the full burden and mostly succeeds: it defines the value as an id from list_experience, gives concrete examples ('0', 'Tenna', 'HP', 'Director'), and specifies case-insensitive partial matching against company or position. The only gap is whether a partial match spanning multiple roles is an error or a multi-result return, which the 'one or more roles' phrasing only hints at.

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: 'Full details for one or more roles: highlights, accomplishments, and tech stack.' The 'full details' phrasing implicitly distinguishes it from the sibling list_experience, and the parameter note naming list_experience reinforces that pairing. It stops just short of explicitly contrasting the two, so a 4 rather than a 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?

Usage is clear from the parameter guidance: an id comes from list_experience, so the agent knows to enumerate first and then drill down. It also shows that a name fragment is acceptable as an alternative lookup path. There are no explicit when-not conditions or statements about ambiguity, which keeps it from 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is fully covered. The description adds only the content scope (interests, hobbies, tech news feeds) and says nothing about completeness, freshness, or whether the data is user-curated — a modest but real 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?

A single short phrase with no filler, and the scope is front-loaded. It is a fragment rather than a sentence with a verb, which slightly undercuts clarity but wastes nothing.

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 an output schema present and zero arguments, the description needn't explain return values or parameters, and it doesn't. What remains missing is any disambiguation from the many sibling getters in this family, which is the one substantive gap for a simple read 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter information is missing or contradictory.

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 a concrete resource set — personal interests, hobbies, and tech news sites Kyle reads — so an agent knows what content comes back. It does not, however, differentiate itself from near-neighbours like get_skills or list_side_projects, which could plausibly overlap with 'interests and hobbies'.

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 not to use it, and no pointer to an alternative sibling. The agent must infer that this is the tool for hobbies/interests purely from the noun phrase.

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=true, idempotentHint=true, and openWorldHint=false, so the safety profile is fully covered. The description adds the returned field set, which is mildly useful context but largely duplicates the output schema; it discloses nothing about scope limits, auth, or data freshness beyond that.

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 the most important noun ('Overview') first and a compact field list; nothing is wasted and no padding is present.

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 parameters and an existing output schema, the description only needs to identify the tool and its scope, which it does. The one thing an agent might still want is an explicit pointer to the sibling tools for deeper fields, which is not provided.

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 no parameter semantics to explain and the baseline is 4. The description correctly does not invent parameter behavior.

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 resource (the profile of Kyle Romero) and enumerates exactly what the overview contains: title, summary, location, current role, total experience. That is clearly distinguishable from field-specific siblings like get_skills or get_education, though it never explicitly says 'use this for the overview, those for details.'

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 word 'Overview' implies this is the entry-point/aggregate call versus the granular siblings (get_contact, list_experience, get_skills), but the description never states when to prefer it or when to drill into a sibling. Usage is inferable but not articulated.

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, and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that by explaining that results are merged across roles and include where and how recently each skill was used, but it stops short of describing any limits or grouping 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 front-loaded with the core purpose in the first clause and the parameter detail is separated into an Args block, with no redundant sentences. The docstring-style formatting is slightly mechanical but does not cost clarity.

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 an output schema present, the description need not explain return structure, and annotations cover safety and idempotency. For a single-optional-parameter read tool, the remaining need is parameter meaning, which is well handled; only the when-to-use dimension is genuinely absent.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does: the filter is optional, case-insensitive, substring-based, with concrete examples ('aws', 'react', 'agile') and an explicit statement of what fields it matches (skill names, sub-components, category names). Only the behavior for empty or no-match results is unstated.

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 (Kyle's skills) and describes the two distinct views it returns: by category and as job technologies merged across roles. It is clearly distinguishable from siblings like get_profile, list_experience, or get_education, though the verb is only implied rather than stated as 'retrieves'.

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 such as search or get_career_timeline, and no prerequisites or exclusions are stated. The only usage-adjacent content is the filter examples, which describe 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?

The annotations already declare readOnlyHint, idempotentHint and a closed-world scope, so the safety profile is covered. The description adds the data source (a travel globe on a personal site), which usefully implies the result is a curated public list rather than exhaustive travel records. It does not mention ordering, coverage, or 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?

Two short elements with no filler; the purpose sentence is front-loaded and the argument note follows. The 'Args:' formatting is a stylistic artifact but does not obscure anything.

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 an output schema present and a single optional boolean parameter, the description needs only to convey what the tool returns and what the flag does, and it does both. The main residual gap is that the distinction between lifed and traveled results when the flag is omitted is only implied.

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 carries the full burden and does explain that lived_only restricts results to lived places. However, it omits the boolean type and the default of false, so an agent must open the schema to learn that omitting it returns traveled places as well.

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 resource (places Kyle has lived and traveled to) with a concrete provenance note (the travel globe on kgromero.com), so an agent can tell it apart from siblings like get_profile or get_interests. It lacks an explicit verb such as 'list' or 'return', which keeps it just short of a 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?

There is no statement of when to call this versus the many sibling read tools or when not to call it. The only usage signal is the lived_only filter, which is about invocation 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 already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is covered. The description adds useful behavioural context by explaining that results are grouped by employer/school and that group matching is a case-insensitive substring rather than an exact key. It does not say what form the downloadable items take (paths, URLs, counts) or what an empty group filter returns, so it goes beyond annotations but only modestly.

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: a front-loaded inventory of what is listed, then a compact Args section for the single optional parameter. Every sentence carries information and nothing is padded, though the prose inventory of document types is slightly listy relative to a one-parameter tool.

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

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

With one optional parameter, an output schema present, and annotations covering safety, the description supplies what is missing: the content domain, the grouping semantics, and the filter matching rule. Return-value shape is rightly left to the output schema; only minor details (filter with no matches, ordering) are absent.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so well: it names concrete example group values ('Resume', 'MEARS', 'HP', 'Texas Tech', 'Other') and specifies case-insensitive substring matching, which the schema does not convey at all. It stops short of saying whether the filter is exact-group or matches any containing group name beyond the substring note.

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 a concrete resource set: downloadable resume formats plus portfolio artefacts (architecture diagrams, process docs, write-ups, certificates, lab reports) grouped by employer/school. That is far more specific than the bare name 'list_documents' and separates it from resume/profile siblings like get_experience or list_side_projects, though it never explicitly contrasts itself with the 'search' 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?

Usage is only implied: an agent can infer this is the browse-everything-documents tool while 'search' is the query-based one. There is no explicit when-to-use/when-not-to-use statement, no note that group filtering is a narrowing rather than a query, and no guidance on choosing this over 'search'.

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, and openWorldHint=false, so the safety profile is covered. The description adds behavior beyond that: the results are sorted most-recent-first and each entry exposes an id, which is what an agent needs to plan the follow-up call.

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, both earning their place. Ordering is stated first and the id/follow-up detail second, so the most useful information is front-loaded with zero 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?

For a zero-parameter, read-only list with an output schema that documents return values, the description covers purpose, ordering, and follow-up usage. Only minor gaps remain, such as whether an empty timeline is possible, which the output schema can reasonably carry.

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?

There are no parameters, so the baseline is 4; the description correctly implies an unfiltered full listing rather than hinting at hidden filtering options. Nothing in it misleads about inputs.

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 ('career timeline') and its ordering ('most recent first'), which makes clear this is a listing tool. It also implicitly distinguishes itself from get_experience by noting entries carry ids 'for use with get_experience', though the verb itself is only conveyed by the tool name.

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 chaining guidance: call this to get the timeline, then use the per-entry id with get_experience for detail. That effectively routes the agent between two siblings. It stops short of a full when-not statement, but for a zero-parameter list tool the context is unambiguous.

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, and openWorldHint=false, so the safety profile is covered. The description adds only that each entry carries language, description, and a GitHub link, which is modest additional context rather than behavioral disclosure (no ordering, pagination, or empty-state 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?

A single short fragment with no wasted words, but it is under-specified rather than efficiently structured — there is no leading verb or scoping clause to anchor the reader, so brevity comes at the cost of clarity.

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 zero-parameter, read-only listing tool with full annotations and an output schema, the description covers what is needed to select and invoke it. It only lacks a statement of purpose and any routing hint against the many sibling list/get tools.

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

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

The tool takes no parameters, so the schema imposes no semantic burden and the baseline is 4. The listed fields are return-value information rather than parameter meaning, and the output schema already documents the response shape.

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 is a noun phrase that names the resource ('personal side projects') and the fields surfaced (language, description, GitHub link), which partially distinguishes it from siblings like list_experience. However, it never states the action (listing/retrieving), leaving the agent to infer the verb from the tool name alone.

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 call this versus alternatives such as list_experience or get_profile, and no indication of prerequisites or exclusions. The agent must infer that 'side projects' is distinct from professional experience purely from the wording.

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 (readOnly, idempotent, closed-world), so the description's job is matching behavior — and it delivers: every word in the query must appear (AND semantics), case-insensitive matching. That is materially useful context an agent cannot infer from the annotations. It stops short of explaining ranking, result caps, or what a match looks like.

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 plus examples, front-loaded with scope before matching rules. The parenthetical content list is long but every item earns its place by telling the agent what corpus is searched.

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 an output schema present, return values need no explanation, and annotations cover safety; what remains is scope and query semantics, both supplied. Slightly short of complete because result ordering, limits, and how many matches to expect are unaddressed.

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 `query` parameter has 0% schema description coverage, so the description must carry the meaning — and it does, specifying that it accepts a keyword or phrase, giving concrete examples, and defining the AND/case-insensitive matching rule. The only gap is that quoting/negation/phrase-grouping syntax is left unstated.

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

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

Description gives a specific verb (search) and an explicit scope: the union of every content section on the site (resume, skills, projects, documents, timeline, interests, travel). That enumeration makes it clear this is the cross-cutting tool rather than any of the granular siblings, though it never names those siblings explicitly.

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

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

Usage is implied by the scope statement — reach for this when you want a keyword hit anywhere rather than a specific section — but there is no explicit when-to-use/when-not-to-use guidance and no routing to alternatives like get_skills or list_documents.

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