Patrick Vieira

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

The description adds substantial behavioral context beyond the annotations: nothing is reserved until the person opens the confirmation link and signs in with Google within 60 minutes; the confirmation is delivered via a confirm_url rather than email; name/email come from sign-in, not the caller. Annotations only declare openWorld/non-idempotent/non-destructive, so this description is doing real work.

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?

Well front-loaded with the guide-step context first, then mechanics, then cautions. Slightly dense but every sentence adds actionable information (confirm_url behavior, no-retry, next-step tool, privacy URL).

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 absent output schema, the description explains what the tool returns (a confirm_url) and the full lifecycle of the booking. Combined with complete schema coverage and annotations, an agent has everything needed to invoke 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 coverage is 100%, so all three parameters are already documented. The description still adds meaningful semantics: 'type' must come from list_meeting_types, 'start' from get_availability, and the caller must not pass identifying information (which maps to the absence of name/email properties). This adds sourcing and constraint guidance beyond the schema.

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

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

States a specific verb+resource (book a meeting with Patrick Vieira) in the context of the booking workflow and references the sibling get_booking_guide. An agent can distinguish it from cancel_booking, get_booking_status, and request_intro 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?

Explicit when-to-use ('Only use this when the person has asked for this meeting at this time'), sequencing with get_booking_guide before and get_booking_status after, a clear 'Do not retry on error' exclusion, and a usage constraint to not send name/email. This is textbook routing guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description adds genuinely non-obvious behavior: unconfirmed requests are withdrawn immediately, while a booked call is not cancelled directly and instead returns a confirm_url (or emails a link). The 'Do not retry on error' note reinforces the non-idempotent annotation. It does not explain error modes or what happens if the confirm_url is never used, so not a 5.

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

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

Information density is high and there is little fluff, but the paragraph is poorly front-loaded: it opens with a dangling fragment before reaching the actionable details. The two-behavior split (unconfirmed vs. booked) is buried mid-paragraph rather than structured.

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

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

For a one-parameter mutation tool with no output schema, the description covers the key decision points an agent needs: when to call it, the two behavioral outcomes, and the no-retry rule. It even sketches the confirm_url return, though it leaves the exact response shape and failure handling 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?

With a single parameter and 100% schema description coverage, the schema already documents booking_id and its pattern, so the baseline is 3. The description adds only indirect meaning by tying the workflow to book_meeting, which the schema itself already references.

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 verb (cancel) and resource (booking) are unambiguous, and the description distinguishes the two cancellation paths (unconfirmed request vs. booked call) that no sibling tool covers. The opening fragment 'Cancelling, in the booking guide (get_booking_guide).' is grammatically broken and reads as an artifact rather than a clean statement of purpose, keeping it 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?

It gives an explicit usage constraint – 'Only use this when the person has asked to cancel' – plus an operational rule ('Do not retry on error') and points to get_booking_guide for the surrounding flow. It stops short of naming which sibling to consult for status or confirmation (e.g. get_booking_status), so the alternative-routing picture is incomplete.

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, non-destructive, closed-world), and the description adds substantial non-obvious behavior: the available window is weekdays 10:00–17:00 London time, at least 24 hours ahead and at most four weeks out. It also discloses the return format (ISO 8601 with Europe/London offset), which annotations cannot 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?

One dense but well-ordered passage: workflow position first, then what it returns, then the scheduling constraints, then the optional parameters. No sentence is redundant given how much specification it carries.

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 correctly shoulders the burden of describing return values and all business constraints, which it does. It omits what happens when no slots match (empty result) and any cap on the number of times returned, which an agent might reasonably need.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema lacks: from and to are interpreted as 'London days' that narrow the range, tying the date parameters to the same timezone as the returned times. It adds interpretation but no new syntax or edge-case 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?

States a specific resource and scope — 'Free start times for a meeting type, from Patrick's live calendar' — plus its position in the workflow ('Step 2 of the booking guide'). An agent can distinguish it immediately from list_meeting_types (enumerates types) and book_meeting (consumes the slots this returns).

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 'Step 2 of the booking guide' reference gives clear sequencing context and the from/to sentence explains how to narrow the search. It never states an explicit when-not-to-use case or names a sibling alternative if the requested window is empty, 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: 'no sign-in needed' discloses the authentication requirement, which the agent cannot infer from the 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?

Two tight sentences with zero filler. The content scope is stated first and the actionable directive ('Read this first') follows, giving appropriate front-loading.

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 static guide with no output schema, the description conveys enough: it says what the guide contains (step-by-step booking and cancellation instructions) and that no auth is required. Only the shape of the returned content (markdown vs. structured steps) is left unspecified, a minor gap at this 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?

The tool takes zero parameters and the schema is empty with additionalProperties=false, so there is nothing to document; baseline for a parameterless tool is 4. The description correctly does not invent parameter talk.

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 precisely (the booking guide) and enumerates its content: how to book a call with Patrick Vieira and how to cancel one. It implicitly contrasts with the book_meeting and cancel_booking siblings by framing itself as the instructional content about those actions, but it never names them explicitly, so it falls just short of full sibling differentiation.

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?

'Read this first' gives an explicit precedence rule, telling the agent to consult this guide before attempting booking or cancelling. It stops short of naming the concrete alternatives (book_meeting, cancel_booking) or stating when the guide is not needed, so it is clear context without full when/when-not coverage.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new context beyond that: the enumerated set of possible states, the presence of a 'reason', 'next_step', and time/meeting-type fields, and the privacy scoping note 'Never returns the guest's details' — but it omits permission/auth requirements.

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 compact sentences, front-loaded with the workflow anchor before the substantive return-value detail. The state enumeration is dense but load-bearing; little text is wasted, though the opening guide reference could be tightened.

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 carries the return contract itself — it names the possible states, the extra fields (reason, time, meeting type, next_step), and what is deliberately omitted (guest details). Combined with annotations covering safety, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100% and the single parameter carries both a format pattern and a provenance note ('the booking_id book_meeting returned'). The description adds no parameter syntax or format detail beyond the schema, so the baseline 3 for schema-led parameters is correct.

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 ('get the state of a booking by its ID') and enumerates the exact state space (pending_confirmation, confirmed, declined, expired, cancelled). It also positions itself in the workflow as step 6 of get_booking_guide, so it is clearly separable from siblings like book_meeting and cancel_booking.

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?

Anchoring usage to 'Step 6 of the booking guide (get_booking_guide)' tells the agent when this call belongs in the flow. It does not, however, explicitly state when NOT to use it or name an alternative for related needs (e.g. cancel_booking), so it falls short of full when/when-not guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context beyond that — and it does, by disclosing the concrete fields returned despite there being no output schema. It stops short of mentioning auth or rate-limit behavior, but for a public read that is a minor omission.

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 resource and its identity, with the field list tucked into a compact parenthetical. Nothing is redundant or padded.

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 parameterless read tool with full annotation coverage and no output schema, the description supplies exactly what is otherwise missing: the identity of the profile and the shape of the return payload. No gap remains that would cause a misinvocation.

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 with additionalProperties false, so there is nothing for the description to disambiguate — the baseline of 4 applies. The description correctly spends no words on arguments.

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 (get profile) and enumerates the exact payload returned: name, headline, tagline, location, links. The parenthetical disambiguates the entity from the footballer of the same name, which is genuinely useful for an agent resolving the name. Clearly distinguishable from the list_* siblings and request_intro.

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: it is the only profile-fetching tool among list_faq, list_skills, list_work and request_intro, so an agent can infer when to call it. But there is no explicit when-to-use framing, no mention of prerequisites, and no statement about how it relates to request_intro (e.g. call this before requesting an intro).

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 non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context by revealing the return shape (q/a pairs), but says nothing about staleness, caching, or completeness of the FAQ set.

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

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

A single compact sentence that front-loads the resource and then the item shape. Nothing is wasted, though the phrasing 'q' and 'a' is terse enough to border on cryptic.

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, zero-parameter, read-only tool with no output schema, the description is nearly sufficient: annotations carry the safety profile and the sentence discloses the return structure. It could be improved with a note on what topics the FAQ covers, but nothing essential to calling it is missing.

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

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

The tool takes zero parameters, so the baseline is 4 by rule. The description correctly implies no input is required and instead characterizes the output items.

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 (FAQ about Patrick Vieira) and its content shape (question/answer pairs), which clearly separates it from siblings like get_profile or list_skills. It is clear but stops short of an explicit verb or a direct contrast with the other list_* tools.

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

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

There is no when-to-use guidance and no mention of alternatives such as request_intro or get_profile, so the agent must infer that this is a static Q&A lookup. No exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds real value beyond that by disclosing the shape of the returned data (id, title, length, purpose) for a tool with no output schema.

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

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

Two short sentences, front-loaded with the booking-guide position before the field list. Tight and waste-free, with only a minor stylistic awkwardness in the phrasing.

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 list tool with no output schema, the description supplies the one thing structured data cannot: what the returned meeting-type records contain. Annotations handle the safety profile, so the definition is sufficient to invoke correctly.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description is needed to clarify inputs, and none is offered.

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 specific resource (meeting types bookable with Patrick Vieira) and enumerates the returned fields (id, title, length, purpose), which clearly distinguishes it from siblings like get_availability or list_skills. It stops short of a crisp 'list' verb but the intent is unambiguous.

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?

By labeling itself 'Step 1 of the booking guide (get_booking_guide)' it tells the agent exactly where this fits in the booking flow and points at the related sibling. There is no explicit when-not-to-use guidance, so it falls 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that: no note on content shape, refresh behavior, or whether the list is exhaustive.

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?

It is a single short fragment with no wasted words and nothing to front-load past. However, the brevity is under-specification rather than genuine conciseness — there simply isn't enough content to be structured well.

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 no-arg, read-only list tool with annotations covering the safety profile, the minimum contract is met. It still leaves open what a 'skill' entry contains and how this differs from get_profile/list_work, which the description could cheaply clarify.

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 schema fully specifies the (empty) input contract. Baseline 4 applies since there are no parameter semantics for the description to compensate for.

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 restates the tool name almost verbatim: 'list_skills' becomes 'listed skills'. It identifies the owner (Patrick Vieira) which filenames-to-resource mapping helps slightly, but it adds no verb, scope, or distinction from the sibling list_work, which a reasonable agent would confuse with this one.

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

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

There is no when-to-use guidance and no mention of alternatives. With siblings get_profile and list_work present, an agent has to guess whether skills belong in get_profile or overlap with list_work.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that and the field list — it does not mention ordering, pagination, or how many items are returned, so it contributes no behavioral context of its own.

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 short sentence with no filler, and the most useful information (the returned fields) is front-loaded. It is efficient, though slightly too terse to be maximally informative.

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

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

With no output schema, the description does at least enumerate the returned fields (title, summary, tags), which is the key missing structured information. However, it omits result scope (all items vs. a fixed subset) and any guidance on how the data relates to sibling list 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 zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool is 4. The description does not need to compensate for any schema gaps here.

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 (work items) and the payload fields (title, summary, tags), but 'Selected work' is a vague noun phrase without a verb and gives no sense of what 'selected' means or how it differs from siblings like list_skills or list_faq. An agent can guess it returns a list, but the scope is not sharpened against 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?

There is no indication of when to call this versus get_profile, list_skills, list_faq, or request_intro. No prerequisites, no exclusions, no context is offered, so the agent must infer usage entirely from the name.

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?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing the strict rate limit (a couple per sender per day), the no-retry rule, and the privacy model: the message is forwarded to Patrick's email, not stored, and rate-limit counters are hashed with daily expiry. This is the behavioral detail an agent cannot infer from structured fields.

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?

Four tight sentences, each front-loading a distinct concern: action, authorization precondition, rate-limit/retry behavior, and privacy. No filler or repetition of the schema.

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 non-idempotent outbound-send tool, the definition covers authorization, rate limits, retry policy, and data handling. With no output schema, return values are not needed, and nothing an agent needs to decide or invoke correctly is missing.

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

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

Schema coverage is high (83%), so the schema already documents the required fields and the reason enum. The description adds no field-level syntax or format guidance beyond the schema, so the baseline 3 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 (send), resource (a short introduction by email), and recipient, on behalf of a person. It is trivially distinguishable from the read-only siblings (get_profile, list_faq, list_skills, list_work) which cannot send anything.

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

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

Gives an explicit precondition: only use when the person asked you to contact him and has approved the message. It also states an explicit anti-behavior, 'Do not retry on error,' which is exactly the kind of when-not guidance an autonomous agent needs.

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