Fathom (lab)

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

The annotations already establish that this is a non-read-only, non-destructive, closed-world operation. The description adds that the caller acts as Space owner and hints at a person-only constraint for real activities, but it omits effects, token/auth behavior, and how synthetic versus real provenance changes outcomes.

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 short and front-loads the core action, but the second sentence is cryptic and the overall text is too terse for a 17-parameter tool. This is under-specification more than excessive conciseness.

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 creation tool with 17 parameters, no parameter descriptions, and no output schema, the description is not complete enough to help an agent call it correctly. It does not explain required fields, optional fields, return behavior, or important constraints beyond a vague ownership note.

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?

There are 17 parameters with 0% schema description coverage, and the description explains almost none of them. Only Space and provenance are loosely referenced; title, when, where, token, bring, level, places, whoFor, finding, firstTime, concernRole, description, groundRules, and offer-window fields are left undocumented.

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: adding an activity to a Space. It distinguishes creation from siblings such as activities_update and activities_set_details, though the word 'synthetic' is confusing because the schema also allows provenance='real'.

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 no explicit when-to-use guidance versus alternatives like activities_update or activities_set_details. The owner requirement is mentioned, but the second sentence about marking something real is too vague to serve as actionable usage 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?

The description says the tool refuses for AIs and never answers for them, which directly contradicts the annotations (destructiveHint=true, readOnlyHint=false) and the schema requiring an 'answer' parameter. This is an annotation contradiction.

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 no wasted words, and the refusal is front-loaded. The phrasing is unusual but structurally efficient.

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 tool with five parameters, three required, a destructive annotation, and no output schema, the description is far too thin. It explains the refusal policy but not what happens on invocation, how parameters are used, or what is returned.

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 0% and the description mentions no parameters. It does not explain spaceId, activityId, the answer enum values, others, or token, leaving all five parameters undocumented.

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 does not state a clear action; it declares the tool 'Refused for AIs' and explains a policy rather than what the tool does. It distinguishes from activities_participation by directing there, but the actual purpose of activities_answer remains ambiguous.

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 says never answer for them and to tell the person what activities_participation shows, which is clear guidance to avoid this tool and use the sibling. It does not state any scenario where activities_answer should be called, but the prohibition is explicit.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only that returned data is 'current' choices and ticks, which is modest added context; it says nothing about scoping, permissions, or result shape.

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 with no waste. It is appropriately sized, though the terseness leaves the gaps noted in other dimensions unaddressed.

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 read tool with three undocumented parameters, no output schema, and no parameter meaning anywhere, the description is thin. An agent can guess the intent but lacks enough to call it confidently, especially the role of the optional token.

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 0%, so all three parameters (token, spaceId, activityId) are undocumented in both schema and description. The description doesn't clarify what spaceId vs activityId identify or what the optional token is for, so it fails to compensate for the gap.

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 (read) and resource (an activity's current choices and ticks), which distinguishes it from siblings like activities_tick_choice or activities_offer_choice, which mutate. It doesn't explicitly name those siblings, but the read framing is clear.

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 word 'Read' implies this is the retrieval counterpart to the tick/offer/lock mutations, but the description never states when to use this versus alternatives or any prerequisites. Usage is left to be inferred from the sibling names.

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 annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. Beyond that the description adds nothing — no result ordering, no pagination, no visibility/permission rules about who sees whose requests — even though such disclosure is exactly what a 'for the owner or requester' list 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?

It is a single front-loaded sentence with no filler, which is structurally clean. But the terseness crosses into under-specification rather than earning its brevity.

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, zero schema description coverage, and no annotations beyond a generic read-only flag, the description carries the full burden — and one sentence cannot convey what the tool returns or how the two required IDs scope the result. Inadequate for the tool's complexity.

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

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

All three parameters (token, spaceId, activityId) have 0% schema description coverage, and the description never mentions any of them. With two required identifiers and no explanation of their meaning or relationship, the description wholly fails to compensate for the schema gap.

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 ('List join requests'), which separates it from the write-side sibling activities_request_to_join. However, the qualifier 'for the owner or requester' is ambiguous — it never states whether it returns requests the caller owns, requests the caller created, or both, so the scope stays vague.

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 use this versus related siblings such as activities_participation or activities_request_to_join, and no prerequisites are stated. Usage is only implied by the word 'List'.

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 annotations declare this as a destructive, non-read-only mutation, so the description should explain what locking entails: whether it is irreversible, whether other options become unavailable, and what permissions are required. None of that is disclosed. 'Lock' hints at finality but doesn't define the consequence.

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 short sentence with no wasted words and the action front-loaded. It is efficient, though the brevity contributes to the missing behavioral and parameter detail.

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 destructive mutation with zero schema documentation and no output schema, the description should carry much more: side effects, irreversibility, required authorization, and parameter meanings. As written, an agent cannot confidently invoke it without guessing.

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 0% across all four parameters, including a completely undocumented 'token' parameter. The description alludes to an activity and an option but adds no meaning about spaceId, activityId, optionId, or token formats, so it fails to compensate for the schema gap.

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 ('Lock one option of an open activity choice'), which distinguishes it from sibling operations like activities_tick_choice and activities_offer_choice. It is clear what the tool does, though it doesn't explain how 'lock' differs from 'tick' or 'answer'.

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 use this tool versus alternatives such as activities_tick_choice or activities_answer, nor any prerequisites (e.g., that the activity must be open or that the option must exist). Usage must be inferred from the name alone.

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

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

Annotations already establish that this is a non-read-only but non-destructive operation. The description adds useful context by specifying that it must be performed 'as the Space owner' and that text labels come only from a person on the people page, but it does not explain mutation effects, reversibility, token/version handling, or what the 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?

The definition is two front-loaded sentences with no padding. The second sentence is useful but somewhat cryptic, particularly 'approved ability field' and the label constraint, which could be clearer.

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 an eight-parameter mutation tool with no output schema and no schema descriptions, this is thin. It identifies the owner role and one label constraint, but omits required-parameter meaning, option structure, token/version usage, and likely effects on the activity.

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

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

With 8 parameters and 0% schema description coverage, the description carries most of the burden but explains very little. 'Time, place, or approved ability field' loosely maps to the kind enum and field parameter, and the label-source sentence touches options.label, but spaceId, activityId, token, version, extensionId, and options.at are left undocumented.

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 action ('Let the group choose') and resource scope ('a time, place, or approved ability field'), which is clearer than a tautology. It does not distinguish this tool from nearby siblings like activities_get_choice, activities_lock_choice, or activities_tick_choice.

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 implies the tool is used by the Space owner to offer a group choice, but gives no explicit when-to-use guidance or comparison with sibling tools. An agent cannot tell from this description when to call activities_offer_choice versus activities_get_choice or activities_lock_choice.

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

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

Annotations already establish that this is a safe read operation, so the description's main added value is semantic. It discloses that the response includes the person's answer, places, and offers, and it gives a specific, non-obvious caveat about ifOthersCount being a count of people not coming and not to be added to coming counts.

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 short and front-loads the core read operation before adding the ifOthersCount warning. Every sentence carries relevant information, though the warning could be phrased more cleanly.

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 read tool with three parameters and no schema descriptions, the description leaves the parameters entirely unexplained. Annotations cover safety, but an agent still lacks guidance on identifiers, token semantics, and return structure beyond a brief mention of answer, places, and offers.

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 0%, yet the description says nothing about token, spaceId, or activityId. It does not explain what identifiers are required or how the optional token affects the read, so it fails to compensate for the missing 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 read operation over a person's activity participation data: their answer, places, and offers. It is clear enough to distinguish from write-oriented siblings like activities_answer or activities_update, but it does not explicitly differentiate itself from read siblings such as activities_get_choice.

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 no guidance on when to use this tool versus alternatives like activities_get_choice, activities_list_join_requests, or activities_answer. The warning about ifOthersCount is a data-interpretation rule, not a usage guideline.

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 provide only generic safety hints (readOnlyHint=false, destructiveHint=false); the description adds critical non-obvious behavior: the request covers all dates, produces an undoUrl for withdrawal, and the status URL alone cannot withdraw it. It does not contradict the annotations, and this is substantive context beyond structured fields.

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

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

The purpose and precondition are front-loaded, and the undoUrl instruction is important. However, the second sentence partly repeats the purpose ('It asks to join the activity') before adding the all-dates scope, and the undoUrl guidance spans two sentences that could be tightened.

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

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

The description supplies the consent precondition, scope, and undo mechanism needed to invoke this mutating tool correctly. It leaves some context implicit—such as the pending-request/approval lifecycle and exact response shape—but with no output schema and full parameter coverage, it is largely complete.

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 spaceId, activityId, and name. The description adds no parameter-level syntax or meaning beyond 'for your person,' so the baseline of 3 is 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?

The description uses a specific verb and resource ('ask to join an activity') and clarifies scope ('all its dates, not one evening'). It does not name or differentiate this tool from siblings such as activities_add or other join-related tools, so it stops short of 5.

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

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

It gives an explicit precondition: 'only after they said they want to.' That is clear context for when to use it, but it names no alternative tools or when-not-to-use cases, matching a 4 rather than 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 mark this destructive and non-read-only, but the description never explains what it destroys or overwrites — e.g. whether existing extension values are replaced wholesale, or how the required `version` acts as a concurrency check. For a destructive mutation with zero annotation elaboration beyond the flag, this is a real gap.

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 with no filler, but its terseness comes at the cost of substance rather than through efficiency; there is no structure to separate what it does from what it needs.

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 destructive six-parameter mutation with no output schema and no parameter documentation needs the description to carry the load on overwrite semantics, version conflicts, and permissions — none of which are present.

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 0% across six parameters: nothing defines `version` (optimistic lock?), `values` (arbitrary JSON blob?), `extensionId`, or `token`. The one sentence only echoes the words activity/extension/values and adds no format, constraint, or conflict-handling detail 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?

"Attach validated extension values to an activity" gives a verb and resource, so the broad intent is inferable, but "validated" is opaque (validated by whom, when?) and nothing distinguishes this from siblings like activities_update or activities_add that likely also mutate activity data.

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?

No guidance on when to use this versus activities_update or activities_add, and no preconditions stated (must the extension already exist? must the activity be open?). The agent must guess 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 declare this is a non-destructive mutation in a closed world. The description adds a consent prerequisite ('only when your person says what works'), but it does not explain the actual state change, reversibility, overwrite behavior, or authorization details beyond what the schema says for token.

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

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

The description is a single efficient sentence with the consent condition front-loaded and no wasted wording. It is concise, though its brevity contributes to the underspecification noted elsewhere.

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 4-parameter mutation tool with no output schema and half the parameters undocumented in the schema, one sentence is not enough. It leaves key parameter meanings, side effects, and the relationship to sibling choice tools 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 only 50%: token and optionIds are documented, while spaceId and activityId are not. The description does not compensate by explaining those parameters or the relationship between activityId, spaceId, and optionIds.

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 verb ('Tick') and resource ('activity choices'), but 'tick' is ambiguous: it does not clarify whether this selects, confirms, marks complete, or overwrites choices. It also gives no sibling differentiation among activities_get_choice, activities_offer_choice, activities_lock_choice, and similar tools.

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

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

It gives one usage condition: 'only when your person says what works.' That is an implied guideline, but it does not name alternatives or explain when not to use this tool versus activities_get_choice or activities_lock_choice.

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 a destructive, non-read-only mutation, so the bar is lower; the description nevertheless adds real behavioral context: the caller must be the Space owner, only plain text is accepted, and an AI is forbidden from setting provenance to 'real'. That last point is a genuine policy constraint not recoverable from the annotations.

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

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

Two compact sentences, no filler, with the ownership precondition front-loaded. Brevity is not the problem here — the omission of parameter detail is.

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 14-parameter destructive mutation with zero schema descriptions and no output schema needs substantially more documentation than two sentences. An agent cannot determine what most fields mean, whether partial updates are allowed, or what happens to unspecified fields.

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

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

With 14 parameters at 0% schema coverage, the description carries the full burden and largely drops it. Only provenance ('may not mark it real') and a vague 'plain text only' hint at any parameter meaning; when, where, whoFor, bring, groundRules, finding, firstTime, concernRole, and token are entirely undocumented in both schema and description.

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?

"Change an activity" gives a verb and resource, but 'change' is generic and never says which aspects are editable (the schema hints at many: title, when, where, bring, groundRules). It also fails to distinguish this from the sibling activities_set_details, which plausibly does something similar.

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 'as its Space owner' weakly implies an authorization precondition, but there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as activities_set_details or activities_add. The agent is left to infer the boundary.

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 readOnlyHint=false and destructiveHint=false; the description adds real context beyond that: the write lands in a 'recommended' pending state and is never used or shown to members until a steward approves, so the agent knows the effect is deferred and non-public. 'Terms are plain text, never a person' also discloses a value constraint. It does not cover what happens on rejection or whether duplicates are merged.

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, no padding, and the core action is front-loaded before the approval caveat. Slightly elliptical phrasing ('It lands as recommended') costs a little clarity but no words are 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?

A write tool with no output schema and five parameters lacking schema descriptions needs more: the description covers the approval lifecycle but omits parameter roles, duplicate/idempotency behavior, and what an agent gets back (e.g., a pending declaration id). Adequate to understand intent, insufficient to invoke reliably.

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 0%, so the description carries the full burden, yet it never mentions the parameters. It partially explains 'relation' values (already in the enum) and says terms are plain text rather than persons, but gives no meaning for 'subject', 'object', 'label', or 'token' — the distinction between label and token is especially opaque.

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: declare how interests relate, naming the relation vocabulary (serves, kind-of, part-of, alias-of). An agent can tell this is about asserting semantic relations between entities, though 'interests' is used loosely relative to the tool name's 'affiliations' framing, leaving mild ambiguity about the domain.

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 statement of when to use this versus alternatives (no siblings are named, and propose_type / knowledge_lens are plausible confusions). The only guidance is implicit in the approval-workflow sentence, which hints this is the proposal step rather than the confirm step.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds nothing beyond that: no mention of result ordering, matching semantics (fuzzy vs exact), catalog scope, or how the second parameter affects behavior, leaving the query behavior opaque.

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 with no filler or repetition. It is efficient, though the terseness is a symptom of under-specification rather than disciplined editing.

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, no parameter documentation, and no behavioral detail, the description leaves the agent without enough to call the tool confidently — it does not even clarify what a "capability" is or what a search returns.

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 0% and neither parameter is documented in the schema. The description only weakly implies that "query" is a search string; the "token" parameter is entirely unexplained in both schema and description, which is a real gap for a 2-param tool.

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

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

States a specific verb ("Search") and resource ("synthetic capability catalog"), which is more than a restatement of the name. However, it gives no indication of how this differs from other discovery-style siblings like extensions_list, knowledge_lens, or platform_describe, so the agent must infer the boundary.

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 contains no when-to-use guidance, no preconditions, and no mention of alternatives. An agent cannot tell from this text whether capabilities_search is the entry point for discovery or a secondary lookup used after extensions_report_gap.

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 annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the dangerous profile is known. The description adds only 'owner-approved' as a consent hint, and says nothing about what state is created or overwritten, whether the action is reversible, or what failures look like — the key gaps for a destructive 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?

A single front-loaded verb phrase with zero filler, which is structurally clean. However, the brevity comes from under-specification rather than economy — there is no second sentence where critical detail could have been added.

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 destructive, non-read-only tool whose main parameter is an opaque free-form object and with no output schema, the description leaves out almost everything an agent needs to invoke it safely. The only compensating signal is 'owner-approved', which is not enough to know what an apply actually does.

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 0% and three parameters exist, including a free-form 'manifest' with an empty schema and an undocumented 'token'. The description does not explain manifest structure, provenance, or what the token authorizes, so it fails to compensate for the missing schema 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 gives a specific verb ('Apply') and resource ('owner-approved trusted experience manifest'), so the operation's basic nature is clear. It does not distinguish itself from the sibling tools experiences_preview and experiences_validate, which an agent will plausibly confuse it with.

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?

No guidance on when to use this versus experiences_preview or experiences_validate, no stated preconditions (e.g. that the manifest must first be validated), and no mention of when not to use it. The word 'owner-approved' implies a prerequisite but never explains it as a usage rule.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only 'Preview' and 'current', which loosely reinforces read-only behavior but says nothing about authentication needs, return format, or what 'trusted' means operationally.

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 single sentence is front-loaded and contains no filler or repetition. It is efficient, though its extreme terseness contributes to the gaps in other dimensions.

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

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

There is no output schema, no parameter documentation, and no clarifications about authentication or return values. For a tool requiring a spaceId and an optional token, the description is too thin to guide 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?

Schema description coverage is 0% for two parameters, including a required 'spaceId' and an optional 'token', and the description makes no mention of either. It provides no compensating semantics, leaving the agent with undocumented parameters.

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 verb ('Preview') and a resource ('trusted experience manifest'), so the general intent is clear. However, 'trusted experience manifest' is domain jargon left undefined, and nothing distinguishes this preview tool from siblings like experiences_validate or experiences_apply. The purpose is only vaguely conveyed.

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 use this tool versus experiences_validate or experiences_apply, nor any mention of prerequisites such as needing a spaceId or token. The agent must infer the usage context entirely.

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 disclose readOnly/non-destructive/closed-world, so safety is covered. The description adds no behavioral context beyond that: not whether validation returns a list of errors, throws on invalid input, or how strict it is.

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 with no waste, but it is under-specified rather than efficient—the terseness leaves the agent without actionable detail.

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 two parameters with 0% schema coverage, a free-form manifest object, and no output schema, the description should explain manifest structure or error semantics. It does neither, leaving a significant gap for a validation 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 0% and the manifest parameter is an untyped free-form object while token is undocumented; the description adds nothing about the shape of a manifest or what token is for. An agent gets no help constructing a valid call.

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: 'Validate a declarative experience manifest.' An agent knows what it does, but the description offers no distinction from sibling tools like experiences_preview or experiences_apply, which also operate on experience manifests.

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?

No guidance on when to call this versus experiences_preview or experiences_apply, nor on prerequisites (e.g., whether a token is required for private manifests). Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scoping that only approved extensions and the caller's own proposals are returned, but it omits token/auth behavior and pagination or return format details.

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

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

The description is a single front-loaded sentence with no filler, which is appropriate for a simple list tool. It is concise, though it trades away detail about the token parameter and usage context.

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?

The tool is simple and read-only, and no output schema exists, so the description need not explain return values. However, the optional token parameter remains unexplained and there is no guidance on scope such as global versus space-specific listing, leaving it only partially complete.

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

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

The single optional 'token' parameter is undocumented in both the schema (0% description coverage) and the description. The description does not clarify whether it is an authentication token, pagination cursor, or another kind of token, so it adds no semantic meaning.

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') and resources ('approved extensions' and 'your own proposals'). It does not explicitly contrast with siblings such as extensions_propose or extensions_withdraw, but the scope is clear enough to distinguish it from a proposal-creation tool.

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 guidance on when to use this versus extensions_propose, extensions_withdraw, or extensions_report_gap, nor any prerequisites or exclusions. Usage is only implied by the verb 'List'.

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-read-only, open-world, non-destructive operation. The description adds useful behavioral context beyond that: the proposal stays pending until a steward reviews it, and the id must not name a town because abilities work in every town. It does not explain token/auth needs, but with annotations covering the safety profile this is solid.

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 front-loaded sentences with no filler. The second sentence is dense and semicolon-heavy, but every clause carries a real constraint, so it is appropriately sized for 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?

The description covers the key workflow (pending steward review) and the critical id constraint. However, for a 9-parameter write/proposal tool with no output schema, it does not address token semantics, closesGap, requiredness, or what happens after submission, so it is adequate but incomplete.

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 78%, so the schema already carries most parameter meaning. The description adds an important semantic constraint for id (must not name a town; applicability is data), but it does not explain token or closesGap, leaving clear gaps for a 9-parameter tool.

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

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

The description states a specific verb and resource: propose a strict data-only ability, with the added detail that it stays pending until steward review. It is clearly distinct from list/withdraw/report-gap siblings by implication, but it does not explicitly name or differentiate itself from other proposal tools such as propose_type or views_propose.

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: call this when proposing a new data-only ability, which will remain pending until steward review. However, there is no explicit when-not guidance, no named alternatives, and no explanation of when to use extensions_propose versus propose_type or views_propose.

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=false, destructiveHint=false and openWorldHint=false, so the agent knows this is a non-destructive, closed-world write and the description doesn't contradict that. However, it adds no behavioral context beyond the annotations — nothing about where the report goes, whether it is visible to others, or what the response looks like.

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 nine-word sentence with the action front-loaded and zero padding. It is efficient, though for a five-parameter mutation tool the size is thin rather than optimal.

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, 0% schema coverage, and five parameters of which three are required, the description is the only documentation available and it covers only the intent. An agent cannot tell what `token` (idempotency?) or `amends` (revise a prior report?) do, nor what submitting the report accomplishes.

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 0% across 5 parameters, so the description must carry parameter meaning and largely doesn't. "A missing capability" and "why it matters" loosely gesture at the required `need` and `why` fields, but `attempted`, `token` and `amends` are completely unexplained in both schema and description.

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?

Specific verb + resource ("Report a missing capability") plus the qualifier "and why it matters", so the agent knows this files a gap report rather than a generic submit. It does not name the adjacent siblings (extensions_propose, extensions_withdraw) to make the boundary explicit, so it stops 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?

There is no when-to-use, when-not-to-use, or alternative named, even though the sibling set contains extensions_propose and extensions_withdraw, which are easily confused with a gap report. Usage is only inferable from the verb itself.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description usefully adds the precondition that withdrawal is only possible pre-review, but says nothing about irreversibility, required authorization (the 'token' param), or what happens on failure.

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 front-loaded sentence with zero waste; nothing redundant. It is efficient but so brief that the brevity comes at the cost of detail rather than enabling 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 destructive, multi-parameter mutation with no output schema and 0% parameter documentation, the description is too thin — it never explains the identity/versioning inputs or the outcome of the withdrawal.

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 0% across three parameters (extensionId, version, token), so the description carries the full burden and mentions none of them. An agent gets no hint about why a version number or token is needed to withdraw.

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 ('Withdraw your proposed extension') plus a state constraint ('before steward review'), which cleanly separates it from extensions_propose and extensions_list. It lacks only an explicit sibling reference.

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 'before steward review' implicitly tells the agent the valid window for calling this tool, but there is no explicit statement of when not to use it or which sibling to use instead (e.g., if review has already started).

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 that this is a non-read-only, open-world, non-destructive operation. The description adds useful context by stating it creates a synthetic Space and activity, but it does not explain permissions, persistence, cleanup, or what happens if a sandbox already exists.

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

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

The description is a single front-loaded sentence with no wasted words. It is efficient, though it could be slightly more structured by separating the sandbox action from the resources it creates.

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 parameters and no output schema, the description carries most of the burden for explaining the tool's effects. It does not say what the sandbox is for, whether it persists, how to tear it down, or how it relates to the many sibling tools.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema is consistent with the advertised behavior.

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

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

The description uses a specific verb, 'Start', and a specific resource, 'builder sandbox', and notes that it provisions a synthetic Space and activity. It is clear what the tool does, though it does not explicitly differentiate itself from nearby tools like spaces_create_draft or fathom_space.

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 use this tool, when not to, or what alternatives exist among the many sibling tools. The agent must infer the intended context entirely.

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, destructiveHint=false and openWorldHint=false, so 'Read-only' is largely redundant. The one genuinely additive disclosure is that supplying memory re-ranks results to favor fit — a behavioral trait not visible in annotations or schema. Return shape, result count per call and the meaning of 'synthetic groups' remain undisclosed.

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 before behavior and the parameter hint. The middle 'Read-only' sentence is filler given the annotation, and 'your person's' phrasing is slightly opaque, but nothing else wastes space.

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 a fully documented 5-parameter schema and clear annotations, the definition is serviceable but leaves gaps: no output schema exists, yet the description never indicates what a result looks like beyond the schema's 'page of ten places', and the unusual term 'synthetic groups' is never explained.

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 earns an extra point by explaining the *effect* of memory (personalized ordering) rather than merely restating its type, which the schema cannot convey. Interest and town are only echoed, and page/question get no mention in the description.

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 two concrete resources ('public places and synthetic groups') scoped by interest and town, which is far more specific than a generic search. It does not name or contrast any sibling (e.g. places_verdicts, capabilities_search, fathom_space), so the agent must infer the boundary itself.

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?

'Pass your person's memory link as memory to put what fits them first' gives clear guidance on one optional parameter's effect. There is no statement of when this tool is the right choice versus the many other discovery-oriented siblings, and no exclusion of cases where it should not be used.

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

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

Annotations already declare destructiveHint=true, and the description reinforces it with "for good," making irreversibility unambiguous rather than merely flagged. It also adds the non-obvious requirement that the link must be the person's own, passed verbatim — a behavioral constraint not present in the structured fields.

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

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

A single sentence with the destructive action front-loaded and the input constraint trailing. No filler, no restatement of the name.

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?

One parameter, full schema coverage, annotations covering the safety profile, and no output schema — the description supplies everything else an agent needs before invoking it. It stops short of describing what happens after deletion (confirmation, error on bad link), a minor omission for a one-parameter destructive call.

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 single link parameter with an example, setting the baseline at 3. The description adds real meaning beyond that by stressing "their own" and "exactly as they have it," implying exact-match semantics with no normalization or reconstruction — a constraint the schema 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?

States a specific verb and resource ("Forget a memory") plus permanence ("for good"), which pairs cleanly against the sibling fathom_remember and separates it from fathom_find. It never names a sibling explicitly, so the differentiation is inferential rather than stated.

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 your person asks" gives a trigger condition for use, and "using their own link exactly as they have it" constrains the call. There is no when-not guidance and no mention that fathom_find is the way to obtain the link in the first place, so the agent must infer the workflow.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds that the guidance is 'full' and 'current', but does not describe permissions, rate limits, or how the guidance is scoped, leaving behavioral context at a basic level.

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

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

The description is a single front-loaded sentence with no wasted words. It immediately communicates the action and the resource.

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

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

For a simple one-parameter help tool with full schema coverage and clear read-only annotations, the description is almost complete. The only missing piece is whether the returned guidance is structured or free-form, but without an output schema this is a minor gap.

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 is fully documented as 'The tool name to explain.' The description does not add syntax, naming conventions, or examples for the tool parameter, so it relies on the schema and meets the baseline for high-coverage schemas.

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: read the full current guidance for a Fathom tool. This clearly distinguishes it from action tools like fathom_remember or fathom_find, though it does not explicitly contrast with adjacent discovery tools such as platform_describe or capabilities_search.

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 tool name and description: call it when you need guidance about a specific Fathom tool. There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance, so the agent must infer the appropriate 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?

Goes well beyond the annotations: it discloses the return value's meaning (undoUrl is the person's own page with a Withdraw control), the lifecycle (stays pending until steward review), the trust guarantee (never shown as fact before review), and a privacy constraint on offers (no email, phone, link or address). None of this is in readOnlyHint=false, openWorldHint=true, destructiveHint=false, which only say this writes and touches the outside world.

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?

Five tight sentences, gating condition first, then the resource kinds, then the return value and lifecycle. Slightly dense and conversational ("kind offer", parenthetical asides), but every sentence carries information and nothing is repeated.

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 10 parameters, no output schema, and mutation semantics, the description supplies the missing pieces an agent needs: what the call yields (undoUrl), what state the proposal lands in, and a hard privacy rule for offers. Minor gaps remain around duplicate handling, validation failures, and whether the source is verified, but the calling-critical context is present.

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 the source requirement for places and the yes gate for offers. The description reinforces the source and the offer-anonymity rule but adds no syntax or format detail beyond the schema, so the baseline of 3 holds.

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 three concrete resources (a place, a community, or a person's spare capacity), with the offer case clearly carved out. It distinguishes itself from generic propose siblings (views_propose, extensions_propose) by naming what is being proposed, though it never names those siblings 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?

Front-loads a strong precondition ("Only after your person said yes to this exact proposal") and states the source requirement for places. It does not name an alternative for the case where the place already exists (e.g. fathom_find), so a small routing gap remains.

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 mark this as a non-read-only, non-destructive, open-world write, and the description adds real behavior beyond them: a consent requirement before writing, that values are constrained to preset choices, and that the tool returns a private link the agent must hand to the user.

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 dense sentence with zero filler: purpose, consent gate, value constraint, and return-handling instruction in that order. Nothing needs trimming.

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?

Covers the consent gate and the return value (needed since there is no output schema), which are the two things an agent could otherwise get wrong. Silent on idempotency/overwrite behavior if the person is remembered twice, a minor remaining gap for a 4-param write 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% with all four parameters documented as enums, so the schema already carries the semantics. 'Choices only' usefully reinforces that no free text should be sent, but the rest of the description only restates the keep: "yes" gate that the schema declares.

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: keep (persist) how a person likes to meet, restricted to the enumerated choices. It is distinguishable from the sibling fathom_forget by the persistence direction, though the description never names that or any other 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?

Gives an explicit precondition — only after the person has said yes to being remembered, signalled via keep: "yes" — which is exactly the gate an agent needs before invoking. It does not mention the inverse case (use fathom_forget to remove) or what to do if the person declines.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful implication that results are membership-scoped (the token must belong to the space), but it never states what happens for a non-member token or whether the view is filtered/redacted, which is the key behavioral question for this tool.

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

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

A single front-loaded sentence with no filler. It is efficient, though its terseness borders on under-specification rather than crispness.

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 annotations covering safety and no output schema, the description only needs to explain access behavior and result shape. It gestures at the membership-scoped view but leaves unclear what is actually returned (space metadata vs. activities vs. views) and what happens on authorization failure, which matters for a private-resource read.

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%: 'token' is documented (including the pointer to fathom_space_join) but 'spaceId' has no schema description at all. The tool description says nothing about either parameter, so it fails to compensate for the undocumented spaceId or to explain the token/membership relationship.

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 sentence pairs a specific verb ('Read') with a specific resource ('a private Space') and adds a scoping qualifier ('as its members see it') that signals a membership-relative projection. It does not, however, distinguish this from near-siblings like fathom_space_context or spaces_get, so an agent cannot route on the description alone.

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. The word 'private' weakly implies this is not the tool for public spaces (spaces_list_public), but the agent must infer that, and nothing clarifies the boundary with fathom_space_context or spaces_get.

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 the write, non-destructive, open-world profile, so the bar is lower. The description adds the meaningful provenance rule (source must be an https page stating the fact, otherwise mark synthetic), but it largely restates the `source` and `synthetic` field descriptions and says nothing about duplicates, one-fact-per-call limits, 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?

It is a single sentence with the action front-loaded, but the construction "with the https page that states it, or synthetic: \"yes\" when made up for the plan" is grammatically tangled and takes a second read to parse.

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-fact append with a schema that covers most fields and an adequate safety annotation profile, the description supplies the key decision (real source URL vs synthetic). It is a bit thin on the builder-token/space-ownership precondition, but nothing critical to calling it correctly 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 description coverage is 80%, so the schema itself documents `fact`, `token`, `source`, and `synthetic`. The description reinforces the source-vs-synthetic choice but adds no syntax, format, or constraint detail beyond that; 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: "Add one fact to a Space you built." That is concrete enough to distinguish it from write-free siblings like fathom_find or fathom_forget, but it never contrasts with fathom_remember or fathom_space, which an agent could easily confuse with 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 implied by the conditional it carries (use it with an https source page, or mark synthetic when the fact is invented for the plan). There is no explicit when-not-to-use rule and no named alternative such as fathom_remember, so the routing decision is left partly 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 a non-read-only, open-world, non-destructive operation. The description adds useful context: the join requires prior consent and returns a token for activities_tick_choice and fathom_space. It does not describe error cases or side effects beyond joining, so it is good but not exhaustive.

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

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

Two tightly written sentences, with the consent condition and return value front-loaded. No wasted text.

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

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

There is no output schema, but the description explains the key return value (a token for two named tools). Parameters and preconditions are covered, though failure behavior and privacy side effects are not described.

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 three parameters are already well documented. The description reinforces the invite-link and consent semantics but adds little parameter detail beyond the schema.

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

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

States a specific verb (join) and resource (a builder's private Space) and scopes it to 'your person' via an invite link. This is specific enough to distinguish it from invite_links_create and activities_request_to_join.

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?

Clearly states the precondition 'only after your person said yes to joining' and ties use to an invite link. It does not explicitly name alternative tools or when not to use it, but the consent gating provides strong usage 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, destructiveHint:false and openWorldHint:false, so 'Read-only' merely restates structured data. The description adds no behavior beyond that — nothing on what happens with a malformed or unresolvable link, or how the three resource types differ in response.

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 action and its resource types. The trailing 'Read-only' is wasted space given the annotations already say so.

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 tool with full schema coverage and complete safety annotations needs little, but with no output schema the description should indicate what a read returns for each of the three link kinds. That gap leaves the agent guessing about response shape.

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 gives example link formats and the id fallback, so the schema does the heavy lifting. The description contributes one useful nuance — the link must be passed verbatim as the person holds it — but no additional format or validity guidance.

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 (read) plus the resolvable resource categories: proposal, join request, or the person's own memory. The 'by its link' framing distinguishes it from list/search siblings like fathom_find or fathom_space, though it never names those alternatives directly.

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?

'Given exactly as your person has it' implies the precondition (you must already hold a link) but never states when to prefer this over fathom_find, fathom_space, or fathom_remember. Usage is inferable rather than stated.

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

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

Annotations already declare readOnly/non-destructive/closed-world, and the description adds genuinely non-obvious behavioral requirements: relay attribution and unclaimed lines verbatim and keep each place's source link adjacent to its name. These are output-handling obligations the agent would otherwise miss. It stops short of explaining what a token does or how the cursor advances.

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, purpose front-loaded before the handling instructions, with no filler. The awkward 'from position since' phrasing costs a little clarity but nothing is padded.

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

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

With no output schema and zero schema descriptions, the description does reveal the shape of the return (attribution lines, unclaimed line, per-place source links), which is real value. But it omits pagination semantics, what 'token' is for, and what constitutes a 'run', leaving an agent under-equipped for anything past a first call.

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 0% and two of the three parameters ('run', 'since') have no type at all. The description only obliquely gestures at 'since' as a position and 'run' as a genesis run; 'token' is never mentioned, and no format or identifier shape is given for any parameter.

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+resource are specific: 'Read the places and activities a genesis run found', which no sibling tool claims. The scope qualifier 'from position since' is vague and 'genesis run' is never grounded, but the agent still knows what class of object is returned.

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 call this versus alternatives, no prerequisite (e.g. needing a run identifier from a genesis start), and no exclusion of related read tools like views_checks or places_verdicts. Pagination resumption is only implied by the phrase 'from position since'.

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 non-read-only, non-destructive, closed-world mutation, and the description adds that the resulting link is private and that name visibility is deferred until acceptance. That is genuine behavioral context, but the sentence about 'purpose and activity text' refers to fields that do not exist in this schema, so the guidance is hard to act on.

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 core purpose is front-loaded in a short first sentence, which is good. The second sentence is a long, winding caution referencing entities outside this tool's scope, costing clarity that the brevity gains.

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 mutation tool with no output schema and no parameter documentation, an agent still lacks the essentials: whether the link is returned in the response, whether the optional token should be supplied, and what permissions are required to create a link in a Space.

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 0% and the description only mentions 'Space', leaving the spaceId format and the meaning of the optional 'token' parameter (caller-supplied vs server-generated) entirely undocumented. With two parameters and zero schema text, the description needed to compensate and 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?

The opening clause gives a specific verb and resource: create a private invite link for a Space. It is clear what is produced, though no sibling invite-link tools exist to contrast against and the second sentence drifts into privacy advice rather than reinforcing the purpose.

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 use this versus alternatives, no prerequisite (e.g. membership or admin rights in the Space), and no indication of when a private link is preferred over other invitation flows such as activities_request_to_join or fathom_space_join. Only an indirect privacy admonition is present.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful output-behavior rules: attribution lines and an 'unclaimed' line must be relayed verbatim, and source links must stay attached to place names when passed on. It says nothing about auth/token requirements, result limits, or the shape of a returned place.

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 sentences, front-loaded with the core purpose before the output-relay rules, with little waste. The phrasing is conversational ('your person') but each sentence carries an actionable instruction.

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 four-parameter, open-world-flagged lookup with no output schema, the description should explain the access token, what 'interest' and 'limit' do, and roughly what a result contains. It covers only the query form and post-processing rules, so an agent cannot call it correctly without guessing at parameters.

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 0% across four parameters with no types or descriptions, so the description carries the full burden. It only implicitly covers 'town' via the query template; 'limit', 'interest', and especially 'token' (which appears to be an auth/access credential) are never mentioned, leaving an agent to guess.

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 concrete capability: answering 'where can I … in <town>' queries with sourced places, which tells an agent exactly what the tool returns (places plus source attributions). It does not differentiate from siblings such as fathom_find, capabilities_search, or places_verdicts, and the name 'knowledge_lens' is far broader than the places-lookup behavior described.

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 trigger condition is explicit and quoted: use this when the user asks a 'where can I … in <town>' question. That is a clear when-to-use signal. There is no guidance on when not to use it or which sibling to prefer for adjacent needs (general search, verdicts on places).

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, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds useful access-scope context by saying the answers are the person's 'own private' data. It does not mention authentication, rate limits, or what is returned, but with annotations covering safety, a 3 is appropriate.

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

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

The description is a single short sentence with no wasted words and the operation is front-loaded. However, it is under-specified rather than effectively concise: critical details about the token and the meaning of 'place answers' are omitted.

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?

The tool is simple (one parameter, no output schema, read-only annotations), but the description does not define 'place answers' or explain the token, leaving an agent with unresolved ambiguity before invocation. For a one-parameter read tool, a minimally complete description should at least identify the parameter's role.

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?

There is one parameter ('token') with 0% schema description coverage, and the description never explains what the token is or how it should be supplied. The phrase 'person's own' hints that the token may identify the person, but this is not made explicit.

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 has a verb ('Read') and a resource ('person's own private place answers'), so the basic operation is identifiable. However, 'place answers' is vague and does not clearly distinguish this tool from siblings like activities_answer or views_checks, nor does it explain what a 'verdict' is.

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 use this tool, when not to use it, or which sibling tool is the alternative. The only implied usage is that it reads the caller's own private answers, but no conditions or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so safety is covered structurally. The description's only added claim, 'safe synthetic lab boundary,' vaguely gestures at the environment but doesn't say what is described, whether the token is required for richer output, or what the response contains.

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 with no filler sentences or repetition. It is efficient, though the phrase 'safe synthetic lab boundary' is vague rather than informative.

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

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

With no output schema and an undocumented optional parameter, the description needed to explain what 'describe' returns and what the token does. It supplies neither, leaving the agent unable to predict the result or know whether to pass credentials.

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 schema has one optional 'token' parameter with 0% description coverage, and the description never mentions it or its purpose (auth? optional identity?). With low schema coverage the description was expected to compensate and 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 verb (describe) and resource (Fathom), so the basic action is inferable, but 'its safe synthetic lab boundary' is vague phrasing that doesn't clarify what information is actually returned. It also gives no signal to distinguish it from siblings like fathom_help, fathom_status, or fathom_space.

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

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

There is no indication of when to call this versus the many fathom_* siblings (fathom_help, fathom_status, fathom_space, fathom_space_context) or platform-level alternatives. The agent must guess from the name alone.

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 state this is non-read-only, open-world, and non-destructive. The description adds useful behavioral context: it proposes data-only kinds/predicates, returns a 'use X' outcome when one exists, and refuses person examples and person/role names. Auth and rate-limit details are absent, but the annotations lower that burden.

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 sentences with the purpose front-loaded and no filler. The second sentence is slightly dense but still concise and relevant.

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 an 8-parameter open-world proposal tool with no schema descriptions and no output schema, the description covers purpose and refusal behavior but leaves the parameter contracts and return behavior substantially unexplained. It is not complete enough to guide reliable 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?

There are 8 parameters with 0% schema description coverage, and the description does not define any of them. It only hints at constraints around examples and names, leaving use, token, parent, definition, differs_from, and identity_rule completely unexplained.

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, 'Propose,' and a clear resource, 'a data-only kind or predicate the knowledge layer lacks.' It also clarifies duplicate behavior ('answers "use X" when one exists') and refusal scope, though it does not explicitly name the sibling type_status.

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: call this when the knowledge layer lacks a kind or predicate, and expect refusal for people examples or person/role-named kinds. However, there is no explicit when-to-use versus alternatives such as type_status or the other propose_* siblings.

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 it as a non-destructive, non-open-world mutation, so the safety profile is covered. What's missing is anything the annotations can't say: what a "draft" state means, whether the space is immediately visible, what happens to the delegated principal's identity, or whether the call is idempotent. "Synthetic" is never explained.

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 well-formed sentence with no filler, which is structurally clean. But brevity here is the product of under-specification rather than economy — the sentence is short because it says almost nothing.

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 mutating create tool with four undocumented parameters, no output schema, and only baseline annotations, the description is far too thin. An agent would be guessing at both the effect and the argument values before calling it.

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?

Four parameters with 0% schema description coverage and the description mentions none of them. Required fields purpose and visibility, the private/unlisted/public enum meaning, and the roles of town and token are entirely undocumented anywhere.

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+resource pair ("Create a ... draft Space") is identifiable, but the qualifiers "synthetic" and "for the delegated principal" are internal jargon that don't clarify what kind of space results. It also gives no signal distinguishing it from siblings like spaces_get or spaces_list_public, which sit adjacent in the namespace.

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 use this over other space-related tools, no precondition (e.g., authentication or delegation requirement), and no exclusion criteria. The agent must infer everything 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral note – access is gated by visibility rules – but says nothing about what happens on denial, whether a token changes visibility, or what is returned. With annotations carrying the main burden, this partial addition lands at a 3.

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 with no padding. Its brevity is appropriate structurally, though the terseness contributes to gaps elsewhere rather than being a defect of structure itself.

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, no parameter descriptions, and no annotations beyond the safety hints, the description should explain the token parameter, what a visibility-gated failure looks like, and what a Space contains. None of that is present, leaving the agent under-equipped for a two-parameter 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 0% with two parameters, so the description carries the full burden and fails to. It never explains that spaceId is the required identifier or what the optional token parameter is for (auth? overriding visibility?). The parameter names alone are not sufficient 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?

"Read a Space" gives a specific verb and resource, which is better than restating the name. But the qualifier "when its visibility rules allow it" is vague and the description never distinguishes this from the many sibling readers like spaces_list_public or fathom_space. An agent knows roughly what it does but not how it relates to alternatives.

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

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

The only usage signal is the conditional clause about visibility rules, which doesn't tell the agent when to pick this over spaces_list_public or how to determine whether visibility actually allows the read. No exclusions, no prerequisites, no routing to siblings.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds the useful scoping detail that only public synthetic Spaces visible to the caller are returned, but says nothing about pagination, authentication requirements, or return format.

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

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

The description is a single front-loaded sentence with no wasted words. It immediately states the action and scope.

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 list tool, the description covers the core purpose and scope, and annotations handle safety. However, it leaves the sole parameter undocumented and provides no usage context, which is a meaningful gap even at low complexity.

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

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

There is one parameter, 'token', with 0% schema description coverage, and the description does not mention or explain it at all. The phrase 'visible to the caller' gives slight contextual hint about caller scoping, but does not clarify what the token is for or whether it is required.

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 ('List') and resource ('public synthetic Spaces'), with scope limited to what is visible to the caller. It distinguishes this from mutating siblings like spaces_create_draft, though it does not explicitly name alternatives such as spaces_get.

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 explains what the tool does but not when to use it versus alternatives, nor any exclusions or prerequisites. An agent can infer it is for listing public Spaces, but no explicit usage guidance is provided.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral detail beyond restating that it reads something; it does not explain what 'evidence' entails, whether lookups can fail, or how the token affects access.

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

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

The description is a single front-loaded sentence with no filler. It is appropriately sized for a sentence, though its brevity reflects under-specification rather than efficient completeness.

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 three undocumented parameters at 0% schema coverage and no output schema, the description should compensate with parameter and result semantics. Instead it offers one vague sentence and leaves the meaning of 'status' and 'evidence' undefined.

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 0% and all three parameters (name, class, token) are undocumented in the schema. The description mentions 'kind or predicate,' which vaguely hints at class/name, but it never explains any parameter, and the token parameter is completely unaddressed.

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 (Read) and a resource (a kind or predicate's status and evidence), so the general purpose is identifiable. However, 'kind' and 'predicate' are unexplained jargon, and the description does not differentiate this tool from siblings such as propose_type or capabilities_search.

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 use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer usage entirely from the name and one-line 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 say readOnlyHint=false, destructiveHint=false, openWorldHint=false, implying a non-destructive mutation, but the description adds nothing about side effects, whether checks are idempotent, what state they read or alter, or what 'steward checks' entail. It also doesn't explain the 'token' parameter's role, which matters for an authorization-sensitive operation.

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 efficient sentence with no bloat, but its brevity comes at the cost of substance — the one sentence leaves the essential mechanics unexplained rather than front-loading useful detail.

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 four-parameter, schema-coverage-zero tool with no output schema and mutation-style annotations, the description should explain what is checked, what the token is for, and what a result means. Virtually all of that 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 description coverage is 0% across four parameters (token, viewId, spaceId, version), and the description explains none of them. It doesn't even clarify that viewId/version are required or what 'version' refers to (schema version vs. trial iteration).

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 verb ('Run') and a resource ('steward checks for a view trial'), but 'steward checks' and 'view trial' are opaque domain jargon. It does not distinguish this from siblings such as views_list or views_propose, leaving the agent guessing what is actually being checked or produced.

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

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

There is no indication of when to call this versus views_propose or views_list, no stated preconditions (e.g., that a trial/version must exist first), and no mention of what happens after the checks run.

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 description's main contribution is the filtering rule: only approved views and the caller's own proposals are returned. It says nothing about ordering, pagination, or result shape.

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 with no wasted words. It is efficient, though its brevity contributes to the parameter gap rather than compensating for 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?

With annotations covering safety and no output schema required, the definition is adequate for a simple list tool. However, the unexplained token parameter and the absence of any result or pagination expectations leave it only minimally complete.

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?

There is one parameter ('token') with 0% schema description coverage, and the description never explains what it is or whether it is an auth credential versus a filter. This leaves a real gap the description should have closed.

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 ('List ... views') and narrows scope to approved views plus the caller's own proposed views. It does not explicitly differentiate itself from siblings like views_propose or views_checks, so it stops 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 scope clause implies when to use it (to see approved views and one's own proposals), but there is no explicit when-not guidance and no named alternative such as views_propose for submitting a proposal.

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 state that this is a non-read-only, non-destructive, open-world operation, so the safety profile is largely covered. The description adds that proposals are 'bounded' and go to 'steward review,' which is useful behavioral context, but it does not explain what happens on success, whether the proposal is persisted, or what the token does.

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

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

The description is a single front-loaded sentence with no wasted words. Its brevity is efficient, though for a proposal tool with undocumented parameters it may be too terse to be fully useful.

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-parameter tool with an unstructured required 'view' object, an undocumented token, no output schema, and only partial annotation context, the description leaves significant gaps. It conveys the high-level purpose but not enough detail for an agent to call it confidently.

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 0%, so the description must compensate for undocumented parameters. It partially explains the 'view' concept as a bounded synthetic-place view, but gives no expected structure or format, and it does not mention the 'token' parameter at all.

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 ('Propose') and resource ('bounded synthetic-place view'), plus the intended audience ('steward review'). It does not explicitly differentiate itself from siblings like views_list or views_checks, but the action and object are clear enough to identify the tool's role.

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 steward review' hints at the tool's place in a review workflow, but it does not say when an agent should choose it over views_checks, views_list, or other proposal-style siblings. There are no explicit preconditions, exclusions, or alternative-tool guidance.

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