Dayze — Life in Days + Notable People

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value beyond annotations by specifying the output nature ('life_in_days + day_number timelines') and the cost ($0.08), which is useful behavioral context. It does not contradict 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 concise, front-loaded with the core purpose, and includes a concrete example and cost detail in a compact format. Every sentence earns its place; no redundant or filler 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 five parameters and no output schema, the description provides essential context: what it compares, how it relates to notable_pack, and an example invocation. It could be more complete by explaining parameter interactions or return format, but the given context is sufficient for basic 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?

The input schema covers 60% of parameters with descriptions, and the prose adds meaning for the two slug parameters through the example. However, 'date', 'peers', and 'similar' are not elaborated beyond their schema defaults/descriptions, leaving some parameter semantics under-specified.

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

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

The description clearly states the tool's function: 'Side-by-side notable packs for two slugs' with a concrete example. It differentiates itself from sibling notable_pack by positioning it as 'One call instead of two notable_pack.' This is a specific verb+resource statement that removes ambiguity.

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 clear guidance on when to use this tool: when you need side-by-side comparison of two slugs, and explicitly notes it replaces two notable_pack calls. It does not state explicit exclusions or alternative scenarios, but the practical context is strong 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 read-only, idempotent, and non-destructive behavior, so the description does not need to restate that. It adds valuable context beyond annotations: requires API key or share token, has a $0.20 cost, includes a spec link, and explains that the optional query focuses memories. 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 informative without being verbose. It front-loads the main purpose and contents, then adds practical details (auth, cost, spec) in a compact final sentence. Every sentence earns its place, though the URL and cost might be seen as extra, they are relevant for usage decisions.

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 complexity as a multi-part pack, the description covers what is included (identity, edges, calendar, memories, protocol.version), the optional query, and important constraints (auth, cost, spec). There is no output schema, so the description's mention of components helps set expectations. It could be slightly stronger by referencing alternatives, but is otherwise complete for a read-only getter.

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% for the single optional 'query' parameter, which is already described as 'Optional focus query for semantic memories'. The description reinforces this by saying 'Optional query focuses memories', but adds little new meaning. The schema effectively carries the semantic load, so baseline 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 clearly states a specific verb+resource ('Life Context Protocol reference pack') and enumerates its contents (identity, edges, week calendar, semantic/recent memories, protocol.version). This distinguishes it from sibling tools like get_memories or get_people, which are individual data getters, by framing it as a comprehensive pack.

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: this is a reference pack for getting all LCP context at once. It mentions an optional query to focus memories, and notes API key/share token requirements, but it does not explicitly state when to use this tool versus alternatives like get_life_context or get_memories. No when-not or exclusion guidance is provided.

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

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

Annotations already declare read-only and idempotent hints, and the description adds cost ($0.10) and authentication requirements (API key). This provides useful context beyond the 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 concise sentence with all essential info (resource, range, cost, auth). No wasted 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?

For a simple read-only lookup, the description covers the core behavior. However, the absence of an output schema and unspecified default behavior for the optional range leave some ambiguities, though they are minor given the tool's simplicity.

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

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

The description lists the enum values for range, matching the schema, but does not explain defaults or semantics beyond the parameter name. Since the schema already enumerates allowed values, the description adds limited value.

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 explicitly identifies the resource as 'calendar events' and the range parameter, which distinguishes it from sibling tools like get_expenses and get_people. The tool name 'get_events' supplies the verb, making the purpose 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?

No explicit guidance on when to use this tool vs alternatives; it simply states what it returns. The only contextual hint is 'Requires API key,' which is a prerequisite, not a usage scenario.

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, idempotentHint, and destructiveHint, so the tool's safety profile is covered. The description adds valuable behavioral context by stating an API key is required and noting a cost of $0.10, which is 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 short and front-loaded, stating the purpose in the first phrase. However, it redundantly mentions 'API key required' twice ('Requires API key' and '($0.10; API key required)'), which slightly undermines conciseness.

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

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

Given no parameters and no output schema, the description provides essential information: what it does, auth requirements, and cost. It does not detail the exact structure of the cashflow summary, but this is less critical for a no-input tool with read-only annotations.

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

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

The tool has zero parameters, so the input schema is empty. The description correctly implies that no arguments are needed, and there is no additional parameter semantics to clarify. Baseline for 0 params is 4, and the description adds no further confusion.

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 lists user expenses and provides a cashflow summary, using a specific verb ('List') and resource ('user expenses'). It is distinct from sibling tools like get_events and get_people, which focus on different data domains.

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 clear context for when to use this tool (to retrieve expense or cashflow data) and mentions the requirement for an API key. While it does not explicitly name alternative tools or exclusions, the purpose is unambiguous enough to guide selection among siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no contradiction. The description adds context beyond annotations by stating the API key requirement and per-call cost, which are useful operational details. It does not elaborate on pagination or return format, but with strong annotation coverage this is not a major 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?

The description is two sentences plus a cost note, front-loaded with the core purpose. Every sentence earns its place: first defines what it returns, second gives sibling guidance, third covers auth and cost. 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 zero-parameter, read-only snapshot tool with no output schema, the description fully covers the context: what data is included, the recommended alternative, and the authentication/cost caveat. The component list is enough for an agent to know what to expect.

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 zero parameters, there is no schema to clarify; the baseline for no params is 4. The description does not need to explain parameter meaning, and the schema is 100% covered by the absence of properties.

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 a clear resource ('authenticated user's current life context') with explicit components (identity, events, mood, inner circle, social edges). It is clearly differentiated from the sibling 'get_context_pack' by noting the latter is for a full session bootstrap.

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 'Prefer get_context_pack for a full session bootstrap', which tells the agent when to use the sibling instead, thereby implying when to use this lighter tool. It also specifies the API key requirement as an operational prerequisite.

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, idempotentHint=true, and destructiveHint=false, covering safety traits. The description adds useful context about the API key requirement, cost, and the output structure (people nodes/edges). It does not explain pagination or behavior with parameters, but given annotation coverage, this extra detail is valuable and not contradictory.

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 conveys the core purpose, content, and key prerequisites. Every word earns its place; there is no fluff 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?

No output schema exists, so the description should clarify return values. It gives a high-level shape (people nodes and edges) but lacks details on response format, limits, or parameter effects. The cost and API key info are useful, but the tool is not fully specified for an agent to understand all behaviors.

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 only hints at 'Optional event–people links', which relates to include_event_links, but completely ignores max_people and event_links_limit. The default values in the schema are not explained. This adds minimal 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 clearly states that this tool performs a 'life-graph export' and specifies the content: 'people nodes + person_connections edges' with optional event–people links. This distinguishes it from sibling tools like get_people or get_events, though the term 'export' is somewhat generic. The verb is specific and the resource is 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?

The description implies usage for obtaining the complete life graph but does not explicitly state when to choose this over alternatives. It provides practical prerequisites (API key required, $0.25 cost) but lacks explicit 'when-to-use' or 'when-not-to-use' guidance. The context is present but exclusions are 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 indicate read-only, idempotent, and non-destructive behavior. The description adds crucial details: the semantic vs chronological retrieval modes, API key requirement, and cost ($0.10). These go beyond annotations and inform the agent of auth and operational constraints.

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, front-loaded with the core purpose, followed by usage and operational requirements. Every sentence provides distinct value 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?

For a simple retrieval tool with two optional parameters and no output schema, the description covers the essential behavioral and operational context. It lacks explicit mention of return format/pagination, but the 'recent chronological' note implies ordering, and the tool appears low-risk. Slightly more detail about response structure would push this to a 5.

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 already fully describes both parameters (limit and query). The description adds meaning to the query param by explaining that passing it triggers semantic retrieval and omitting it yields recent chronological results, which is not fully captured in the schema's 'Semantic focus (optional)'.

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 'User memories from Dayze Agent' and distinguishes two modes: semantic retrieval via query or recent chronological when omitted. This specific verb+resource combination differentiates it from sibling get_* 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?

Provides actionable guidance on when to pass query vs omit it, which is useful for invocation. However, it does not explicitly mention alternatives or exclusions relative to sibling memory/get_context tools, leaving room for a more explicit 'use this for memories, not for other data types' statement.

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, idempotentHint, and destructiveHint, so the risk profile is covered. The description adds useful behavioral context beyond annotations: it requires an API key, costs $0.10, and returns each row with 'contact_origin' values. This enriches the agent's understanding of invocation requirements and output content without contradicting 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 short and front-loaded, but it redundantly states 'Requires API key' twice (once as a sentence and again in parentheses). Removing the duplication would make it tighter. Still, it is concise and structured with clear separation of function, output detail, and requirements.

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 list tool with no input schema and no output schema, the description gives a basic expectation: flat list with contact_origin. However, it omits other potential output details (e.g., additional fields, pagination, sorting) and does not explain what 'CRM people' entails in full. This is adequate but has gaps given the absence of an 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?

There are zero parameters, so the schema is fully self-explanatory. The baseline for 0 params is 4. The description mentions 'contact_origin' which is output-related, not an input parameter, so no additional semantic burden is needed. This is appropriately handled.

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 'List' and the resource 'user CRM people', specifying it returns a flat list. The mention of 'contact_origin' fields adds specificity and distinguishes it from sibling tools like get_events or get_expenses. This is a precise, scoped purpose.

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

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

The description implies usage: if you need a flat list of CRM people, use this tool. However, it does not explicitly state when to use it over alternatives like 'search' or 'notable_search', nor does it provide exclusions. The requirement for an API key and cost are operational details, 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description's job is lighter. It adds valuable context beyond annotations: the response includes a profile plus declared connections, an API key requirement, and a per-call cost. This extra information helps the agent anticipate side effects and prerequisites.

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: two sentences that front-load the core purpose and provide essential usage details (cost, API key). Every word earns its place, with no filler or repetition of schema fields.

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 tool with one parameter and no output schema, the description sufficiently covers input, output scope, and usage constraints. It doesn't mention pagination or return format, but 'subgraph' implies all connections, making it reasonably complete. The lack of an output schema is mitigated by the clear description of what is returned.

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

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

Schema coverage is 100% with the single parameter person_id described as 'UUID', so the baseline is 3. The description only references 'one person_id' without adding extra meaning beyond the schema. It does not clarify format constraints or behaviors associated with 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 clearly states the tool's function: retrieving a subgraph around a specific person_id, including profile and declared connections. This distinguishes it from sibling tools like get_people (likely a list) and get_life_graph (likely the whole graph). The phrasing 'profile plus all declared connections' provides a precise 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 implies when to use the tool (when you need a person's neighborhood) but does not explicitly compare to alternatives or state exclusions. It mentions the prerequisite of an API key, but lacks direct guidance on choosing between this and sibling tools.

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

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

Annotations already cover safety (read-only, idempotent, non-destructive). The description adds valuable context about cost ($0.10) and API key requirement, which are not in 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?

Extremely concise: two sentences, no fluff. Information is front-loaded with the verb, and cost/auth are clearly flagged. Minor redundancy with 'API key' repeated, but still efficient.

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

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

For a simple zero-param read-only list tool with strong annotations, the description is complete. It tells what it does, cost, and auth. No output schema required; return type is implied by 'list'.

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

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

Tool has zero parameters, so baseline is 4. Description does not need to explain parameters; it adds no parameter-specific details but stays consistent.

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?

Clearly states 'List user trackers / habits / streaks' with a specific verb and resource. Distinguishes from sibling tools by the domain of trackers/habits/streaks.

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?

Provides no explicit when-to-use guidance or alternatives, but the action is straightforward. The API key requirement is a prerequisite, not usage guidance. Usage is implied by the description.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive. The description adds value by disclosing the tool's composition, that timeline events include day_number, and the $0.05 cost. This goes beyond the annotations without contradicting them.

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 yet information-dense: default usage, component list, sibling preference, example, and cost are all conveyed in three sentences. It is front-loaded with the most critical guidance and contains 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?

Given the tool's simplicity (no output schema, few params), the description covers the main aspects: content, usage preference, example, and cost. It lacks detail on date parameter behavior, but that is a minor gap for a package tool.

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

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

Schema coverage is only 50% (peer and similar lack descriptions). The description compensates by linking 'similar people' to the similar parameter and 'birthday peers' to peers, and the example clarifies the slug format. It adds meaning beyond the bare schema for these fields.

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

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

The description clearly states the tool's purpose: a default package for 'who is X' queries, listing its components (profile, life_in_days, similar people, birthday peers). It also distinguishes from the sibling notable_profile by explicitly preferring this tool. This is specific and action-oriented.

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

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

It gives explicit usage guidance: 'DEFAULT for who is X' and 'Prefer this over notable_profile.' However, it does not mention when to use alternatives like notable_pack_premium or notable_search, so it partially covers when-not.

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 valuable behavioral context beyond annotations: it discloses the 'Errors if below bar' failure mode, the specific quality thresholds (score≥85, timeline≥8, image, embedding), and the $0.10 cost. Since annotations already cover read-only and idempotence, this extra information is significant for decision-making.

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 packs the core value proposition, quality bar, error behavior, usage context, and an example into a few short sentences, with no wasted words. Each clause earns its place.

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

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

Despite lacking output schema, the description tells the agent what the pack includes (score≥85, timeline≥8, image, embedding) and the error condition. It covers cost and gives a usage example. The only gap is explaining optional parameters, but the essential context for selection and invocation is present.

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

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

Schema description coverage is only 25%, so the description must compensate. It provides an example for 'slug' (elon-musk) but leaves 'date', 'peers', and 'similar' without any added meaning. The low coverage and minimal description leave parameter behavior ambiguous.

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 premium notable pack with specific quality guarantees (score≥85, timeline≥8, image, embedding), distinguishing it from the sibling 'notable_pack' by its 'S-tier guaranteed' standard and cost. It explicitly states the resource and the qualitative bar, making its 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?

The description provides a clear usage context: 'Use when you need high-quality, complete notable context.' This tells the agent when to select this tool, but it does not explicitly mention alternatives or when not to use it, which would be stronger differentiation.

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 idempotentHint=true, and the description adds useful behavioral context: it returns a bio-only profile, excludes certain data types, provides an example, and notes a cost of $0.02. This is beyond what annotations provide, though it could elaborate on output structure or edge cases.

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: two sentences covering purpose, exclusions, alternative, example, and cost. Every word earns its place with 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 one-parameter tool with no output schema, the description sufficiently conveys the return type (bio-only JSON), scope (by slug), an example, and caveats. Given the low complexity, this is complete.

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

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

The schema already covers the single 'slug' parameter with a description and example. The description's example 'taylor-swift' is a minor addition, but since schema coverage is 100%, the description does not need to compensate and adds little extra semantic meaning.

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

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

The description clearly states the tool provides a 'Bio-only profile JSON by slug', explicitly listing what is excluded ('no life-in-days, similar, or birthday peers'). This distinguishes it from notable_pack and other sibling tools, making its purpose unambiguous.

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

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

It gives explicit guidance to 'Prefer notable_pack for “who is X / age in days / peers”', directly naming the alternative and specifying when not to use this tool. The exclusion list further clarifies 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable context beyond annotations: it states the catalog is 'public', indicates a cost ('$0.01'), and provides an example slug, which helps set expectations about the tool's behavior and access 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 compact and well-structured: the first sentence states the action and resource, the second provides usage context, and the third gives an example and cost. No redundant details; 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?

For a simple search tool with no output schema, the description covers the essential aspects: what to search, why to use it, an example, and cost. The strong annotations and simple schema (2 params, one required) mean the description is sufficiently complete without needing to explain return formats or error handling.

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 descriptions are minimal ('Search query (alias: query)' and 'Max results 1–20'), while the description enriches parameter meaning by specifying that q can be a name, occupation, or slug, and gives a concrete example ('albert-einstein'). This goes beyond the schema baseline and helps the agent construct valid queries.

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 is specific and action-oriented: 'Search the public Dayze notable-people catalog by name, occupation, or slug.' It clearly defines the resource (notable-people catalog), the operations (search), and the search criteria. The phrase 'Use when you need to find a person before fetching a pack' differentiates it from siblings like notable_pack, establishing a distinct purpose.

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

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

The description explicitly provides a use case: 'Use when you need to find a person before fetching a pack.' This tells the agent when to invoke this tool versus fetching a pack directly. It does not name alternative search tools (e.g., get_people or search), but the context is clear enough to avoid misuse.

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 idempotentHint=true, and the description adds useful context such as API key requirement and per-call cost ($0.15). It also clarifies the 'semantic' nature of search, which implies fuzzy matching rather than exact matches. This goes beyond the safe-read profile established by 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 extremely concise—one main sentence plus a parenthetical with cost/auth info. It is front-loaded with the core purpose and contains 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?

Given the tool's moderate complexity, the description is fairly complete: it specifies the scope (life graph), entity types (events, people, memories), and the authentication/cost requirements. Since no output schema exists, a bit more detail on result format could help, but the core usage is well-covered.

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 input schema has 100% description coverage, so the baseline applies. The description does not add any parameter-specific meaning beyond the schema's existing field descriptions for 'query', 'q', and 'limit'.

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 'Semantic search across the authenticated user life graph (events, people, memories)' with a specific verb and resource. This clearly distinguishes it from sibling tools like get_events or get_people, as it is a cross-entity semantic search rather than a targeted retrieval.

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 for cross-entity semantic searches but does not explicitly specify when to use this tool versus alternatives or mention any exclusions. It simply states the search scope without offering comparative guidance against sibling tools.

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