Dayze — Life Context

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

Beyond annotations (readOnly=false, destructive=false), the description discloses the $0.10 cost and API-key requirement, which are useful operational constraints. It does not discuss duplicate handling or creation side effects, but the schema covers idempotency keys.

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 the purpose first and cost/auth appended compactly. No filler or repetition.

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 create-style tool with an output schema and documented idempotency parameters, the description covers the main purpose and operational prerequisites. It could mention duplicate behavior or when to use update instead, but these lacks are minor.

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 67%, so the schema already explains request_id and idempotency_key. The description adds little parameter-specific meaning; 'owned object' only weakly implies that name identifies the object being added.

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

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

The description uses a specific verb ('Add') and resource ('an owned object to Life Inventory'), making the core function clear. It does not expressly contrast itself with sibling add_inventory_valuation, but the 'item' vs 'valuation' distinction is inferable from name and wording.

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 is given on when to choose this tool over alternatives such as update_inventory_item, archive_inventory_item, or add_inventory_valuation, and no exclusions or prerequisites are stated beyond the API key requirement.

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 adds meaningful behavioral context beyond the annotations: the operation appends an immutable observation, costs $0.10, and requires an API key. Annotations already indicate it is a write operation, but the description usefully discloses immutability and cost.

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 extremely concise and front-loaded with the action. The parenthetical cost and API key requirement earn their place without adding fluff. Every word contributes meaning.

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

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

For a simple append operation, the description covers the essential behavioral facts: immutability, cost, and authentication. However, it is incomplete as a standalone guide because it omits usage context and leaves the core parameters (value, currency, inventory_id) semantically under-specified despite low schema coverage.

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 40%, and the description does not explain value, currency, or inventory_id. The phrase 'valuation observation' hints at the meaning of value, but the description does not compensate for the missing parameter documentation, especially for required fields like inventory_id and the optional currency format.

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 the specific verb 'Append' and the resource 'valuation observation', making the core operation clear. The word 'immutable' also implicitly distinguishes it from update/delete tools, though it does not explicitly name sibling tools or state what it is not.

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 no guidance on when to use this tool versus siblings like get_inventory_valuations, update_inventory_item, or add_inventory_item. It mentions API key and cost, which are prerequisites, but gives no context about when this tool is the right choice or when an alternative should 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?

The description adds meaningful behavioral context beyond the destructiveHint=true annotation by clarifying that this is a soft-delete: it sets archived_at and preserves original rows for versioning. This materially reduces the risk of an agent assuming permanent destruction. It also mentions the cost and API key requirement, adding operational transparency.

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. The core action and state change come first, followed by the preservation behavior and then operational prerequisites. Every sentence earns its place with no 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?

The tool's purpose, effect, cost, auth requirement, and non-destructive nature are all covered. The main omission is the return value or response shape, especially since no output schema is provided, but for a simple soft-delete operation the provided context is otherwise sufficient.

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 67%, with request_id and idempotency_key already described in the schema. The description itself does not add parameter-level detail, but asset_id is self-explanatory given 'archive an asset.' The description does not compensate for the undocumented asset_id semantics, but the gap is minor.

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 action: 'Soft-delete an asset (sets archived_at).' This is a specific verb plus resource, and it distinguishes the tool from related siblings like upload_asset and update_asset by clarifying the archive semantics.

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 usage context is implied through the 'soft-delete' and 'archive' language, so an agent can infer when to use it. However, it does not explicitly state when not to use it or mention alternatives such as update_asset, upload_asset, or a hard-delete path.

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 indicate readOnlyHint=false and destructiveHint=true, so the description correctly aligns with a mutating, destructive-intent operation. The description adds important context: the operation is non-destructive in terms of data loss ('archive instead of destructive delete'), there is a $0.10 monetary cost, and an API key is required. Ironically, the annotation destructiveHint=true may mean the operation is considered destructive (e.g., it removes the item from active lists), but the description clarifies it is not a permanent delete. The description adds value beyond annotations by disclosing cost and authentication requirements.

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 extremely concise: one sentence with three useful clauses: the operation type, the cost, and the auth requirement. It front-loads the most important behavioral distinction ('Archive instead of destructive delete'). It could be slightly more structured (e.g., separate cost and auth into a second sentence), but it earns every word and has no wasted content.

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 an output schema, 4 parameters, and destructiveHint=true, the description is minimally adequate: it tells the agent this is an archival operation with cost and auth requirements. But it doesn't explain the meaning of reason, what happens to the archived item (e.g., is it still visible in get_inventory?), or how retries work with idempotency keys (though the schema documents retries). Given the output schema exists, return values don't need explanation, but the behavioral consequence of archiving is left partially inferred.

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 50%, with documented parameters being request_id and idempotency_key. The description does not explain inventory_id or reason beyond the schema's basic type declarations. However, the description's 'Archive instead of destructive delete' implies inventory_id is the target item, and reason is presumably an audit/archive reason. Baseline 3 is appropriate because the schema covers half the parameters and the description partially compensates by clarifying the operation's nature, but it doesn't add specific meaning to the 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 uses 'Archive instead of destructive delete' which clearly indicates the operation is a non-destructive archival action on an inventory item. It distinguishes itself from delete operations by emphasizing it is not destructive, though it doesn't name a specific sibling alternative like delete_event or delete_food. The related get_inventory_item, update_inventory_item, and add_inventory_item siblings help contextualize it, but the primary behavior (archive an inventory item) 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 'instead of destructive delete' phrase provides an implicit usage guideline: use this when you want to remove an inventory item from active use without permanently destroying it. However, it does not explicitly state when to use this over update_inventory_item (e.g., when the item should be retired) or contrast with alternative archive tools like archive_asset, nor does it mention the $0.10 cost as a decision factor. This is adequate but relies on 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 are minimal, so the description carries the burden. It discloses the key side effect: it creates a linked copy rather than moving the original row. It also adds legacy URL behavior, role values, cost, and API-key requirements. It does not describe failure modes or output behavior, but the core semantics are clearly stated.

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 well-front-loaded. The first sentence delivers the operation and its main caveat, followed by compact role and legacy/cost information. Every sentence contributes practical information, though the role list is partially redundant with the schema.

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

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

Given the tool has 9 parameters, nested objects, and low schema coverage, the description is only minimally sufficient. It explains the main operation and one parameter relationship but leaves key invocation details—entity_type/entity_id allowed values, metadata/asset_type semantics, and URL vs. asset_id precedence—incompletely specified. The output schema helps, but the overall context is not fully self-contained.

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 33% schema description coverage, the description must compensate for undocumented parameters. It does explain asset_id vs. URL legacy behavior and role values briefly, but entity_type, entity_id, metadata, asset_type, and idempotency behavior are left under-explained. It also omits a valid schema enum value, 'photo', from its Roles list.

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 starts with an explicit verb and resource: 'Link an existing asset_id to another entity by creating a linked copy.' This is clearly distinct from upload_asset, update_asset, and archive_asset, and the clarifying clause 'does not move the original row' removes ambiguity about whether this is a move operation.

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 provides clear context for the intended use: linking an existing asset to an entity, creating a linked copy, and supporting a legacy URL path. It also notes API key and cost requirements. It stops short of explicitly saying when not to use this tool or naming upload/update/archive as alternatives, so it is not fully 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 indicate this is not a read-only operation (readOnlyHint=faalse). The description adds cost ('$0.05') and authentication ('API key required'), which are useful semantics beyond the annotations. However, it does not explain side effects such as whether the action is reversible, how many items are affected, or the exact criteria for 'non-person / typed junk'.

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 sentence plus a parenthetical is extremely concise and front-loaded: the core action and scope are stated first, then cost and auth requirements. 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?

The tool has no required parameters and four optional ones, but the description leaves the meaning of 'bulk' and the valid inputs (reason, entity_type) ambiguous. It also does not say how it differs from the per-item dismiss_clarification. The presence of an output schema helps with return values, but an agent still lacks enough context to construct a correct call 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 covers 50% of parameters: request_id and idempotency_key are described; reason and entity_type are bare strings. The tool description does not clarify what values reason or entity_type should accept, and the phrase 'typed junk' only loosely hints at entity_type's role. It does not compensate for the schema gaps.

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 ('Dismiss') and resource ('the clarification queue') with a clear scope: non-person / typed junk. The 'bulk' in the tool name and this qualifier distinguish it from the sibling 'dismiss_clarification', which presumably handles a single item.

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 like dismiss_clarification or resolve_clarification. The use case is implied ('dismiss non-person / typed junk') but no explicit conditions, prerequisites, or exclusions are given.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses three behavioral traits the structured fields do not: the feature flag is off by default, an API key is required, and each call costs $0.10. That is exactly the kind of operational context annotations cannot convey, though it omits whether a commit is reversible.

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

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

Two tight fragments with parenthetical qualifiers — the gating facts (flag, cost, auth) are front-loaded and nothing is padded. The telegraphic style borders on cryptic, but no sentence 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?

An output schema exists, so return values need not be described, and the cost/flag/auth profile is covered. Still missing for a write/commit tool: whether the operation is idempotent or reversible, and what payload_hash must match — a material gap given three required parameters with no schema documentation.

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, and the description only gestures at two of them (payload_hash, owner_session_id) without explaining format, provenance, or purpose. proposal_id, request_id, and idempotency_key are left entirely undocumented in both the schema and 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?

It names a specific action ('Owner approve+commit') and the key credentials involved (payload_hash, owner_session_id), which implies it finalizes a proposal created by propose_life_update. But 'life update' is never defined and the verb phrase 'approve+commit' is compressed jargon, so an agent must infer the resource being mutated.

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?

'flagged; off by default' and 'API key required' give real gating conditions for when this call is permitted. However, it never names propose_life_update as the prerequisite step or explains when an owner should choose to commit versus leave a proposal pending.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so no contradiction exists. The description adds useful behavioral context beyond the annotations: it packages what would be two notable_pack calls into one, notes the timeline format, and discloses the $0.08 cost.

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 concise semantic units in one sentence: what it returns, why it is preferable to calling notable_pack twice, and a concrete example. No filler words or redundant restatements.

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-only tool with only two required parameters, the description plus the input schema and annotations gives an agent everything needed to call it correctly. It also includes enough comparison-specific context to choose this over notable_pack, and the cost and timeline details remove the main remaining unknowns.

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?

slug_a and slug_b have schema descriptions, and the example reinforces what a slug looks like. However, the description adds nothing about date, peers, or similar, and peers/similar are not described in the schema either, so the 40% schema-description gap is left uncompensated.

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 clear operation: produce side-by-side notable packs for two slugs. It names the resource (notable packs with life_in_days + day_number timelines) and explicitly differentiates itself from notable_pack by noting it replaces two calls. The elon-musk vs steve-jobs example grounds the abstraction.

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 names notable_pack as the alternative and frames compare_lives as the one-call version for comparing two people. It doesn't give formal when-not conditions, but the intended context is clear enough for an agent to decide when to pick this over a single notable_pack call.

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

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

Beyond the annotations, it discloses a duplicate check, a $0.10 cost, and an API key requirement. It does not specify the outcome when a duplicate is found (error vs no-op), but still adds material behavioral context not present in 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?

One efficient sentence with essential business constraints appended parenthetically. The main action is front-loaded, and every clause adds value.

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

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

Output schema covers return values and annotations cover basic mutability, so the description need not explain those. However, it omits what happens on duplicate detection and does not clarify parameter semantics (especially tier/relationship), leaving moderate gaps for an agent to hit errors on alternative paths.

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 22% (just request_id/idempotency_key), and the description lists no parameter details. An agent must infer the meaning of tier, relationship, and aliases from names alone, which is risky for a 9-parameter creation 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 'Add' and resource 'CRM contact', and adds unique behavioral cue 'checks duplicates first'. This clearly distinguishes it from update_person, merge_people, and read-only lookup siblings.

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 clearly frames the tool as the way to create a new CRM contact, and the duplicate-check note implies it is the entry point before considering update or merge operations. It does not explicitly name alternatives or exclusion conditions, but the context is sufficient for an agent to select it for creation.

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 non-read/non-destructive profile, so the bar is lower. The description adds genuinely useful context: idempotency behavior ('Idempotent by name or idempotency_key'), a cost signal ($0.10), and an auth requirement (API key required) — all 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?

Two compact sentences with the primary purpose front-loaded, then behavioral constraints. Efficient; slight density of parenthetical signals but no wasted sentences.

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?

Output schema exists so return values need not be explained, and annotations cover the safety profile. However, for a 21-param creation tool with 29% schema coverage, the description omits many parameter semantics and gives no explicit relationship to siblings like update_place or resolve_place.

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 29%, and the description only names a handful of fields (address, opening_hours, affordability, notes, tags) out of 21 params. It doesn't clarify the alias relationships (hours↔opening_hours, price_level↔affordability) that the schema does document, leaving substantial gaps the description does not compensate for.

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 ('Save a venue card') and enumerates the fields it holds (address, opening_hours, affordability, notes, tags). It is clearly a creation tool distinct from get_place/get_places/update_place siblings, but it does not explicitly name those siblings the way a 5 would.

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 clause 'does not create calendar notes' implies when-not usage by exclusion, but there is no explicit guidance on when to use create_place versus resolve_place or enrich_place_from_google. Usage is only implied.

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 destructiveHint=true and readOnlyHint=false, and the description adds substantial behavioral detail: event_people tags cascade, linked entity_assets are archived, replicated food rows are deleted, life_state is rebuilt, and auth/cost constraints are stated. This goes well beyond what annotations alone 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 dense but every clause adds value: mutation message, required parameter, failure mode, cascade effects, sibling routing, system rebuild, auth requirements, and cost. The most important operational facts are front-loaded at the beginning.

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 tool with cascading side effects, the description covers the required parameter, ownership validation, error behavior, side effects, routing to delete_food, auth scope, and cost. An output schema exists and describes return values, so the description is sufficiently complete for an agent to select and invoke 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 100%, so the schema already documents event_id as a UUID of an owned calendar event and documents request_id and idempotency_key fully. The description mostly restates that event_id is required and adds error behavior rather than new parameter meaning, 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 states a specific verb and resource: 'removing one existing calendar event the authenticated user owns.' It clearly distinguishes delete_event from sibling tools like delete_food and update_event by focusing on owned calendar events and noting the food-diary special case.

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 explicitly says 'For food-diary meals, prefer delete_food,' naming the alternative and the condition that redirects usage. It also sets boundaries by stating unknown or other-user event_ids return an error, and that share tokens cannot write, which clarifies when this tool is not appropriate.

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 destructiveHint=true, and the description adds substantial behavior: it removes the mirrored calendar event, rebuilds life_state, returns an error for unknown/other-user food_id, and notes that share tokens cannot write. This goes far beyond the annotations, no contradictions.

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?

Every sentence earns its place: the mutating effect, required param, sibling routing, error behavior, side effect, auth requirements, and cost. Front-loaded with 'MUTATES' and sized appropriately for the information density.

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 purpose, target, side effects, error conditions, auth, and cost. With output schema present, return values need no explanation. Complete for a destructive single-object deletion tool with 3 parameters and rich annotations.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates that food_id is required and is a UUID, but adds no extra semantics for request_id or idempotency_key beyond what the schema already provides. It is adequate but not additive.

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 ('removing'), resource ('Food Diary row'), ownership scope ('the authenticated user owns'), and the mirrored calendar event side effect. The title and description together make it clear this is the food-diary deletion tool, and it explicitly differentiates from delete_event via the 'prefer this over delete_event' note.

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

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

Explicitly names the alternative (delete_event) and provides the condition for choosing this tool ('for meals logged via log_food'). Also states error conditions for unknown/other-user food_id and gives auth prerequisites, which helps the agent decide when this tool is appropriate.

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

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

The description goes beyond the annotations by disclosing the API key requirement and the $0.05 cost. It does not contradict the annotations, but it also does not explain the effect of dismissal, whether it is reversible, or what happens to the entity afterward.

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 compact sentence that front-loads the core action and adds only the essential cost/auth caveat. It is appropriately sized, though a bit more context about related tools would improve it without bloating 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?

Given the annotations and output schema, the description is mostly adequate for a simple dismissal action, but it leaves gaps around when to use bulk vs single dismissal and what the optional reason parameter is for. The presence of an output schema means return values need not be explained, but alternative routing is missing.

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

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

Schema description coverage is 50%, covering request_id and idempotency_key, but the required clarification_id and the optional reason are undocumented in the schema. The description does not explain how to supply or format any parameter, so it adds little beyond the tool name and schema.

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

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

The description clearly states the action ('Dismiss'), the resource ('pending entity clarification'), and gives a concrete example type ('not_person'). It is distinguishable from siblings like resolve_clarification and bulk_dismiss_clarifications, though it does not explicitly name them.

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 about when to choose this tool over the related bulk_dismiss_clarifications or resolve_clarification siblings. The phrase 'pending entity clarification' implies when it is applicable, but the description does not state exclusions or alternatives.

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

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

Annotations cover the safety basics (readOnlyHint=false, destructiveHint=false), and the description adds genuinely new behavioral context: the default non-overwrite policy, a $0.15 per-call cost, and an API-key requirement. It does not describe rate limiting, failure modes when Google has no match, or interaction between place_id and business_contact_id; note also that openWorldHint=false sits uneasily with a documented external Google API dependency.

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

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

Three tight clauses: what it fills, the non-overwrite default, and the cost/auth note. Nothing is redundant, though the parenthetical field list and price note are packed densely into one sentence rather than separated for scanning.

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

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

An output schema exists, so return values need not be described. However, with five parameters and zero required, the definition should say which identifier (place_id or business_contact_id) the caller must supply and what happens if neither is given; that gap leaves the agent unable to construct a valid call from the description alone.

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 40% (request_id and idempotency_key are documented; place_id, fill_empty_only, business_contact_id are not). The description compensates partially by stating the default for fill_empty_only, but it never explains the role of place_id versus business_contact_id or whether either 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 names a specific verb and resource ('enrich ... saved place card') plus the fields it fills (hours/address/phone/website) and the external source (Google Places). This clearly separates it from sibling mutators like update_place, which edit a place card without an external data source.

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

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

It gives clear context for use: it is 'optional', defaults to non-overwriting behavior ('fill_empty_only — does not overwrite agent-supplied fields'), and carries a cost/auth requirement. It does not explicitly name alternative tools (e.g., update_place) or state when to prefer manual editing, so it stops short of full when/when-not 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?

Beyond the readOnlyHint annotation, the description discloses the source lookup order, the API-key requirement, the $0.10 cost, and an important integrity constraint against inventing sources. This adds substantial behavioral context that the annotations alone do not 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 three short sentences: function, usage guidance, and cost/auth. Every sentence earns its place, and the most important information is front-loaded.

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

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

Given the output schema exists and annotations cover safety, the description provides everything else an agent needs: the provenance strategy, when to invoke it, and operational constraints like API key and cost. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the input schema already documents all parameters well. The description reinforces the notion of a 'claim' but does not add significant additional parameter semantics beyond what the schema provides.

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 starts with a specific verb and resource: 'Return evidence/provenance for a claim.' It goes further by naming the exact source types to consult and their precedence, which clearly distinguishes this tool from siblings like get_memories or get_life_graph.

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 trigger condition ('Use when the agent must cite why it believes something') and a clear negative behavior ('do not invent sources'). However, it does not explicitly name alternative tools or describe when NOT to use this tool beyond that one negative 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?

Annotations already signal read-only safety, and the description adds meaningful behavioral context: the operation costs $0.05 and requires an API key, which is beyond the structured annotations. It also discloses that the output can include a signed_url for download/processing, clarifying a key behavioral detail not present in the schema. No contradiction with 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 a compact two-sentence definition with no filler. The primary action and resource are front-loaded, and the cost/api-key caveat is appended economically without disrupting the core message.

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

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

Given the low parameter count and existing output schema, the description provides the key context needed to call the tool: what it returns, the lookup method, cost, and authentication requirement. It falls slightly short only because it does not clarify the include_signed_url parameter's behavior, which is important for accurate 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?

With schema description coverage at 0%, the description must carry parameter meaning, but it only explicitly mentions asset_id and the concept of a signed_url. The optional boolean include_signed_url is not named or explained, leaving its effect ambiguous. This is a notable gap for an otherwise simple two-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 uses a specific verb ('Fetch'), a clear resource ('one asset'), and the lookup key ('asset_id'), making the tool's core purpose unambiguous. It also states the return context ('signed_url for download/processing'), distinguishing it from sibling list-type tools like get_entity_assets or update-oriented tools like update_asset.

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 'Fetch one asset by asset_id' gives a clear and direct when-to-use scenario: retrieve a single asset when you have its ID. It also adds practical usage conditions, noting the $0.05 cost and API key requirement. However, it does not explicitly name alternatives or exclusion cases, such as when to use get_entity_assets instead.

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 indicate read-only, non-destructive behavior, so the description does not need to restate that. It adds useful context: API key required, a $0.10 cost, and restriction to completed trips. It does not explain canonicalization behavior or result shape, but the output schema covers returns.

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 extremely compact, front-loads the purpose, and adds only high-value operational notes (cost and API key). No filler or redundant restatement of the tool name exists.

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 output schema exists, so return value documentation is not needed. However, with 0% parameter coverage, no usage guidance, and no explanation of 'to'/'from', the description is not complete enough for an agent to invoke the tool correctly in all 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?

Schema description coverage is 0%, and the 'to' and 'from' parameters have no descriptions. The description does not clarify whether these are dates, place identifiers, or some other range, so an agent cannot reliably determine parameter format or 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?

The description names a specific resource ('canonical cities') and the source domain ('completed trips'), and the tool name reinforces the action. It does not explicitly contrast with siblings like get_countries_visited or get_travel_history, but the core purpose is understandable.

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 when-to-use guidance is provided, and no alternative tools are mentioned. The phrase 'from completed trips' implies a filter condition, but it does not explain when an agent should prefer this tool over get_countries_visited, get_place_visits, or get_travel_history.

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 tool read-only and non-destructive. The description adds valuable behavior: a $0.20 cost, required API key, a spec URL, and explicit opt-in behavior for location and money. There is no contradiction with 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 three dense sentences with no filler: the first names the pack and its sections, the second gives toggle guidance, and the third covers cost, auth, and spec. Information is front-loaded and each sentence 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?

Given the output schema and annotations, the description covers the important operational details: contents, toggles, opt-in sections, cost, API key, and spec link. The main gap is the lack of differentiation from similar life-context sibling tools, which makes the definition mostly complete but not fully self-sufficient.

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 fully documents all eight parameters. The description only restates that include_relationships/include_memories can be omitted and that location/money stay opt-in, adding minor context but no substantial parameter semantics beyond the schema.

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

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

The description names a specific resource — 'Life Context Protocol (LCP) pack for the authenticated user' — and enumerates its contents: identity, pulse, who_matters, whats_next, memories. This clearly goes beyond the generic title, though it does not explicitly distinguish itself from the similarly named sibling get_life_context.

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 parameter-level usage guidance ('Pass include_relationships/include_memories false to omit those sections; location and money stay opt-in') and notes the API key and cost, but it never states when to use this tool instead of alternatives like get_life_context, get_memories, or get_location_context. Selection guidance is missing.

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 valuable context beyond that: the data is canonical, derives from completed trips, excludes other people's travel, costs $0.10 per call, and requires an API key. No contradiction 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 extremely compact and front-loaded, with the core meaning first and the cost/auth note parenthesized. All words carry value, though the phrase 'not other people travel' is grammatically awkward and 'canonical' is undefined. Overall it is efficient, not bloated.

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 optional and completely undocumented parameters, the description does not give the agent enough to call the tool correctly. The output schema and read-only annotations help, but the missing parameter semantics and the lack of explicit date-range/format guidance make this under-specified for a tool with multiple optional inputs.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented 'to', 'from', and 'include_residence' parameters. It does not mention or explain any of them. The agent is left to guess whether 'from'/'to' are dates, ids, or something else, and what residence inclusion means.

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 (countries) and the source scope (completed trips), and adds a distinguishing 'not other people travel' note. It does not use an explicit verb, but 'canonical countries from completed trips' is unambiguous enough for an agent to infer a retrieval operation.

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 the tool (when the ask concerns canonical countries visited on completed trips, not cities or individual trips) but does not name any alternative tool or state explicit exclusions. Sibling tools like get_cities_visited or get_travel_history are present but not referenced, leaving routing to the agent's inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the cost ($0.10) and API key requirement, which are useful operational constraints, but says nothing about what 'states' are, how they are filtered, or output behavior beyond what the output schema likely covers.

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 concise sentence that front-loads the resource and includes cost/auth details. It is efficient, though the parenthetical may be too terse to be 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?

With an output schema present, return values need not be explained, but the description fails to explain the core concept of 'permitted assertion states' or how the temporal parameters affect results. For a tool with five parameters and 40% schema coverage, the description is 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 only 40%, and the description provides no information about the five parameters (known_at, valid_at, people_id/person_id alias, predicates). Two parameters have schema descriptions (people_id and person_id alias), but the temporal and predicate parameters are undocumented, and the description does not compensate.

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 ('assertion states for a person') and implies a retrieval action, but the verb is not explicit and the phrase 'flagged life-graph; off by default' is ambiguous. It is distinguishable from siblings like get_life_graph or get_person_links only by the specialized 'states' concept, which is not clearly defined.

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 get_life_graph, get_context_pack, or get_life_context. The parenthetical about being off by default suggests limited availability but does not give actionable conditions for invocation.

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 read-only and non-destructive behavior, and the description's 'List' wording is consistent. It goes beyond annotations by disclosing that an API key is required and that the call costs $0.10, which is operationally useful for an agent deciding whether to call it.

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

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

The description is two compact sentences with no filler; the main verb is front-loaded and the cost/auth constraint is efficiently appended. The arrow notation is terse but packs useful parameter semantics into very few words.

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?

Cost, authentication, read-only intent, and some asset-type scope are covered, and an output schema exists so return format need not be described. However, with three un-described parameters, no enums, and many sibling tools, the description leaves enough ambiguity around entity_type values and the inventory mapping that invocation still requires inference.

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 description coverage, the description must explain parameters, and it partially does: the parenthetical likely enumerates asset_type values and 'entity_type inventory_item → inventory' adds domain mapping. But it leaves entity_id implicit and does not enumerate valid entity_type values, so the compensation for low schema coverage is incomplete.

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 action ('List assets linked to an entity') and gives concrete asset-type examples (role, signed_url, versions), so an agent can tell what the tool returns. It does not explicitly contrast this with get_asset or get_inventory, so it misses the highest sibling-differentiation bar.

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 intended use is implied by 'List assets linked to an entity,' and the 'entity_type inventory_item → inventory' hint is context-specific. However, there is no explicit guidance about when to choose this over get_asset/get_inventory or when it should not be used, which is noticeable given the large sibling 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context by stating the cost ($0.05) and auth requirement (API key), which are behavioral constraints not present in the structured metadata. It does not contradict any annotation.

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 of about 13 words with no filler. The core action and scope are front-loaded, with cost and auth appended parenthetically. Every token 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?

Given the tool's simplicity, two required params, and an existing output schema, the description covers the purpose, entity types, cost, and auth requirement. The term 'graph edges' is somewhat technical but the output schema presumably defines the return shape. The only notable gap is lack of usage guidance, but that is covered by another dimension.

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. It partially does by enumerating the allowed entity_type values (event, trip, place, person) and implying entity_id is the identifier of that entity. However, it does not describe what IDs look like or the exact meaning of entity_id beyond that implication.

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 ('List') and a specific resource ('graph edges') and names the valid entity types (event, trip, place, person). This clearly differentiates it from sibling tools like get_entity_assets or get_person_connections.

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 when to use the tool by scoping it to a specific entity type and graph edges, but it does not explicitly say when to use it over alternatives like get_life_graph or get_person_connections. There is no when-not-to-use guidance or mention of complementary tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful operational context beyond that: the API key requirement, a $0.10 cost, and the default exclusion of browsing noise. These are behavioral and constraint details not present in the 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 compact and front-loaded with the core purpose, followed by parameter guidance, default behavior, and operational constraints. Every sentence provides actionable information without redundancy.

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

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

Given the output schema exists and the input schema covers most parameters, the description fills the remaining important gaps: range semantics, default noise exclusion, auth requirements, and cost. An agent has enough information to select and invoke 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 coverage is high at 83%, and the description adds useful semantics beyond the schema: it clarifies that 'year' means calendar year, lists the range shortcut values, and emphasizes preferring explicit from/to. It does not add meaningful detail for the kinds parameter, but the schema already describes that adequately.

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 resource as 'Authenticated user's calendar events' and the tool name supplies the 'get' verb, making it clear this is a read operation on calendar events. It distinguishes itself from obvious siblings like log_event, update_event, and delete_event, but it does not explicitly name any alternatives or provide contrast with similar listing 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?

The description gives clear invocation guidance: prefer explicit from/to dates, use shortcuts for common ranges, and note that browsing noise is excluded by default. It does not, however, state when NOT to use this tool or point to alternatives such as log_event, update_event, or delete_event.

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 read-only safety profile is covered. The description adds useful behavioral context beyond annotations: authentication requirements ('OAuth or a supported scoped credential'), API key requirement, and cost ($0.10). This is meaningful additional operational information.

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

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

The description is two short sentences with the core purpose front-loaded and the authentication/cost details appended compactly. Every sentence carries useful information with no filler or redundancy.

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 zero-parameter tool with output schema present and annotations covering safety, the description is largely complete: it names the returned summary components, authentication requirements, and cost. The only minor gap is that it does not specify the time period or scope of the cashflow summary (e.g., all-time vs. current period), though this may be covered by the output schema.

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

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

The tool has zero parameters, so the schema offers no parameter documentation burden. Per the baseline for 0-parameter tools, a score of 4 is appropriate. The description adds no parameter details because none exist.

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 returns an 'Authenticated user cashflow summary' with specific components: spend, income, net, and top spend categories. This gives a specific resource and output scope. It does not explicitly distinguish itself from siblings like get_transactions or get_money_between_people, but the summary purpose 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 description implies this is for the authenticated user's own cashflow summary and notes OAuth/scoped credential requirements. However, it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or alternative tools, leaving some usage inference to the agent.

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 read-only and non-destructive behavior. The description adds useful context by disclosing a $0.10 cost and API key requirement, which are behavioral constraints beyond the annotations. It does not mention pagination or filter specifics, but the annotations lower the 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 a single sentence that communicates purpose, filtering capability, cost, and authentication requirement without any filler. It is efficiently front-loaded and easy to scan.

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 browse operation with no required parameters, an output schema, and read-only annotations, the description is mostly sufficient. The main gap is that the available filters are not enumerated, but this does not prevent a basic invocation and the overall context is adequate.

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 0 parameters, so the baseline is 4. The description adds that filters are supported, which is meaningful even though the schema is empty and allows additional properties. It does not list filter names, but with no required parameters this is acceptable.

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 ('Browse owned inventory') and mentions filters, making the core purpose clear. It does not explicitly differentiate itself from get_inventory_item or search_inventory, so it falls short of a 5.

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

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

No guidance is given on when to use this tool versus siblings like search_inventory or get_inventory_item. The phrase 'with filters' implies a browsing use case, but there are no explicit use conditions or alternatives.

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

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

Annotations already mark this as read-only and non-destructive, so the description is not burdened with safety disclosure. It adds meaningful context beyond annotations: the call costs $0.10, requires an API key, and returns a full item with related valuations, people links, and assets.

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-loaded with the most important functional information, followed by cost and auth requirements in parentheses. Every phrase earns its place, though the content is sparse.

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

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

With an output schema and read-only annotations present, the description is adequate for a simple single-id retrieval: it states what is returned, the cost, and the API key requirement. It is not fully complete because it fails to distinguish this from the sibling list/get tools, which is relevant given the large sibling set.

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 does not mention inventory_id at all. Although the parameter name and type are self-explanatory, the description provides no added meaning about what value is needed or how it maps to the returned item.

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 resource as a single inventory item and specifies what it contains ('valuations, people links, assets'), which is clear and useful. It does not explicitly name a sibling alternative, so it stops short of full differentiation from get_inventory or get_inventory_valuations.

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 choose this tool over the many related siblings like get_inventory, get_inventory_valuations, or get_entity_assets. It mentions API key requirement but does not state use cases or exclusions.

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 indicate a safe read operation. The description adds useful behavioral context by disclosing the $0.10 cost and required API key, and by noting the chronological ordering of results. These details go beyond the structured 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 a single front-loaded sentence with a useful parenthetical for cost/auth. There is no fluff or redundant repetition of the tool name or title.

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

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

With one required parameter, an output schema, and read-only annotations, the context is mostly sufficient. The description adds cost/auth and ordering behavior, though it could be more explicit about the inventory_id parameter and when to use this tool over siblings.

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

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

Schema coverage is 0%, so the description must compensate for the undocumented inventory_id parameter. It only refers to 'an item,' which provides minimal semantic context and does not explain the ID format, source, or relationship to get_inventory_item. The parameter name helps, but the description leaves most of the burden unmet.

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 tool returns a 'Chronological valuation history for an item,' which is a clear resource and scope. It does not explicitly contrast with siblings like get_inventory_item or add_inventory_valuation, but the word 'history' distinguishes it reasonably well.

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 intended use is implied: an agent needing valuation history for an inventory item would choose this tool. However, there is no explicit guidance about when to prefer it over related tools such as get_inventory_item or add_inventory_valuation.

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 read-only and non-destructive, and the description adds meaningful context: authentication requirements via OAuth or scoped API keys, cost, and default inclusion behavior. This goes beyond the structured annotations and aligns with them, with no 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?

The description is three concise sentences that front-load the purpose and then cover defaults and auth/cost. Every sentence adds useful information without redundancy or filler.

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

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

For a read-only tool with zero required parameters, an output schema, and safe annotations, the description adequately covers defaults, opt-in location, and authentication. It is slightly thin on routing to more granular sibling tools, but an agent has enough to invoke 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 100%, so all three boolean parameters are already documented with defaults. The description reinforces the include_*=false pattern and the opt-in nature of location, but adds little new meaning beyond the structured schema. This fits the baseline where schema does the heavy lifting.

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

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

The description uses a specific verb ('Get') and names a composite resource ('snapshot of the authenticated user's current life context') with enumerated contents: identity, today/upcoming events, pulse, trackers. It also clarifies the optional relationship, memory, and location buckets. It does not explicitly differentiate from sibling tools like get_context_pack, so it is clear but not maximally distinct.

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 that relationships and memories are included by default and can be omitted via include_*=false, and that location is opt-in. This gives practical call-construction guidance but no explicit when-to-use versus alternatives such as get_memories, get_events, or get_trackers. Usage is implied by 'snapshot' rather than stated with exclusions.

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 description does not need to reassert safety. It adds valuable behavioral context by disclosing the private export scope, the cap behavior behind full=true, optional event-people links, the OAuth/scoped-credential requirement, and the $0.25 cost. This goes beyond what the annotations 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 compact and front-loaded: the first clause states what the tool exports, followed by the key flag, optional links, and auth/cost note. Every sentence earns its place, and there is no filler or redundant restatement of the tool 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?

Given the output schema, annotations, and the tool's simple parameter structure, the description covers essential invocation details: scope, the full flag, optional links, auth, and cost. The only notable gaps are explicit guidance around the max_people/event_links_limit caps and alternatives, but these are not critical for a successful 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?

With only 25% schema description coverage, the description must compensate for underdocumented parameters. It explicitly mentions full=true and 'Optional event-people links,' but it never names or explains max_people or event_links_limit, and 'larger capped list' is vague about the actual cap. This is only partial compensation for four 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 clearly identifies the action ('export') and the object ('private life-graph'), and it enumerates the graph's contents: favorites/VIP plus people with edges or recent event tags. It does not explicitly contrast with sibling tools like get_life_context or get_people, but the name and content make the purpose distinguishable.

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 context through phrases like 'Explicit private life-graph export' and 'Pass full=true for a larger capped list,' and it states an authentication requirement. However, it never explicitly says when to choose this tool over related siblings such as get_people or get_life_context, nor does it state exclusions or alternatives.

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

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

Annotations already mark this as read-only and non-destructive. The description adds useful behavioral context beyond those annotations: the result is a 'likely' estimate, includes confidence and provenance, requires an API key, and costs $0.10 per call.

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 conveys the core purpose, uncertainty, provenance, cost, and authentication requirement without any filler. The most important information is front-loaded and every element 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?

Given one optional parameter fully documented in the schema, an output schema, and read-only annotations, the description covers the essential operational facts including cost and API key requirement. No critical information needed to invoke the tool correctly appears missing.

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

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

The schema already describes the only parameter, 'at', as an ISO timestamp with 100% coverage. The description adds meaning by distinguishing 'current' vs 'at-time', which clarifies that omitting the parameter yields the current estimate and providing it yields an estimate for that time.

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 names the resource, a place estimate at the current or a specified time, with confidence and provenance. It is understandable, though it lacks an explicit verb and does not distinguish itself from sibling tools like get_life_context or get_location_history.

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 phrasing 'current or at-time place' implies this tool is for point-in-time location estimation, but the description does not explicitly say when to use it over alternatives or when not to use it. Cost and API key requirements are practical prerequisites, but not 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 adds useful behavioral context beyond the annotations: results are normalized, venue-level by default, and not raw GPS noise, plus an API key and cost are required. Since annotations already declare readOnlyHint, the description does not need to belabor safety, and it adds meaningful nuance.

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

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

The description is two short sentences with no filler. The core behavior is front-loaded and the cost/auth caveat is appended compactly.

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 output schema and read-only annotations reduce the burden there, but the description still omits parameter meanings and sibling differentiation. For a six-parameter tool, an agent needs more than one implicit precision hint to invoke it correctly.

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

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

Schema description coverage is 0%, and the description only hints at one parameter: 'venue-level by default' implies a precision default. The other five parameters (to, from, city, place, country) receive no semantic explanation, leaving the agent to guess how they combine.

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 scopes the tool to normalized visit history at venue-level rather than raw GPS noise, which distinguishes it from a raw location feed. It lacks a direct contrast with siblings like get_place_visits or get_travel_history, but the resource and its normalizing behavior are specific.

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 guidance is that an API key is required and the call costs $0.10. There is no indication of when to prefer this over get_travel_history, get_place_visits, get_location_context, or get_cities_visited, and no exclusions or alternative conditions.

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 value beyond annotations by disclosing OAuth/scoped credential and API key requirements and the $0.10 cost. No behavioral trait contradicts 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?

Purpose is front-loaded, followed by usage guidance, alternative routing, and requirements in a compact form. Every clause contributes new information; no filler or redundant elaboration.

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 the input schema covering both parameters and an output schema present, the agent has all return and parameter details. The description fills the remaining gaps: when to prefer search, authentication needs, API key, and cost. This is complete for a read-only retrieval tool.

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

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

schema_description_coverage is 100%, so schema already documents both optional parameters. The description adds meaning to 'query' by stating it supports both semantic and keyword retrieval, which goes beyond the schema's 'Semantic focus' label. Limit semantics are left to the schema, which is sufficient.

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?

Description states a specific action and resource: retrieving authenticated user memories from Dayze Agent. It also distinguishes itself from sibling search by noting when search is preferred for event-first trip and calendar titles. This is more than a restatement of the name or title.

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 instructs passing a query for semantic/keyword retrieval and tells the agent to prefer search for event-first trip and calendar titles. It also discloses credential and API key prerequisites. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds valuable operational traits beyond annotations: cost ($0.10), API key requirement, and the precise scoping 'authenticated user ↔ one contact via expenses FKs.' 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 compact and front-loaded: it establishes the relationship to get_person_transactions first, then adds the alias rationale and cost constraints. Every sentence earns its place with no filler or redundancy.

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 100% schema parameter coverage, an output schema, safety annotations, and an explicit pointer to the sibling tool, the description is nearly complete. It could directly restate the return behavior instead of relying on 'Same as get_person_transactions,' but the alias framing makes this 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 description coverage is 100%, so the baseline is 3 even without extra parameter details in the description. The description's scoping phrase 'one contact via expenses FKs' gives some context for person_id/name, but it does not add meaningful syntax or format details beyond the schema.

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

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

The description states the tool's function via 'Same as get_person_transactions: authenticated user ↔ one contact via expenses FKs,' which clearly specifies a verb, resource, and scope. It also distinguishes itself from the sibling by explicitly naming get_person_transactions and framing this as an alias, so an agent can tell them apart.

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 selection guidance: 'Prefer get_person_transactions; this alias exists for agent discoverability.' This tells the agent when not to use this tool and points to the preferred alternative, leaving no ambiguity about routing.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavior: OAuth/scoped credential requirement, cost, server-side redaction of credential/secret spans, default note omission, and pagination behavior (total/truncated). 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 dense but every sentence earns its place—purpose, field summary, alternative, notes behavior, pagination, auth/cost. It is front-loaded with the primary purpose and no 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?

Covers all necessary aspects: primary action, output fields, pagination, notes behavior, authentication, cost, and the sibling for photos. With an output schema present, nothing an agent needs to call correctly is missing.

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

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

Schema coverage is 100%, but the description goes beyond schema by explaining the semantics of include_notes (redaction, progressive fetch) and limit/offset (returns total and truncated). This adds meaning the schema alone doesn't convey.

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

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

The description states a specific verb and resource: 'List the authenticated user's CRM people.' It also distinguishes itself from the sibling get_person_photos by noting that the full gallery is available via that tool, making the purpose unmistakable.

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

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

Explicitly routes the agent to an alternative with 'use get_person_photos(person_id) for the full gallery' and explains the include_notes progressive fetch condition. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already mark the operation read-only, and the description adds useful behavioral context: name resolution via aliases, OAuth/scoped credential requirement, and API key cost. 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?

Two tight sentences with no waste. The core purpose is front-loaded, and the credential/cost details are compactly appended.

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 and an output schema present, the description covers the essential behavioral and operational details. It could be slightly clearer that at least one of person_id or name should be supplied, since the schema marks both as optional.

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 parameters are already documented. The description adds semantic value by explaining the relationship between person_id and name, and that name is resolved through aliases.

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 a specific verb and resource: 'List canonical aliases (nicknames) for a CRM person.' It clearly specifies the operation and distinguishes it from broader person tools like get_people or resolve_person.

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 clear usage context by saying to pass either person_id or name, which tells the agent how to invoke it. It does not explicitly compare against sibling tools, but the intended use is apparent enough.

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 useful behavioral context by noting the $0.05 cost and the API key requirement, which are not present in 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 a single compact sentence with zero filler. It front-loads the core action and resource, then appends the only two operational caveats (cost and API key) in a brief parenthetical.

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

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

For a one-parameter read-only tool with an output schema, the description covers the essential information: what it lists, the scope, cost, and auth. It does not mention usage trade-offs against sibling graph-related tools, but this is a minor gap given the simple interface and existing annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It adds that the tool operates on 'one CRM person,' giving some meaning to person_id. However, it does not clarify the expected format of person_id or how it relates to other person identifiers in sibling tools.

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 verb and resource: 'List graph edges for one CRM person.' It is specific about operating on a single person's graph edges, though it does not explicitly distinguish itself from sibling tools like get_entity_links or get_life_graph, 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 phrase 'for one CRM person' implies the tool is for retrieving the graph connections of a specific person, and the mention of API key required and cost gives operational context. However, there is no explicit guidance on when to use this tool versus alternatives such as get_life_graph or get_person_interactions.

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

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

Annotations already cover read-only and non-destructive behavior, so the description correctly focuses on more useful behavioral details: 'extended kinds like visit/gift/stayed_over encoded in summary' and inclusion of 'co-tagged calendar events'. These reveal data-modeling quirks beyond what readOnlyHint and destructiveHint communicate.

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 dense sentences: purpose, usage guidance, and invocation essentials. No filler or redundant restatement of the schema. The main purpose is front-loaded and every clause adds 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 tool with an output schema and read-only annotations, the description covers the core inputs, the interaction-kinds semantics, the calendar-event inclusion, and the cost/auth caveat. It could slightly improve by stating what happens if neither person_id nor name is supplied, but it is otherwise sufficiently complete for an agent to call it correctly.

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

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

Schema coverage is 67%, leaving name and person_id bare. The description compensates by stating 'Pass person_id or name,' which clarifies that these are mutually acceptable identifiers. It also reinforces the kind parameter by listing extended kinds like visit/gift/stayed_over, adding meaning beyond the bare schema examples.

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 a specific product: 'Relationship timeline for one CRM person' and enumerates the exact contents (interactions rows, extended kinds, co-tagged calendar events). It is clearly distinct from siblings like get_person_transactions or get_people. This is a strong, specific verb-resource-scope statement.

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 when to prefer this tool: 'Prefer this over dumping people.notes for "when did I last see X?"'. It also tells the agent how to identify the person: 'Pass person_id or name.' This gives a concrete usage directive and names an alternative approach to avoid.

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

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds meaningful behavioral context: notes are redacted and omitted unless include_notes=true, an OAuth or supported scoped credential is required, and an API key is needed. It also clarifies the returned data scope and 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 compact and well-structured: function is front-loaded, the alternative is named, notes behavior is clarified, and auth/pricing are included. No sentence is wasted and it remains easy to scan.

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

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

Given the tool has an output schema, the description does not need to explain return values. It covers the person_id scoping, the include_notes behavior, authentication requirements, and the distinction from a sibling. Nothing essential is missing for correct selection and 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 coverage is 100%, so the baseline is a 3. The description adds extra meaning by specifying person_id must be user-owned and by explaining include_notes affects whether redacted notes are returned. These details go beyond the raw schema.

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

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

The description clearly states the tool returns a subgraph around one user-owned person_id, including profile fields and declared connections. It also differentiates from the sibling get_person_photos by directing that tool for the full gallery, leaving no ambiguity about scope.

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 explicitly says 'Use get_person_photos for the full gallery,' which tells the agent when not to use this tool and which alternative to choose. It also clarifies authentication requirements and pricing, giving enough context for appropriate selection.

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 clear. The description goes beyond annotations by disclosing the exact return structure (photos array with id, url, is_primary, created_at), the fact that inline MCP image attachments are included for chat rendering, and the cost/auth requirements ($0.10; API key required). This adds meaningful behavioral context.

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 that front-loads the core function, then provides the return format, attachments, and cost/auth in a compact parenthetical. Every piece of information earns its place with no redundancy or filler.

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

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

Given the simplicity of the tool (one parameter, clear purpose) and the presence of an output schema, the description covers everything an agent needs: it states what it does, what it returns, the input, and even cost/auth. It is complete for correct invocation and interpretation of results.

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. It says 'Accepts person_id,' which is minimal but does imply person_id refers to the CRM contact from the opening. However, it does not elaborate on the type, format, or constraints beyond what the schema already states, so it only marginally adds 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?

The description clearly states the tool retrieves gallery image URLs for a CRM contact, which is a specific verb+resource. It also describes the return shape and the input parameter, making the purpose unambiguous and differentiating it from sibling tools like get_photos_for_event or get_photos_for_place by the explicit 'CRM contact' context.

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 by stating it is for a CRM contact, but it does not explicitly name alternatives or give conditions for when to use this tool versus other photo-related tools such as search_photos or get_photos_for_event. There is no direction on exclusions or when not to use it.

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. The description adds valuable non-obvious context beyond annotations: it reuses existing expense records rather than maintaining a parallel ledger, and it notes cost and API key requirements. 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?

Two sentences deliver the core purpose, inputs, outputs, data source, cost, and authentication requirement with no filler. The information is front-loaded and every clause carries meaning.

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

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

With a full input schema, complete parameter descriptions, read-only annotations, and an output schema available, the description covers the remaining important context: data derivation, required identifier style, return shape, and operational considerations. Nothing critical for invoking the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic guidance by connecting person_id/name to the ledger concept and explaining the data source ('paid_to_person_id / income_from_person_id'), which helps an agent understand how parameters relate to the domain.

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 defines the tool as a 'Me↔contact money ledger' built from expense fields, which is a specific verb+resource. It also states what it returns ('entries + per-currency totals') and distinguishes it from a generic expense query by focusing on person-related transactions.

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 clear usage context: pass person_id or name to get person-to-person money movement. It does not explicitly name alternatives like get_transactions, search_transactions, or get_money_between_people, nor does it state when not to use this tool, but the 'person ledger' framing strongly implies the intended use case.

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. The description adds useful context beyond the annotations: it returns a secure URL, may include an inline MCP image attachment, requires an API key, and has a $0.10 cost. This is valuable operational information without contradicting 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 a single front-loaded sentence covering the core behavior, followed by a compact parenthetical with cost and auth requirements. Every clause contributes meaningful information; there is no filler.

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

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

For a simple one-parameter read-only lookup, the description covers the return content, security property, attachment availability, cost, and authentication. An output schema exists, so enumerating metadata fields is unnecessary. Minor gaps include error handling and not-found behavior, but they are not essential for this simple 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 description does not explain photo_id at all—it doesn't state where the ID comes from, expected format, or how it relates to other photo endpoints. With only one parameter, the description should compensate for the missing schema docs, but it doesn't.

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 'Single photo metadata + secure URL,' which states a specific resource and operation. The 'Single photo' phrasing clearly distinguishes it from collection-oriented siblings like get_person_photos and search_photos.

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 this tool is for retrieving one photo by ID, but it never states when to choose it over related siblings such as get_photos_for_event or get_photos_for_place. There is no explicit when/when-not guidance; the agent must infer usage from the tool name and the word 'Single.'

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 useful context: cost ($0.10) and the requirement for an API key. However, it does not explain behavior beyond that, such as what the returned 'assets' represent or any pagination/limits. With annotations carrying the safety burden, the added cost/auth info earns 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?

The description is a single short sentence, so it is concise in length, but it is not front-loaded with the most critical information. The core purpose is vague ('Assets linked to an event'), and the useful cost/API key details come after. It is under-specified rather than effectively concise.

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?

Even though the tool is simple (one parameter) and has an output schema, the description is far from complete. It fails to clarify what 'assets' means, does not mention event_id, and does not provide enough context for an agent to correctly invoke the tool or distinguish it from similar tools like get_photos_for_place. The description is wholly inadequate for effective use.

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 does not mention the event_id parameter at all. The agent is left to infer that event_id identifies an event, but no format, semantics, or relationship to other tools is provided. The description adds no value for the 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 description 'Assets linked to an event.' is a noun phrase, not an explicit action like 'Retrieve' or 'Get'. It is vague about what 'assets' means (photos? other files?) and does not differentiate from siblings such as get_entity_assets or get_photos_for_place. The name suggests photos, but the description says assets, adding confusion.

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. The description only provides cost and API key requirements, which are not usage guidelines. No mention of scenarios, exclusions, or alternative tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is covered. The description adds useful extra context with the $0.10 cost and API-key requirement, and it scopes behavior to 'canonical place' assets, but it discloses little beyond those points.

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 includes both cost and auth context in a single sentence. However, it reads as a noun phrase rather than a complete operational description, so it is concise but slightly under-specified.

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 with one parameter and an output schema, and annotations cover the read-only safety profile. Still, the description omits any usage context or parameter clarification, so the agent is left to infer details that could help correct invocation, especially among many similar photographic and place-related tools.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented place_id parameter, but it never mentions place_id or explains what canonical place ID format is expected. While the parameter name is somewhat self-evident, the description adds no semantic value beyond the schema.

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

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

The description states a resource scope ('Assets linked to a canonical place') but lacks an explicit verb such as 'retrieves' or 'returns'; the operation is mostly carried by the tool name. It also does not distinguish this from sibling tools like get_photos_for_event, get_person_photos, or get_place_visits, so an agent must infer what makes this tool unique.

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 about when to use this tool versus alternatives. The only added context is cost and API-key requirements, which do not help an agent choose between get_photos_for_place, get_photos_for_event, or search_photos. No exclusions or conditions 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 cover the safety profile (readOnly, non-destructive, closed-world). The description adds pricing ($0.05) and API-key requirement, which are useful quirks beyond the annotations. But it names place_id as the key while the schema exposes three optional identifiers, an unresolved behavioral 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?

One sentence, em-dash summary of return fields, parenthetical cost and auth. Front-loaded verb+resource with zero 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?

Output schema exists, so return-value detail is not required. But with 0% schema description coverage and three interchangeable-looking ID params, the description should clarify the parameter contract; naming only place_id is insufficient.

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% with 3 undocumented params. The description compensates by naming place_id as the lookup key, but is silent on id and business_contact_id, leaving ambiguity about which parameter actually selects the record.

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 (Fetch one saved place card) plus resource (business_contacts) and enumerates the returned fields (address, opening hours, affordability, notes). Clear against siblings like get_places (list) and get_place_visits.

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?

Implied usage (single-record lookup by place_id) is clear, but no when-to-use vs get_places, resolve_place, or enrich_place_from_google. The cost and auth note hint at a paid/authenticated path but don't route between alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds non-obvious operational context the annotations do not: the $0.10 cost and the API key requirement, plus disclosure of the two underlying data sources. Only minor gaps remain (e.g. pagination or default limit 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?

A single compact sentence front-loads the data sources and fields, with the cost/auth note trailing. There is little waste, though the source-qualified phrasing (`saved_places` from business_contacts) is denser than an agent needs for selection.

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

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

An output schema exists, so return values need not be described, and annotations cover safety. However, for a 7-parameter, 0-required tool with only 29% schema coverage, the description leaves filtering behavior and usage context underspecified, making it only minimally adequate.

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 29%, and with 7 parameters (tag, area, city, near, limit, country, affordability) the description documents essentially none of them beyond restating the affordability format ($/$$/$$$) already in the schema. It does not compensate for the large coverage gap, leaving filtering semantics for tag/area/city/country/limit 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 names the resources clearly ('visit-graph `places` plus saved place cards') and what fields accompany them (address, opening_hours, affordability), which lets an agent understand this is a listing of known venues. It stops short of distinguishing itself from siblings like get_place, get_place_visits, or resolve_place, so it is clear but not disambiguating.

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 guidance, no mention of alternatives, and no stated conditions or prerequisites beyond the cost/API-key note. An agent cannot tell from this text when to prefer get_places over get_place or a search tool.

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

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

Annotations already establish read-only and non-destructive behavior, so the description adds value by disclosing the multi-source merge, the $0.10 cost, and the API-key requirement. It does not cover rate limits or failure behavior, but for a read-only tool with annotations present this is reasonably transparent.

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 entire description is one tight sentence that leads with the user-facing purpose and packs scope, cost, and auth requirement into minimal space. There is no filler or redundancy.

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 five-parameter tool with zero schema descriptions, the description is too thin to let an agent construct a correct call. The output schema may cover return values, but input semantics for place_id vs place, person_ids, and from/to are 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%, and the description only implies that 'place' refers to a venue and that from/to relate to a time interval. The distinction between place and place_id, the meaning of person_ids, and expected date formats are all left unspecified.

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