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

Annotations already declare readOnlyHint/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new behavioral context — that the value is user-set ('as he last set it'), carries its own last-updated timestamp, and is a status note rather than a live calendar. This staleness/freshness framing is exactly the kind of disclosure annotations can't express.

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 zero filler, front-loaded with what the caller receives and finished with the key scope caveat. Every clause (status, date, openness, time zone, not-a-calendar) carries distinct 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?

With no output schema, the description must convey the return shape, and it does so field-by-field. A simple zero-arg read-only tool needs little more; only the absence of sibling context keeps it from a 5.

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 and the baseline of 4 applies.

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

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

States a specific verb+resource — returns the current availability status — and enumerates the contents (status, update date, what he's open to, time zone). The closing line 'A status note, not a booking calendar' sharply warns what it isn't, but it never mentions how it differs from siblings like get_profile or how_to_hire, which is the remaining gap.

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 'not a booking calendar' exclusion tells an agent this is not for scheduling, which is useful negative scope. However, no positive 'use this when…' signal or named alternative (e.g., get_profile for broader bio data) is given.

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

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

Annotations already establish that this is read-only, idempotent, non-destructive, and not open-world, so the safety profile is covered. The description adds useful context by enumerating the fields returned, but it does not describe other behavioral details such as error handling for invalid slugs.

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 with no wasted wording. It front-loads the core purpose and then efficiently lists the returned content.

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

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

For a simple one-parameter read operation with rich annotations and full schema coverage, the description supplies the important missing information: what a full case study includes. No output schema exists, so enumerating the returned fields is especially valuable and sufficient for correct invocation.

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

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

The single slug parameter is fully documented in the schema with an enum of valid values and a note that it comes from list_case_studies. The description itself adds no parameter guidance, so it relies on the schema as expected when schema coverage is high.

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 this retrieves exactly one case study in full, and it enumerates the content included: client type, role, timeline, status, problem, build, results, stack, and links. This distinguishes it from the sibling list_case_studies, which returns the list rather than the full record.

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: use this to get full details for a single case study when the slug is known. The description does not explicitly say when to use this versus list_case_studies or what to do if the slug is unknown, though the schema notes the slug comes from list_case_studies.

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 safety and cacheability are covered. The description adds that this is a single full-dump call covering all profile facets (no filtering or pagination mentioned), which is useful, but it says nothing about response shape, size, or freshness.

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

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

A single sentence, front-loaded with the highest-value items (positioning, summary, roles) and then the long tail. It is a fragment without an explicit verb, and the trailing link list is slightly padded, but every clause maps to real returned content.

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

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

With no output schema and no parameters, the description carries the burden of telling the agent what comes back, and it does so thoroughly across all facets. Only the structure of the returned object (flat fields vs. nested sections) and overall size are left unspecified.

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; baseline 4 applies. The field enumeration helpfully signals what comes back even though no inputs 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 enumerates exactly what the tool returns (positioning, summary, roles, location, availability, languages, education, skills, links), so the resource is unmistakable and it identifies the subject as a personal profile ('what he is open to'). It does not explicitly differentiate from siblings like list_services or how_to_hire, but the enumerated content already makes overlap unlikely.

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 entry point for background/about-the-person information. There is no explicit 'use this when...' or exclusion such as 'for availability use check_availability' or 'for engagement terms use how_to_hire', despite those siblings being the most likely confusion points.

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 structurally. The description adds one genuinely useful clarification — 'This tool sends nothing' — which prevents an agent from treating it as an outreach action, but it says nothing about the return shape (URLs vs. free text) or that the content is static reference material.

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 clauses, front-loaded with the resource list and closing with the key negative guarantee. Every element earns its place; only the missing explicit verb keeps it from being model-tight.

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, no output schema and rich annotations, the description covers everything an agent needs: what content comes back, what each route is for, and that no message is sent. Nothing required for 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?

The tool takes zero parameters and the schema coverage is 100%, so there is nothing for the description to disambiguate. The baseline for a no-parameter tool applies, with no parameter-level gaps introduced.

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 concrete resource being returned — contact routes (site contact page, Upwork, LinkedIn, CV PDF) plus what to include in a first message — which is specific enough to distinguish it from siblings like get_profile or check_availability. What it lacks is an explicit verb ('returns'/'describes'), so the agent has to infer it is an informational lookup rather than an action.

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 enumeration of contact routes signals 'call this when you want to reach the owner', and 'This tool sends nothing' hints at the boundary of the tool. There is no explicit when-to-use/when-not or routing to a sibling (e.g. 'use check_availability to see if he is free before contacting').

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 closed-world scope, so the safety profile is covered. The description adds behavior beyond that: the fixed cardinality (7) and the exact shape of each returned record, which tells the agent it can rely on a small, stable, field-structured payload. Minor gap: no statement about ordering or whether the set can change.

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 waste. The return shape is front-loaded and the routing hint follows, so an agent gets the essential fact first.

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?

There is no output schema, so the description carries the burden of describing return values, and it does so field by field. For a no-parameter, read-only listing tool that is nearly complete; only ordering/stability of the list is unstated, which is low risk.

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, which is the baseline-4 case. The description is consistent with that — it never implies a filter or argument, and the mention of a slug is correctly attributed to the sibling get_case_study rather than to this tool.

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+resource (lists the 7 case studies) and enumerates exactly what each entry contains (slug, title, summary, headline figure, URL). It also names the sibling it is not: get_case_study returns the full write-up, so an agent can distinguish the index from the detail tool immediately.

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 second sentence routes the agent explicitly: use this to enumerate, then pass a slug to get_case_study for the full write-up. That is a clear use/alternative pairing. It stops short of an explicit exclusion (e.g. 'do not use this if you already know the slug'), so it is not 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 readOnly, idempotent, closed-world, non-destructive, so safety is covered. The description still adds useful behavioral context not in the annotations: the result is a static published catalog of 12 projects × 3 tiers plus 3 consultations, priced in USD, and that acquisition happens externally through Upwork rather than through this tool.

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

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

Two tight sentences, front-loaded with the resource and currency, followed by the concrete breakdown of what is offered. No filler or redundancy.

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

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

With no output schema, the description does much of the return-value work by enumerating the catalog composition and pricing currency, which is enough to set expectations. It stops short of describing actual field names or ordering, a minor gap for a static list 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?

Zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly signals a no-argument full-catalog call rather than implying filtering options.

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 the specific resource and its contents precisely: published offers with USD prices, 12 fixed-price projects with 3 tiers each (including delivery days and inclusions), plus 3 paid consultations. This is clearly a catalog/service-listing tool and is distinguishable from siblings like list_case_studies or get_profile.

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 pricing/catalog lookup, and the closing sentence notes purchases happen via his Upwork profile, hinting that this is not a purchase tool. However, it never explicitly says when to call this versus how_to_hire or check_availability, nor any exclusion.

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