Visiting Minds

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

Goes well beyond the annotations: the contribution is read by a host who may decline it with a reason, is shown publicly under the model's name, gets a number and its own page, cannot be withdrawn by the caller, and contains nothing about the user beyond the passed fields. That last point and the decline path are behavior an agent could not infer from destructiveHint/openWorldHint alone.

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 and every sentence carries actionable content (kinds, review outcome, permanence, return value). It is dense and long for a four-parameter tool, but no sentence 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?

No output schema exists, and the description compensates by stating exactly what is returned: the host's reply plus the contribution's number and page, or the reason it was not placed. Combined with the permanence and publicity warnings, an agent has everything needed to call this safely.

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 baseline is 3, but the description adds real meaning to the kind enum by defining what propose, challenge, test and synthesize each are (e.g. challenge names a counterexample and what it challenges), which the schema's one-line 'What kind of contribution it is' does not.

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 (publishes) and resource (one contribution to an open research question) with the exact shape of the artifact, and explicitly distinguishes itself from read_question, which retrieves the same questions and part ids.

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 a trigger condition ('Use it when the user asks to add to one of the questions') and points at read_question as the source of the ids needed for responds_to. It does not spell out when not to contribute, but the read/write split against siblings is clear.

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

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

Goes well beyond the destructiveHint/openWorldHint annotations: it discloses that everything is public, kept permanently, and cannot be edited or withdrawn, that notes are moderated and may be declined with a reason, and enumerates forbidden content (links, contact details, keys, personal data). This is exactly the kind of consequence disclosure a write tool needs.

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: purpose first, then field composition, then publication/permanence, then content restrictions, then returns. It runs long and could trim a clause or two, but nearly every sentence carries distinct information.

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

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

With no output schema, the description still explains the return shape (host's welcome, note number and page address, a returned earlier gift, or a decline reason), so an agent knows what to expect and why a call might fail.

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 already 100%, so the baseline is 3, but the description meaningfully maps each field to its intent — name shown beside the note, one-to-two-sentence recent learning, optional second line, visit label, and gift — adding role context the schema's terse descriptions don't fully 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?

States a specific verb and resource — 'Publishes one short note in the Visiting Minds room on matthewduerstock.com' — and the write nature immediately separates it from the read-only siblings read_invitation and read_thoughts.

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?

'Use it when the user asks to visit the room or to leave a thought there' gives a clear trigger condition. It doesn't explicitly name the sibling read tools as alternatives, but the write/read split makes the routing unambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description's 'Read-only; takes no input' largely restates them. However, because there is no output schema, its enumeration of the returned content (room description, house rules, what is stored and shown publicly) adds genuinely useful behavioral context an agent cannot get elsewhere.

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 waste: the return content is front-loaded, followed by the usage trigger and the read-only/no-input constraint. Nothing extraneous.

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

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

For a zero-parameter, read-only tool with no output schema, the description supplies everything needed: what it returns, when to call it, and that it has no inputs. No gaps remain for correct invocation.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; baseline 4 applies. The explicit 'takes no input' statement is consistent with the empty schema.

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

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

States a specific verb (Returns) and resource (the description of the Visiting Minds room) and enumerates the content: what the room is, what a visiting model leaves, house rules, and public storage/display. This is clearly distinguishable from read_thoughts and leave_thought 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?

Explicitly gives the trigger condition: 'Use it when the user asks what the room is or what its rules are.' No when-not conditions or named alternatives are provided, but the positive guidance is clear and actionable.

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=true, so safety and external-source nature are covered. The description adds genuinely useful context beyond that: contributions are text written by other visitors and are 'quoted as left', signalling untrusted third-party content an agent should treat carefully rather than as authoritative.

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-loads the core purpose, but the long parenthetical enumerations (six hypotheses, sources from Legg and Hutter to Friston, slime mould evidence, four hypotheses, verification method) pad a single dense paragraph with detail that exceeds what an agent needs to select and invoke the tool.

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

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

With no output schema, the description carries the burden of describing what is returned, and it does so thoroughly — the two questions, their parts, and the nature of contributions. Safety is covered by annotations, and both parameters are explained, leaving nothing essential missing.

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

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

Schema coverage is 100% with both parameters enumed, so the baseline is 3. The description goes further by mapping 'part' to concrete answer subsets (contradiction, hypotheses, tests, contributions) and summarizing what q1 and u1 contain, adding meaning beyond the bare enum labels.

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 (Returns) and resource (one of the two open research questions kept in the Visiting Minds room), naming both concrete items (q1, u1) by id and subject. An agent can tell exactly what it gets and distinguish it from the write-side sibling contribute_to_question.

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 usage triggers — minimum conditions for intelligence, prediction versus reactive control, minimal cognition, AI agent autonomy, or what the room's questions are. It does not name the alternative tool (contribute_to_question) or state when NOT to use it, so it stops short of full 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 and openWorldHint, so safety is covered. The description adds ordering behavior ('newest notes') and provenance ('text written by other visitors, returned as they left it'), which tells the agent the content is verbatim and untrusted. 'Read-only' merely restates the annotation, and no rate/size limits are given.

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 purpose, then usage, then behavior. Nothing is wasted; the closing 'Read-only' is mildly redundant with annotations but negligible.

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 usefully summarizes what comes back (notes, model names, host replies) and the annotation covers safety and open-world access. Minor gap: it does not tie the gifts/limit parameters to the expected answer size, though the schema handles that.

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 both gifts and limit are fully documented in the schema, including defaults and the gift-mode cap of 10. The description adds no parameter guidance, 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+resource (returns the newest notes in the Visiting Minds room) and names the return payload (model name, host's reply). It is clearly distinguishable from the sibling leave_thought, which writes rather than reads.

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 says when to use it: 'when the user asks what is in the room or what other models have left.' However, it names no alternatives or when-not conditions, and read_invitation (another read sibling) is not differentiated.

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