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

Annotations already declare the tool read-only and non-destructive. The description adds useful context about the dedicated Chrome instance and what status reports, but it does not disclose side effects or return behavior of open_login, such as whether it opens a new browser page or returns immediately.

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 one compact sentence, front-loaded with the tool's domain and then covering both action options. Every clause earns its place and there is no redundant restating of schema information.

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

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

For a single-parameter enum tool with read-only annotations and no output schema, this description is largely sufficient. It explains both actions and their purposes, but it could be more complete by clarifying what open_login returns or how the status result identifies the user.

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 provides only an enum with no per-value descriptions (coverage 0%). The description fully compensates by explaining both allowed values: status checks login state and user identity, while open_login opens the sign-in page. An agent can select the correct action without additional inference.

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 identifies the tool's domain (FamilySearch login session) and gives each action a concrete behavior: status reports signed-in state and user identity, open_login opens the sign-in page. This is clear, though the overall purpose is expressed through the action descriptions rather than a single overarching verb+resource phrase.

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 action descriptions provide clear situational guidance: use status to check whether the dedicated Chrome is signed in, and use open_login to start the sign-in flow. It does not explicitly contrast with sibling tools like raw_request, but the dedicated-Chrome session scope makes the intended context reasonably clear.

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

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

The annotations already flag the tool as non-read-only and destructive, and the description adds useful behavioral detail beyond that: download can write to outPath or return base64, upload moves a local file into memories, and delete removes a memory. It does not contradict the annotations.

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

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

The description is intentionally compact and front-loads the resource type before the action list. The dot-separated action markup packs a great deal of information into one sentence, though the 'then attach' wording inside upload is slightly ambiguous and the dense punctuation requires careful parsing.

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 seven actions, ten parameters, no output schema, and no return-value descriptions, the definition is not complete enough for safe invocation. The agent does not learn which parameters are required per action, what enum values mean in context, how pagination works, or what each action 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 only 20%, so the description must compensate for many undocumented parameters, but it only clarifies outPath, memoryId, and personId indirectly per action. Parameters like count, start, title, description, filePath, and personName are left unexplained, leaving the agent to guess which action each belongs to and what values are expected.

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

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

The description states the resource ('Memories (photos, documents)') and enumerates seven concrete actions with verbs and objects: list_person, list_mine, get, download, upload, attach, and delete. This makes the tool's purpose unambiguous and differentiates it from sibling tools like note or person, even without detailed prose.

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

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

The context 'Memories (photos, documents)' and action list imply when the tool is relevant, but the description never explicitly says when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The usage guidance is present only by implication, not by direct instruction.

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 flag destructiveHint=true, and the description aligns by listing the delete action. However, the description does not go beyond the action list to explain side effects, prerequisites, or behaviors like requiring personId for certain actions. It adds minimal contextual value beyond what annotations and schema already provide.

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 sentence that front-loads the purpose and presents a compact action list. There is no filler or redundancy; it is extremely 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?

With 6 parameters, no output schema, and low schema documentation, the description is only minimally sufficient. It lists actions and some parameter hints, but it does not specify required parameters per action (e.g., list likely needs personId), nor does it mention changeMessage. An agent may struggle to correctly invoke the tool without additional context or examples.

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 17% (only personId is described), so the description must compensate. It partially does by mapping actions to parameters: 'add (subject + text)' and 'delete (noteId)'. However, it does not explain the meaning of subject/text, nor does it clarify parameter requirements for list or the changeMessage field. The compensation is incomplete given the low schema coverage.

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

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

The description clearly states the tool's resource ('Notes on a Family Tree person') and enumerates three concrete actions (list, add, delete), which distinguishes it from sibling tools like person or relationship. The scope is specific and unambiguous.

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

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

The description implies usage by identifying the resource and actions, but it does not explicitly contrast with sibling tools or state when not to use this tool. There are no alternative routing criteria or exclusions, leaving the agent to infer when this is the right 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 mark the tool as destructive, and the description goes well beyond that: it warns that edits are public and attributed, that living people created by the user are private, that non-standardized dates/places get flagged, and that delete only works on people the user created. This adds meaningful behavioral context not inferable from annotations or schema.

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

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

The description is dense but well-organized as a compact action list with parentheticals, making ten actions scannable. It front-loads the most important operational warning about public, attributed edits and change reasons. It is long, but given the multi-action surface area, very little is wasted.

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

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

For a complex 30-parameter, multi-action tool with no output schema, the description covers action semantics, search syntax, edit conventions, and privacy/destructive behavior thoroughly. It does not detail response shapes or pagination/offset behavior, which remains a meaningful gap, but the description is complete enough for correct action selection and invocation in most cases.

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 only about 10% schema description coverage, the description does substantial compensating work: it explains fact id semantics for updates, formalDate/placeId standardization requirements, wildcard behaviors for name search, the records flag for matches, and the sources flag for get. Some parameters remain under-described (count, offset, includeSources, spouse-like fields), but the key behavioral parameters receive solid treatment.

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

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

The description clearly identifies the resource (people in the FamilySearch Family Tree) and enumerates the specific actions available: get, search, ancestry, descendancy, changes, matches, create, update, delete_conclusion, and delete. It also distinguishes itself from sibling tools by explicitly deferring to relationship.create for connecting people and place.search for place lookups.

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

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

The description gives explicit usage conditions for each action: create is for unconnected persons, connect via relationship.create; updates with a fact id edit while without id they add; matches may return record hints; delete requires a reason. It also states a global rule that public, attributed edits always need a changeMessage/reason, which is exactly the kind of context an agent needs to invoke the tool safely.

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, and the description is consistent with that. It adds useful behavioral context about results (place ids, jurisdictions, coordinates, description), but does not mention limitations, pagination, or other runtime behavior.

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

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

The description is compact and front-loads the core concept before enumerating actions. The use of an arrow notation for search mapping is efficient, though a slightly more structured format could improve scannability.

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 primary use cases and return value hints, which is helpful given no output schema. But it omits the 'count' parameter and does not describe any edge cases or constraints, leaving the tool incompletely specified for an agent.

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 0% schema coverage, the description must clarify parameter meaning, and it does for action, query (as 'name'), and placeId. However, the 'count' parameter is entirely undocumented, leaving one of four parameters 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 clearly identifies the resource as 'places' and specifies two concrete actions, 'search' and 'get', with their input-to-output mappings. This distinguishes it from general-purpose siblings, though it does not explicitly name or contrast any sibling 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?

The description implies when to use each action: 'search' by name and 'get' by id. However, it provides no explicit guidance on when to choose this tool over sibling tools like 'person', 'relationship', or 'source'.

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 discloses use of the session bearer token, the default Accept format, and the viaSite behavior, adding meaningful context beyond the annotations. DestructiveHint already signals potential harmful operations, and the description does not contradict it, but it omits any caution about arbitrary POST/DELETE requests or response/error behavior.

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 dense sentences with no filler: the escape-hatch identity is front-loaded, and the route-specific exception for viaSite follows naturally. Every clause earns its place.

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 raw passthrough tool with no output schema and a destructive hint, the description gives enough to make a first call but omits response format, error behavior, and an explicit warning about mutating endpoints. The sibling context clarifies its role as the generic fallback, which helps, but the gaps remain notable.

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 17%, yet the description partially compensates by specifying the path pattern and default Accept header. The viaSite parameter is also explained in the schema. However, jsonBody, contentType, method, and accept are left largely to their names or enum values, so the semantics are not fully fleshed out.

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

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

The description clearly identifies a raw, escape-hatch HTTP request tool for FamilySearch, with a concrete path example and default Accept header. It is distinguishable from the specialized siblings as a generic fallback, though 'any FamilySearch platform request' is broad and could be more explicit about its boundaries.

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?

'Escape hatch' conveys that this is the fallback when no domain-specific tool applies, and the viaSite guidance gives a concrete routing instruction for a specific class of endpoints. It does not explicitly name sibling alternatives or state when not to use it, but the context signals are sufficient for an agent to decide.

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, and the description adds substantial behavioral detail beyond that: fuzzy-by-default matching, wildcard rules, facet return format, extraParams pass-back, image download output options (outPath/base64, maxWidth), and get's full-record semantics. No contradictions with annotations.

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

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

The description is dense but organized by action with semicolon-separated clauses. It front-loads the resource identity and leads with the primary action (search). Though long, each clause contributes meaningful detail; minor formatting improvements (bullets per action) could enhance scannability, but nothing is redundant.

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 43 parameters, four actions, and no output schema, the description is unusually thorough: it covers search semantics, fuzzy matching, wildcard syntax, pagination, facets, image download options, and the citation workflow. Small gaps remain, such as date formats and explicit return structure, but overall an agent has enough context to call the tool correctly.

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

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

Schema description coverage is only 19%, so the description carries the burden of explaining parameters. It compensates by defining exactFields, facets, extraParams, collectionType, offset/count, recordId, outPath, maxWidth, and by stating the general rule that every field is fuzzy unless listed in exactFields. It does not individually document all 43 params, but it gives enough collective semantics to make most of them actionable.

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 opens with 'FamilySearch historical records' and enumerates four distinct actions (search, get, download_image, collections), each with a specific resource and purpose. It clearly differentiates this tool from siblings like person, source, and place by naming the exact resource domain and action set.

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 provides extensive usage context: how to perform search, when to use exactFields vs fuzzy matching, how facets feed extraParams, and how to page with offset/count. It also routes citation workflow to source.create and source.attach. However, it doesn't explicitly state when not to use this tool in favor of siblings like raw_request or note.

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

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

Annotations already carry readOnlyHint=false and destructiveHint=true, and the description is consistent with these: it lists delete actions and adds that they 'need reason', which is useful behavioral context beyond the structured fields. It does not contradict the annotations, but it stops there — no mention of consequences of deletion, idempotency, or permission requirements, so it meets but does not exceed the lowered bar.

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 information-dense paragraph, front-loaded with the domain phrase 'Family Tree relationships' followed by a compact action list using dot separators — every clause earns its place. It is slightly wall-of-text dense, but there is no filler and the structure effectively packages six actions plus parameter hints.

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 6-action, 12-parameter dispatch tool with no output schema, the description covers the core action semantics and key constraints (required params per action, lineage types, delete reason) but leaves notable gaps: changeMessage is undocumented, the facts array structure is only glossed as 'optional marriage facts', and get actions give no hint of what they return. Adequate for basic invocation, incomplete for full agent autonomy.

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 schema description coverage at 0% across 12 top-level parameters, the description carries the full burden, and it compensates well: it maps person1/person2 to create_couple, child/parent1/parent2 to create_child_parents, relationshipId to the get actions, reason to deletes, and enumerates the lineage enum values (BiologicalParent/AdoptiveParent/StepParent/FosterParent/GuardianParent). It does not cover every parameter (changeMessage is absent), but the action-to-parameter mapping adds substantial meaning the bare schema lacks.

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

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

The description states the resource ('Family Tree relationships') and enumerates six specific verb+resource actions (create_couple, create_child_parents, get_couple, get_child_parents, delete_couple, delete_child_parents), so an agent knows exactly what the tool operates on. However, it never distinguishes itself from the sibling 'person' tool, which is a natural alternative for family-tree data, so it misses the sibling-differentiation tier.

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

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

Usage context is implied rather than explicit: the action list with its parameter hints shows which parameters are needed per action, and 'from person.get' hints at a workflow for obtaining relationship IDs. But it never states when to prefer this tool over siblings like 'person' or 'record', and gives no exclusions or alternative routing, so the guidance stays at the implied level.

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=trueable, and the description reinforces this by listing delete_description and detach actions. It adds useful conceptual context about Source Box, source references, and tags, but it does not disclose effects like permanent deletion, permissions, or side effects. No contradiction with annotations.

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

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

The description is compact and front-loaded, opening with the core concept and then listing actions in a compressed notation. The two-sentence structure plus action enumeration is dense but efficient, with no redundant filler.

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

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

With 12 parameters, 7 actions, no output schema, and destructive annotations, the tool is complex enough to require more context. While the action list gives partial parameter mappings, it omits expected return values, per-action required fields for actions like get and create, and behavioral caveats such as irreversibility or authorization needs.

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 25%, so the description carries extra weight. It adds meaningful semantics for tags ('fact types this source supports') and about ('URL/ark'), and maps some parameters to actions. However, it does not clarify note, count, start, or changeMessage, leaving four parameters effectively 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 clearly identifies the resource: FamilySearch sources, source descriptions, and source references. It then enumerates the specific actions available (list_person, source_box, create, get, delete_description, attach, detach), making the tool's purpose and scope unambiguous even as a dispatcher-style 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?

The description provides implied usage context through the action list and parenthetical parameter hints, e.g., 'attach (personId + descriptionId + tags)'. However, it never explicitly states when to choose this tool over sibling tools like record or raw_request, nor does it exclude any alternatives.

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