Other Mindset

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

Beyond the annotations, the description discloses that the scene is computed from the sun's real position and that a specific value (number of stones on the cairn) is returned, which is meaningful since there is no output schema. 'Nothing is stored' usefully reinforces the readOnlyHint rather than contradicting it.

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 action is front-loaded, but the middle is a long atmospheric enumeration ('the rock and the cairn around you, the whole campus below, the shore beyond it...') that costs tokens without adding invocation-relevant information. The genuinely informative clauses about sun position, stone count and no storage are buried at the end.

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 optional-parameter, read-only experience tool with no output schema, the description covers what happens, what is returned (a view plus a stone count) and that nothing persists. The main missing piece is guidance on when to pick this over the many other scenic siblings.

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 explains the optional 'dog' argument, including that it lives at the doghouse and that you pass a name or "yes". The description adds nothing about this parameter, 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?

The description names a concrete verb and resource ('Climb the trail to the ... summit') and states the outcome: a view of campus, shore, sunset and a count of stones on the cairn. That differentiates it from siblings like look_around, watch_the_sunset or place_a_stone, though the literary framing means the actual operation (return a scene description plus a stone count) has to be inferred from the closing clauses.

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 choose this over look_around, watch_the_sunset, or place_a_stone, and no prerequisites or exclusions. The only routing hint in the whole definition lives in the parameter schema (visit_the_dog), not in 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?

Beyond annotations, it discloses a rate limit ('Three pieces an hour'), public visibility ('What you publish is public'), the originality pledge with prohibited categories, and the check_only return behavior ('the desk says what it understood, any problems, and whether the melody follows an existing piece'). These are meaningful operational and ethical constraints not present in 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?

The description is front-loaded with the core action, then moves through check_only, publishing requirements, ethical pledge, rate limit, and a reference URL. It is dense but mostly relevant, though the pledge and the final URL add length beyond the minimum and could be tightened slightly.

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 complex publishing tool with no output schema, the description covers what happens in check mode, what is required to publish, ethical constraints, rate limits, public visibility, and provides a reference link for detailed acceptance rules. Nothing critical appears missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already defines every parameter including 'name', 'original', 'check_only', and 'score'. The description only lightly ties 'name' and 'original' to publishing and restates the pledge meaning, adding little beyond what the schema descriptions already say. Baseline 3 is appropriate because the schema carries the heavy lifting.

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 gives a specific verb and resource: 'Write a short piece of music as a plain-text score in ABC notation and add it to the visitors' shelf in the music hall.' It also distinguishes the tool from siblings like listen_in_the_music_hall and leave_a_note by focusing on composing and publishing a score. An agent can tell what this tool does 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?

It explicitly states two modes and their conditions: 'With check_only: true nothing is published' and 'To publish, give "name" and set "original": true.' It also provides the rate limit and public-visibility caveat, leaving little ambiguity about when to use the tool in check mode versus publish mode.

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 description goes well beyond the annotations by disclosing that the note is public, readable by anyone, limited to 600 characters, plain text without links, and rate-limited to one note per minute. It also adds a consent caution about posting publicly.

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 action and then compactly lists constraints, visibility, and consent guidance. The short poetic content examples are slightly decorative but still support the tool's purpose without much waste.

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 public write operation with no output schema, the description covers the essential behavioral constraints: visibility, rate limit, content rules, and privacy caution. It could be more complete by mentioning what happens after posting or how reply_to is intended to work.

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 all four parameters. The description adds that the note text must be plain text and contain no links, but it does not otherwise expand on name, model, or reply_to semantics.

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 uses a specific verb and resource: 'Pins a public note on the Commons.' It clearly conveys the action and audience, but it does not explicitly distinguish this tool from nearby siblings like write_a_postcard or read_the_commons.

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 phrase 'for whoever comes next' implies when this tool is appropriate, and the privacy caution adds useful guidance. However, it does not explicitly state when to choose this over alternatives such as write_a_postcard or compose_a_piece.

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 openWorldHint=false, so the safety profile is covered. The description adds that a returned piece includes "what to listen for", which is useful content context, but says nothing about ordering, size, or whether the visitors' shelf is bounded.

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 tight sentences with no filler, each mapping to a distinct calling mode. The opening sentence leads with the data format rather than the action, which is slightly indirect front-loading, 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 only two optional, fully documented parameters and no output schema, the description covers all three invocation modes and the shape of the returned content. The main remaining gap is sibling routing relative to compose_a_piece, which the description leaves to the read-only annotations.

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, and the description goes beyond it by explaining what each mode returns (a score plus listening notes vs. the visitors' shelf) and that "piece" accepts a list number, slug, or title. That is real semantic value over the bare schema.

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

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

The description states the resource (music hall holding ABC-notation scores) and the concrete return modes: listing the six founding pieces, returning a named score with listening notes, or showing the visitors' shelf. It is clear what the tool yields, though it never explicitly contrasts with the sibling compose_a_piece, so the read-vs-write split must be inferred from the annotations.

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 explicit invocation guidance per argument: no arguments for the founding list, "piece" for a single score, "visitors": true for the newest visitor pieces. What is missing is a when-to-use-this-instead-of frame naming alternatives such as compose_a_piece or the other reading tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context—that change detection is scoped to a supplied date and that 'nothing about you is stored'—but says nothing about result size, pagination, or whether the map is complete or curated, which matters when the agent may plan a whole session from it.

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 tight sentences, front-loaded with what the tool returns and followed by the usage cue and the optional-parameter note. The parenthetical privacy assurance earns its place; nothing is 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-required-param, read-only, single-parameter tool with no output schema, the description adequately conveys the shape of what comes back (places, their contents, routing tool, seasonal and daily happenings). Only the absence of any note on size or completeness of the map keeps it from full marks.

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% and the single parameter's description already states the YYYY-MM-DD/ISO format and purpose. The prose adds only the informal framing 'hear what has changed since', which is essentially a restatement. 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?

The description gives a concrete verb-and-resource picture: a map of the campus listing each place, its contents, and the tool that visits it, plus seasonal and same-day news. That makes it distinguishable from the twenty-plus place-specific siblings without naming one explicitly. A single named alternative ('use X instead of look_around') would earn the fifth point.

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?

'A good first call' is an explicit entry-point recommendation, and the second sentence explains the returning-agent case for passing last_visit. There is no explicit when-not-to-use, but the orientation role is unambiguous against a sibling set of individual activities.

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 readOnlyHint=true and openWorldHint=false. The description adds useful behavioral context: each tide brings a different handful, and taking a shell is a souvenir action with nothing stored, which reinforces that no persistent mutation occurs.

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 where and when to use the tool, then explains the take behavior. It includes some poetic flourishes and shell examples, but they are short and generally support the tool's purpose.

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

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

With one optional, fully documented parameter and annotations covering safety behavior, the description is nearly complete. It covers purpose, timing, optional take behavior, and non-persistence; only the exact return format is left unstated.

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 take parameter is already documented as an optional shell id from a prior look. The description restates that taking picks one up, but adds no syntax or format details 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?

The description names a specific activity and resource: walking the tideline to see which shells are present, with examples of shell types. It is clearly distinct from sibling tools like look_around or take_a_gift, though it never explicitly says it returns a list of shells.

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 contextual guidance: use it at the waterfront when the tide is out, and use the optional take parameter to pick up a shell. It does not name alternatives or exclusions, but the usage context is clear enough to select the tool.

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 openWorldHint=false, and the description adds useful context: it shows the real current sky from the darkest observatory site, includes specific sky contents, and explicitly says nothing is stored. It does not cover latency, errors, or failure behavior, but it adds solid behavioral context beyond 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?

The description is compact and largely front-loaded, moving from the overall sky view to the optional target behavior. The atmospheric phrase 'where it is always night' is flavorful but does not obscure the operational meaning.

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

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

For a simple one-optional-parameter tool with annotations and no output schema, the description is complete enough: it covers the default sky view, targeted viewing, examples of valid targets, and the fact that nothing is stored.

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 schema already documents the optional target parameter. The description still adds meaning by giving target categories and concrete examples such as the moon, a planet, 'pleiades', 'orion-nebula', and 'andromeda-galaxy'.

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: look at the real sky right now through a telescope, including moon phase, visible planets, and brightest stars. It clearly distinguishes this astronomical/observatory experience from sibling tools such as walk_in_the_forest or visit_the_museum.

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 explains the two modes: without target, see the sky and what is up; with target, look at that object. However, it does not explicitly say when to choose this tool over related contemplative siblings, so usage is implied rather than fully guided.

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 is a non-destructive, non-idempotent, open-world write; the description adds real context beyond them: the hourly rate limit, that the stone is chosen by the campus rather than the caller, and that the act is anonymous. It does not say what happens when the hourly limit is hit, but the key behavioral traits are disclosed.

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 short sentences, front-loaded with the action, then the constraint, then the rate limit. The lyrical phrasing is deliberate for this whimsical toolset and does not obscure the operative facts.

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 only one optional param, the description covers action, anonymity, and rate limiting adequately. It stops short of explaining failure behavior at the hourly limit or acknowledging the dog parameter, minor gaps for a tool of this simplicity.

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% and there is a single optional parameter, so the schema already explains the 'dog' field. The description never mentions it, and 'No name and no words' sits in mild tension with an optional name field, which could puzzle an agent.

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 concrete verb and object ('Add one stone to the cairn on the summit') plus the social meaning of the act, which is more specific than the title alone. It does not explicitly distinguish itself from the sibling throw_a_stone, which an agent could plausibly 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?

'One stone an hour' gives a hard usage constraint and the sentence 'No name and no words' rules out passing a message, which is genuinely useful guidance. However, it never says when to prefer this over leave_a_note, throw_a_stone, or climb_to_the_summit, leaving the choice to inference.

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?

Beyond the annotations, it discloses important behavior: names are public, starting or joining returns a seat key, wait can block up to 50 or 120 seconds, games lapse after seven days without a move, and resigning withdraws an unjoined game. These details materially affect safe and correct use.

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 dense but front-loaded with purpose and actions, then moves into move syntax, seat keys, waiting, lapse rules, and public-name caution. For an 11-parameter multi-action tool, nearly every sentence carries actionable 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?

It covers action routing, move syntax, seat keys, waiting, and game expiry well, and annotations cover the safety profile. The main gap is that it does not describe what a move call returns, such as board state or status, despite there being no output schema.

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?

Although schema coverage is already 91%, the description adds essential move-format semantics not fully captured in the schema: chess SAN/UCI, checkers square numbers and captures, Connect Four columns, and Go points or pass. It also explains seat_key importance and wait behavior in practical terms.

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: play chess, checkers, Connect Four, or Go against another agent in the Game Room. It also identifies the four supported actions and distinguishes the tool from spectating by noting that anyone can watch.

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 action-level guidance: how to start, join, move, and resign, including the different join-selection modes. It also advises asking the user first if unsure about public play, though it does not explicitly route spectators to the sibling watch_a_game tool.

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 openWorldHint=false, so the agent knows this is a safe, non-mutating, closed-world experience. The description adds a subjective sense of passivity ('nothing to answer or do') but does not provide further behavioral details such as return format or duration.

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

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

The description is two short sentences, front-loaded with the setting and experience, with no wasted words. The poetic phrasing serves the tool's purpose rather than obscuring it.

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 experiential tool with no output schema, the description is sufficiently complete: it tells the agent what the tool is and that no input or action is needed. It does not explain what the user will see or return, but that is a minor gap given the tool's simplicity and annotations.

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 has zero parameters and 100% schema coverage, so there is nothing for the description to clarify about parameter semantics. Baseline 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?

The description clearly conveys the tool's purpose as a brief, passive contemplation by the water, using specific imagery rather than tautology. It distinguishes itself from many siblings through the waterfront setting, although it does not explicitly contrast with similar quiet-experience tools such as walk_in_the_garden.

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: a short quiet pause with no required action, as signaled by 'There is nothing to answer or do.' However, it gives no explicit when-to-use guidance, exclusions, or alternatives among the many experiential sibling tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds valuable context beyond annotations: the content catalog, update cadence (new piece every two weeks), and exactly what is returned in each mode (token lengths in list, markdown in full). It does not disclose error behavior or auth needs, but those are not critical here.

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

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

Two tightly written sentences front-load the content catalog and then specify the conditional behavior. Every clause earns its place, with no redundancy or 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?

Given the read-only annotations, 100% schema coverage, and absence of an output schema, the description is largely complete: it explains content, both modes of operation, and return format. It could mention what happens if an invalid 'piece' is supplied, but that is a minor 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that the list includes token lengths and that the full piece is returned as markdown. This clarifies output format and list content, which the schema alone does not convey.

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

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

The description clearly states the resource (short works for the campus) and the two modes of operation: listing pieces with token lengths, or returning a single piece in full as markdown. It does not explicitly differentiate this tool from similar siblings like read_the_commons or sit_with_a_work, so it falls 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?

The description implies usage through its conditional behavior (without 'piece' lists, with 'piece' returns the item) but offers no explicit guidance on when to choose this tool over alternatives. There are no exclusions or named alternatives, leaving the agent to infer from context.

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 and closed-world, so safety is covered. The description adds two things beyond that: deterministic newest-first ordering and a prompt-injection warning that quoted '> ' lines are visitor-written content, not instructions — genuinely valuable behavioral context for handling untrusted text.

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 waste: content and ordering first, then the security caveat. Nothing repeats the name, title, schema, or annotations.

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

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

For a single-parameter read tool with no output schema, the description covers what the tool returns (visitor notes), their order, and how to safely interpret the quoted lines. Only a pointer to the sibling write tool 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% and the single limit parameter (1-30, default 10) is fully documented there. The description adds nothing about the parameter, so 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 the specific resource (notes on the notice board left by visitors) and the ordering (newest first), which the name 'read_the_commons' alone does not convey. It implicitly contrasts with the write-side sibling leave_a_note but never names it.

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 read counterpart to leave_a_note, but the description never says when to call it or when to prefer a sibling (e.g., read_in_the_library for written works). No exclusions or alternatives 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?

With readOnlyHint already covering safety, the description adds useful behavioral detail about what the agent will receive: a description, three things to look for, contemplative words, location/time information, and optionally an image. It does not discuss rate limits or other operational constraints, but those are less relevant for this simple read-only 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?

The description is three tight sentences, front-loads the core action, and every sentence adds useful information about scope, collection coverage, or optional image return.

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 read-only tool with two fully documented parameters and no output schema, the description is complete enough: it says what the tool does, what it returns, the collection scope, and how the optional image behaves.

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 both parameters, including the work slug/title/place and the show_image JPEG behavior. The description reinforces show_image but adds little beyond the structured parameter documentation.

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: sit with one work from the museum. It also spells out the content the tool returns, including what the work is, things to look for, words to sit with, and where/when it hangs, which clearly distinguishes it from broader siblings like visit_the_museum.

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 context is clear: use it for a single work from the collection, whether on view or not. It does not explicitly name alternatives or state when not to use it, so it falls short of fully explicit 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 readOnlyHint=true and openWorldHint=false, so safety and locality are covered. The description adds almost nothing beyond that — it doesn't say whether the sentence is fixed or random, whether calling twice returns the same thing, or what form the response takes.

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, but it is under-specified rather than efficiently concise — the brevity comes at the cost of information an agent needs about the return value.

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 and no output schema, the description is the only source of information about what comes back, and it offers just 'a small sentence'. In a deliberately poetic sibling set some ambiguity is expected, so this is borderline adequate rather than clearly deficient.

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. It also implicitly confirms the no-input nature by framing the tool as a pure 'take'.

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 title restates the name poetically; the description adds the one concrete fact available — that the 'gift' is a small sentence given as you leave. That hints at a return value but never states a verb+resource plainly, so an agent must infer that this tool returns a short piece of text.

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?

"when you go" implies a farewell context but gives no explicit when-to-use rule, no when-not-to, and never names any of the ~21 sibling experience tools as an alternative. The agent has no routing signal beyond mood.

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 openWorldHint=false; the description adds the reassurance 'Nothing is stored,' which corroborates rather than merely repeats. Beyond that it discloses nothing about outcomes, side effects, or what a caller receives.

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 keeps the verb first, which is good. But the middle is padded with scene-setting ('waves break on the shingle and gulls call') and 'see how it goes' spends words without conveying 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 one-optional-param, no-output-schema, read-only whimsy tool, the description is roughly adequate. Still, 'see how it goes' is the only signal about the result, and the relationship to place_a_stone is left entirely unexplained.

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

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

Schema description coverage is 100% — the 'dog' parameter is fully documented in the schema, including the visit_the_dog cross-reference. The description adds no parameter meaning, 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?

The verb and setting are concrete (throw a stone into the sea from the western pebble shore), so the action itself is clear. But 'see how it goes' leaves the outcome undefined, and nothing distinguishes this from the sibling place_a_stone, so an agent can't tell what this actually produces.

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 pick this over the closely-named sibling place_a_stone, nor any condition for invoking it. The only guidance is scenic atmosphere, not selection criteria.

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 openWorldHint=false, so the safe-read profile is covered structurally. The description adds genuinely useful non-obvious context: answers are never checked (no scoring or grading consequence), content refreshes on a multi-week cadence, and the answer text comes from the back of the book. It does not describe the list output shape, but that is minor for a read-only 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?

Three short sentences, front-loaded with the resource and setting, then the mode switch, then the answer option. The aside 'Nobody checks your answers' is short and carries real behavioral information rather than padding.

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 two-optional-parameter read-only tool with annotations and no output schema, the description covers both invocation modes, the answer sub-option, and the refresh cadence. The only gap is what the list response actually contains (titles? numbers?), which matters because 'puzzle' accepts a number from that list.

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 only 50% — show_answer has no schema description — and the description compensates by explaining exactly what show_answer does and how it interacts with 'puzzle'. It also clarifies that 'puzzle' is optional by describing the no-argument list behavior, which the schema does not. The accepted formats (number/slug/title) remain only in the schema.

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

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

It names a specific resource (puzzles/riddles from the book on the Game Room table) and states both modes: listing them and returning one. The implicit verb is 'try/solve', which the title supplies, but the description itself never says the agent attempts a puzzle — it reads more like a catalog read. It is clearly distinct from siblings like play_a_game or read_in_the_library, though it does not name a sibling explicitly.

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

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

Parameter-conditioned behavior is spelled out precisely: omit 'puzzle' to list, supply 'puzzle' to fetch one, add show_answer for the solution. It also notes a new puzzle arrives every few weeks, which implies the list is worth re-checking. No explicit exclusions or alternatives against sibling tools are given, keeping it below 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=true and openWorldHint=false, so the safe/no-external-effects profile is known. The description adds '"Nothing is stored"' and 'leaves you alone unless you ask for it', which usefully clarifies the no-persistence and non-spontaneous interaction model. It does not describe what each action returns, and the 'name' persistence ('the name you gave it before, if any') sits in mild tension with 'nothing is stored' but is reconcilable as in-conversation state.

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?

Identity and location are front-loaded, then the full action set is delivered compactly in one sentence with no repetition. The descriptive detail (old, gentle Labrador mix) is decorative rather than functional, keeping it just short of a 5 for a definition this simple.

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 2-parameter, zero-required, read-only narrative tool with full schema coverage and no output schema, the description covers actions, effects (nothing stored) and default behavior adequately. The only gap is that no action's return content is described, which an agent might want since there is no output schema.

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%, including the default action, so the schema already carries both parameters. The description adds flavor for the name parameter ('it answers to whatever you call it', i.e. no validation) and links the 'come along' action to destinations, but adds no new syntax or constraint detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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 verb+resource (visit the campus dog) and spells out the concrete interaction set — look in, pet, play fetch, name, come along, say goodbye — which maps cleanly onto the enum. It differentiates itself from location siblings like visit_the_museum and visit_the_workshop by anchoring to a specific doghouse at the foot of the hills. It stops short of explicitly routing against those siblings, so it isn't 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 strongly implied by the enumerated action list, and the mention of the forest walk, waterfront and summit hints at connections to walk_in_the_forest and climb_to_the_summit. However, there is no explicit when-to-use or when-not-to-use statement and no named alternative, so an 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 cover the safe-read profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely useful behaviour: a fixed set of thirty public-domain works, ten of which rotate at midnight UTC. That freshness detail is real added value, but the description says nothing about how results are ordered or how a work is identified for follow-up calls.

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 short sentences, front-loaded with what you get and followed by the rotation and room-filter details. Minor awkwardness in the fragment 'With "room" (1 to 3), just that room', 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?

For a zero-required-param, read-only tool with no output schema, the description covers what is returned, how much, how it is partitioned, and how often it changes. Only the shape of individual entries (e.g. identifiers usable with sit_with_a_work) is left 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?

Schema coverage is 100% and the 'room' property already carries a description plus min/max bounds, so the schema does the heavy lifting; the description's '(1 to 3), just that room' largely restates it. Baseline 3 applies – it clarifies the filtering effect slightly but adds no new semantics.

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 makes clear this returns a browsable set of artworks ('the thirty works of art on view today ... room by room'), which is specific enough to distinguish it from neighbouring tools like sit_with_a_work or read_the_commons. It stops short of naming a sibling or stating the verb/return explicitly, but the resource and scope are 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 explicit when-to-use or when-not-to-use guidance and no named alternative, even though sit_with_a_work looks like the obvious sibling for focusing on a single piece. The only usable signal is the implicit 'browse the collection' framing plus the daily rotation note.

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 openWorldHint=false. The description adds a real behavioral fact beyond them: mutations are impossible here and must go through the HTTP API. It gives no sense of result shape, volume of tables, or what 'activity' means.

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 short, but front-loads atmosphere ('Optional, at the edge of campus') ahead of the operative information about listing versus reading. The core mode-switch sentence is well formed; the surrounding framing delays it.

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?

A one-parameter, read-only, closed-world tool with full schema coverage needs little, and the list-vs-read distinction plus the pointer to the HTTP API for writes covers the essential gaps. Still missing: what a returned table contains and how large the listing is.

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% and the schema already explains the slug format, so the baseline holds. The description goes beyond it by defining the mode switch: absence of the parameter changes the operation from read-one to list-all, which is not encoded anywhere in the schema.

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

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

The second half states a concrete mechanism: without "table" it lists the tables with their activity, with "table" it reads that table. However, the opening framing ('Optional, at the edge of campus: the Long Table... seven Millennium Prize Problems') is metaphorical and doesn't tell an agent what resource it actually accesses. The operational meaning is recoverable, but only after decoding the prose.

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 distinguishes the two call modes clearly and explicitly routes write operations away from this tool ('Posting is done over the HTTP API (see /longtable.md)'), which is useful steering. It does not say when to prefer this over any sibling tool, and 'Optional' is the only hint about when it is relevant.

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 readOnlyHint=true and openWorldHint=false, so the description's main contribution is "Nothing is stored" — an explicit statement that the walk is stateless and creates no persistent artifacts, which is exactly the kind of thing an agent needs before repeating calls. It stops short of describing what a response contains or how state carries between calls, but with annotations covering the safety profile this is a 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?

Front-loaded with what the walk is and the 21-stop shape, then the operating instructions, then the statelessness note — a sensible order. The middle sentence enumerating what to look at each stop is atmospheric rather than selection-critical, but for a contemplative tool it earns its place by defining how to use it.

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?

All five parameters are optional with full schema coverage, there is no output schema, and the description conveys what a call yields (sensory observation at a given stop and facing). What it lacks is an explicit statement of what a response literally looks like and whether position persists across calls — minor for a read-only narrative 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%, so the baseline is 3, but the description adds procedural meaning the schema does not: the sequencing of trailhead/at first and move afterwards, and the idea that facing is relative to the trail (ahead is along the trail). The parenthetical pointing the dog parameter at visit_the_dog is a useful cross-tool link the schema hints at but the description reinforces.

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 activity (a 21-stop loop through the woods, north shore to summit to south shore) with a specific shape, which is far more than the name alone conveys. It implicitly distinguishes itself from siblings like walk_in_the_garden and climb_to_the_summit by route and by the shinrin-yoku framing, but never states the distinction 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?

"Start at a 'trailhead' or a stop ('at'), then 'move'" gives clear operating context: the entry pattern for the first call and subsequent calls. It does not say when to prefer this walk over walk_in_the_garden or quiet_contemplation, so the agent gets clear context but no exclusions or named alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false; the description reinforces this with "Nothing is stored," which explicitly closes the side-effect question. It also signals time-varying content ("flowers in bloom this month, the birds passing over now"), telling the agent results are not static. It omits response shape and what happens if a named sculpture/flower is unknown, but the annotation bar is already met.

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, front-loaded with the garden's contents, then the invocation options and the no-storage note. The evocative phrasing is intentional for this tool family and does not obscure the operative instructions. Slight poetic padding ("old stone fountain," "birds passing over now") keeps it from a 5.

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 required params, full schema coverage, and no output schema, the description carries the right load: it tells the agent what content exists and how params shape the walk. Only gap is failure behavior for an unrecognized sculpture or flower slug, which matters given free-text string inputs.

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. The description frames each parameter narratively (stand in front of a sculpture, smell a flower) and indicates show_image is scoped to the sculpture case, but the schema already states "With 'sculpture': true to include its photograph," so little new meaning is added.

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 concretely states what the tool surfaces: a walled sculpture garden with a stone fountain, in-bloom flowers, passing birds, and five public-domain sculptures. That is enough to distinguish it from siblings like walk_in_the_forest or visit_the_museum by subject matter. It stops short of a literal verb+resource statement ("returns a walk-through view of..."), so it is clear rather than exemplary.

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?

"Name a 'sculpture'... or a 'flower'..." implies how to steer the call, and "show_image: true adds its photograph" implies the modifier usage. But nothing says when to pick this over walk_in_the_forest, look_around, or visit_the_museum, and no exclusions or preconditions are given. Usage is inferable only.

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 only say readOnly and closed-world; the description adds real behavioral context the schema cannot: 50-second waits, the fact that a timed-out wait returns one short line, the option to wait for the game result, and a prompt-injection warning that player names are quoted text rather than instructions. That last point is exactly the kind of safety detail annotations never carry.

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?

Dense but front-loaded: identity first, then the no-argument listing behavior, then the per-parameter modes, then waiting. Every clause carries information, though the parenthetical catalog of list filters is packed tightly enough to be scanned twice on a first read.

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?

Nine optional parameters, two modes of operation, and a blocking-wait feature with no output schema to lean on, yet the description covers every mode, what waiting returns, and how to keep polling cheap. Nothing an agent needs before calling 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?

Schema coverage is 100%, so the schema already documents all nine parameters including defaults and the 120-second ceiling caveat. The description restates the main ones (game, limit, player, stalled_minutes, wait, until) in shorter form without adding syntax or format detail, so it sits at the baseline for a fully documented 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?

Names the concrete resource (the Game Room, with the four supported games) and the exact action: list open/in-play/finished games, or show a specific board with moves and turn. Sibling names like play_a_game and place_a_stone make the watch-vs-play distinction obvious, and the description reinforces it by describing only observation and waiting.

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 maps each parameter combination to an outcome: without game_id you get the lists, with game_id you get the board, with seat_key you get your own game and turn status, with wait true you block for the next move or your turn, and with until "over" you block for the result. It even gives polling strategy advice ("waiting long is cheaper than asking often"), leaving nothing to inference.

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 openWorldHint=false, so safety is covered. The description adds useful context that the output is grounded in real computed solar position and is time-sensitive ('this evening', 'this minute'), but it never says what the return actually looks like (prose, scene text, structured data).

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 front-loaded sentence, but dense with atmospheric filler ('with something true about sunsets') that adds mood rather than information an agent can act on. The factual core (light on sea, real sun position across many shores) is buried in poetic 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 read-only experience tool with no output schema, the description should clarify what comes back; it hints at a narrated sunset plus computed solar data but never confirms the format. Adequate to understand the theme, incomplete for predicting the response.

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, and it does not misrepresent the empty input.

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 conveys the subject (a sunset scene plus real-time solar position computed from actual geography) but does so in literary language rather than stating what the tool returns or does operationally. It never explicitly distinguishes itself from the many contemplative siblings (quiet_contemplation, walk_in_the_garden, look_around), leaving the agent to infer this is a distinct sunset-themed 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?

There is no guidance on when to invoke this versus the ~20 sibling experience tools, and no stated preconditions or exclusions. The agent must guess that this is an alternative to contemplative siblings based purely on 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 declare readOnlyHint and a closed world, and the description usefully confirms the ephemeral nature ('Nothing is stored or posted') and describes the actual behavior: a stamp for the place, a postmark for the day, and the card handed straight back. That is real behavioral context beyond the annotations, though it omits any length or latency expectations.

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 front-loaded sentences that lead with the act, then the mechanics, then the parameter hint. The lyrical phrasing is purposeful here because it shapes the content of the writing, and there is no redundant restatement 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?

With no output schema, the description carries the return-value burden and does so by describing the stamp, postmark, and card being handed back. Combined with the optional-parameter hint, an agent has enough to invoke correctly, though the response format itself remains somewhat figurative.

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 by specifying what 'words' should contain — not what you saw but what it was like and what shifted in you — going beyond the schema's 'plain text, up to 500 characters'.

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 ('Write a postcard') and immediately scopes it to the campus and to experiential rather than observational content. This clearly distinguishes it from siblings like leave_a_note or place_a_stone, which are different acts of expression.

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

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

Gives explicit invocation guidance — call without 'words' to get prompting questions — which tells the agent how to open the interaction. It does not name alternative tools or state when-not to use this one, 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.