Time of Meeting

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: the output always contains a timeofmeeting.com link scoped to a fixed 60-minute meeting, which an agent would not otherwise know.

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 padding. What the tool does comes first, the link caveat and its escape hatch follow immediately.

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 no elaboration, and the description covers the surprising fixed-60-minute behavior plus the alternative for other lengths. It omits timezone/ambiguity handling, but the schema's strict time pattern and city parameters largely cover the call path.

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 parameter docs already explain city names/ids, flexible accents, the array form, and the time format. The description adds nothing beyond 'one or more other cities', 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 and resource ('Convert one city's local time into one or more other cities'), and distinguishes itself from the sibling create_meeting_link by naming it directly. An agent can place this among current_time_in_cities and find_best_meeting_time without opening any schema.

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 routing rule: if you want a meeting length other than 60 minutes, use create_meeting_link. However it offers no guidance on when to prefer this over find_best_meeting_time or current_time_in_cities, which is left implicit.

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 and destructiveHint=false, so safety is covered. The description adds real behavioral detail beyond that: the planner link is always the first returned item, formats are appended in a fixed order, qr is opt-in, and the calendar file is served from https://timeofmeeting.com/c?q=. That is useful disclosure of return composition.

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 opening sentence is well front-loaded, but the middle sentence is a long enumeration of the four formats that duplicates the schema verbatim, and the calendar-file URL sentence is a fragment awkwardly placed mid-paragraph. Several sentences do not earn their place given the 100% schema coverage.

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 the description did not need to narrate return values, yet it does so partially (link ordering) rather than completely. For a five-parameter read-only link builder with full schema coverage, nothing critical to correct invocation 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 description coverage is 100%, so the schema already documents every parameter including formats ordering, defaults, and duration constraints. The description mostly restates these ('duration_minutes... same choices as the planner Duration control', 'title is optional... e.g. Weekly sync'), adding only marginal meaning, which lands at the baseline 3.

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

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

States a specific verb and artifact: 'Build the invitation for one chosen slot,' and immediately scopes it to the planner link plus optional formats. An agent can distinguish it from find_best_meeting_time (which picks the slot) without opening the schema.

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 routes usage: 'Use this after find_best_meeting_time, or when the time is already known,' naming the sibling and the precondition. It stops short of stating when *not* to use it or what to do if the slot is still undecided beyond the implied 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=true and destructiveHint=false (consistent with this read-only description), so the safety bar is low. The description adds real context beyond the annotations by naming the returned fields (local time, offset, work-hour band) and disclosing the embedded https://timeofmeeting.com link, though it says nothing about invalid-city handling or failure modes.

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, core behavior front-loaded in the first sentence and the notable return artifact (the meeting link) placed last where it belongs.

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 re-explained, and the description still usefully previews them. It is nearly complete for a simple read tool, with only minor gaps around edge-case behavior (unknown cities, ambiguous names).

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 there is only one parameter, so the schema already fully documents the array-or-comma-separated input, the 1-8 city limit, and flexible spelling. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 appropriate.

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 ('Show') and resource ('current local time, offset, and work-hour band for each city'), which is immediately distinguishable from siblings like convert_time or find_best_meeting_time. However, it never names an alternative tool or explicitly contrasts its scope with them, so sibling differentiation is left to inference.

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 description (use this to get the present time in one or more cities), but there is no explicit when-to-use/when-not guidance, no mention of the search_cities prerequisite implied by the schema, and no exclusions relative to convert_time or find_best_meeting_time.

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 this a safe, read-only, closed-world operation, so the bar is lower. The description still adds genuine behavioral traits beyond them: ranking ignores meeting length, each slot carries a score and reasons, the result contains a planner link plus a next_step field, and it explicitly excludes calendar files and QR codes. Some of the return-format detail overlaps the output schema, keeping it short of 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?

Purpose is front-loaded in the first sentence, and each subsequent sentence carries usable information. It is slightly scattered—the exclusion sentence ('does not include calendar files or a QR code') and the link description could be tightened—but nothing is wasted.

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 full schema coverage and an output schema present, the description need not re-explain return values, yet it still covers scope, ranking semantics, output highlights, and sibling routing. Complete for correct invocation, with minor redundancy against the output schema as the only blemish.

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 description adds no parameter-level detail (no mention of cities limits or date ranges). Per the rubric, full schema coverage yields a baseline of 3 regardless of description depth.

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 (propose) and resource (up to three fair meeting times) with a clear scope qualifier ('while the slot is still being chosen'). An agent can distinguish it from create_meeting_link, which is explicitly the post-selection step, without opening either schema.

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 both the when-to-use condition ('while the slot is still being chosen') and the explicit alternative with its trigger ('After a slot is chosen, call create_meeting_link'). The routing decision is fully determined by the description.

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 a safe read (readOnlyHint=true, destructiveHint=false), so the description's job is supplementary — and it delivers by disclosing the next-year default and the hard 366-day range cap. It does not describe pagination or result ordering, which keeps it from 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?

The first three sentences are tight and front-load the verb, scope, default, and limit. The trailing sentence 'dst_changes still calls this tool' is cryptic and adds no actionable information, diluting an otherwise efficient block.

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 needn't detail return values, and it correctly focuses on scope, defaults, and the range cap. What remains thin is the absence of any routing guidance among the five sibling time 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?

Schema description coverage is 100%, so the baseline is 3; the description goes beyond the schema by adding a cross-parameter constraint (range at most 366 days) that is not encoded anywhere in the input schema. It also confirms each entry carries a https://timeofmeeting.com link.

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 ('List') plus a concrete resource ('clock changes') scoped to 'one city', which is clearly distinct from the time-conversion and meeting-scheduling siblings. It never names an alternative, so it stops short of the sibling-differentiation that would earn a 5, 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?

There is no when-to-use versus when-not-to-use guidance and no alternative tool is referenced (e.g. convert_time or current_time_in_cities), even though several siblings operate on the same city/time domain. The user must infer the use case purely 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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description's only addition is a listing of returned fields and a link, which largely duplicates the existing output schema; it says nothing about matching behavior, tie-breaking among similar names, or pagination/result 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 sentences, front-loaded with the purpose and with no filler. The second sentence is somewhat redundant against the output schema, which keeps it just short of ideal.

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

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

For a single-parameter lookup with full schema coverage, complete annotations, and an output schema, the description supplies enough for correct invocation. The one missing piece is its role as a prerequisite resolver for the sibling time 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?

Schema description coverage is 100% for the single required parameter, and the schema already documents flexible spelling/accents and acceptance of a raw city id. The description adds no syntax, format, or constraint detail beyond that, so the baseline of 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 and resource ("Find cities by name"), which is unambiguous and clearly distinct from the time-oriented siblings. It does not, however, explicitly position itself relative to those siblings (e.g., as the id-resolver feeding convert_time or current_time_in_cities).

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 when-to-use or when-not-to-use guidance and never references the sibling tools, even though the returned id and time zone are exactly what several siblings require. Any routing logic an agent applies must be inferred entirely from the tool name and output.

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