EQIQs

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

Annotations cover the safety profile (not read-only, not destructive, not idempotent), and the description adds genuinely new context beyond them: the note is private, it surfaces on the person's profile, and the call costs 1 unit. It does not say whether notes can later be edited or removed, so it is strong but not exhaustive.

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

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

Two sentences, front-loaded with what is saved and where it appears, followed by the trigger and the cost. No filler and no repetition of schema 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 two-parameter mutation tool with an output schema and full annotation coverage, the description supplies what structured fields cannot: visibility, cost, and invocation timing. Only the post-write lifecycle (editing or deleting the note) is left unstated.

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% and the schema already explains that person accepts an id, exact email, or full name and that ambiguous names trigger a disambiguation prompt. The description adds nothing further about either parameter, so the baseline 3 applies.

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

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

States a specific verb (save), resource (note/check-in), scope (one person in the workspace) and the observable effect (appears on their EQIQs profile). The word 'save' cleanly separates it from the sibling list_notes, which only reads notes.

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

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

Gives two concrete triggers — after 1:1s, or when the user asks to remember something about someone — which is real usage context rather than an implied one. It stops short of naming when-not to use it or pointing at an alternative such as list_notes for retrieval.

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 mutation/safety profile (readOnly=false, destructive=false, idempotent=false), so the bar is lower. The description adds genuinely new context — a cost of 1 unit and the fact that traits can be pre-seeded — though it does not warn that non-idempotent creation can produce duplicate profiles.

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 sentences, front-loaded with the core action, then the disambiguation, then the return/cost facts. 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 9-param create tool with a full output schema and safety annotations, the description covers purpose, alternative, return id and cost. The only gap is duplicate-handling behavior implied by idempotentHint=false.

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

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

Schema coverage is 100% and each of the 9 parameters is documented in-schema, so the schema does the heavy lifting. The description only gestures at traits ('e.g. an MBTI type') without adding format or constraint detail beyond what the schema already states.

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 ('Add a new person to the user's workspace') and explicitly contrasts with the sibling invite_person, so an agent can distinguish the two without opening either schema.

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

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

Gives an explicit routing rule: use invite_person instead when the person should self-assess. It also scopes the case where pre-known traits exist, so when-to-use and when-not-to-use are both covered.

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/openWorld/destructive, and the description layers on non-obvious behavior: metered cost of 5 units, elevated latency, privacy weighting per context (business withholds love language, attachment style, DOB), and disambiguation behavior when a name matches multiple people. These are exactly the operational traits annotations cannot express.

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 compact sentences, front-loaded with the premium/scope qualifier, then the privacy constraint, then cost and latency. Zero filler and nothing buried.

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 no explanation. For a 6-parameter tool with pair mode and context weighting, the description covers cost, latency, privacy behavior, and audience limits; the only thin spot is not restating accepted identifier forms, which the schema already handles.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the context enum's withholding rules and the compare_with pair trigger. The description reinforces pair mode and framework synthesis but adds no format, syntax, or default semantics beyond the schema; baseline 3 applies.

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

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

States a specific verb (write) and resource (plain-language coaching narrative), names the person/pair scope modifier (compare_with), and identifies the synthesis source ('all 21 frameworks'). No sibling tool covers narrative generation, so the tool is unambiguously distinguishable from the rest of the set.

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

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

Gives a clear trigger for pair mode ('when compare_with is given') and an explicit exclusion ('Hiring or candidate-screening audiences are intentionally not supported'), plus cost/speed signals ('Slower than other tools. Costs 5 units.') that steer an agent toward cheaper tools when adequate. It stops short of naming a specific alternative to use instead, so not a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new behavioral context beyond annotations: the 1-unit cost and the fact that non-business contexts surface otherwise-withheld signals. It doesn't add rate-limit or failure behavior, but the added context is meaningful.

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 sentences: resource first, usage examples second, operational note last. No filler and front-loaded with the most important 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?

An output schema exists and annotations cover the safety profile, so return format and side-effect details are already handled. Cost and context-dependent withholding are disclosed; the only thin spot is the absence of explicit sibling routing given the large cluster of profile-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 100% and the single 'context' enum is fully documented in the schema, including what each value includes or withholds. The description does not restate or extend parameter semantics, so baseline 3 applies.

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

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

States a specific verb (return) and resource (the signed-in user's own EQIQs profile) and enumerates the payload contents (21-framework battery, labels, missing frameworks). The 'own'/signed-in qualifier implicitly distinguishes it from the sibling get_profile.

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

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

Gives concrete trigger examples ('what is my Enneagram type?', 'how do I come across at work?') that map user intent to this tool. It does not explicitly name a sibling alternative (e.g., how it differs from get_profile for another person), so it stops short of full when/when-not 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, idempotentHint and destructiveHint=false, so safety is covered; the description still adds non-structured behavior by disclosing the cost ('costs 1 unit') and the one-identifier-at-a-time constraint. It does not describe error behavior for missing profiles or ambiguous names, keeping it short of a 5.

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, no filler, with the core behavior front-loaded and the invocation constraint plus cost placed immediately after. Every clause carries information an agent needs.

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

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

An output schema exists so return-value detail is unnecessary, and the description covers scope, identifier constraint, read-only nature and cost. The only real omission is guidance on how the context parameter alters results, but that is documented in the schema itself.

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, but the description adds the exclusivity rule ('exactly one of profile_id, email or name') that the schema does not encode since required is 0. That constraint meaningfully extends the parameter documentation beyond what the structured fields provide.

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

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

States a specific verb and resource ('Return the full 21-framework read for one saved person') and even enumerates what the payload contains (per-framework results, plain-language labels, strengths, working-style notes). This clearly distinguishes it from siblings like list_profiles and get_my_profile.

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 tells the agent it must supply exactly one of profile_id, email or name, which is useful invocation guidance, but it never states when to reach for this tool versus get_my_profile, list_profiles, or prep_meeting. Usage is implied by the resource rather than explained.

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

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

Goes well beyond the annotations by disclosing the rate limit (10 invites per hour), the consent semantics ('Finishing the assessment is their consent to share results'), the cost ('Costs 1 unit'), and the self-invite/opt-out restrictions. The mutation profile it describes is consistent with readOnlyHint=false and idempotentHint=false.

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?

Four tight sentences, front-loaded with what the tool does, followed by email behavior, constraints, and cost with no filler. Every sentence carries operational 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 mutation tool with an output schema present, the description supplies everything an agent needs before calling: mechanics, delivery behavior, limits, exclusions, and cost. Return-value details are correctly left to 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?

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description's note that the link is returned when not emailed mirrors the schema's send_email description rather than adding new meaning. 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?

States a specific verb and resource ('Create a private invite link') and immediately scopes it to a defined outcome (invitee takes the EQIQs assessment and compares with the user). This clearly separates it from sibling tools like create_profile, start_assessment, and list_invites.

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?

Explains the two operational modes (EQIQs emails the link vs. the link is returned to hand over) and gives explicit exclusions ('no self-invites or opted-out addresses'). It stops short of naming sibling alternatives such as list_invites to check existing invites, but the when-to-use context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds genuinely new context by disclosing a cost of 1 unit per call. It does not, however, mention pagination or result-size behavior for the limit parameter.

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: the resource and scope come first, then the status set, then the read-only/cost note. Nothing redundant 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?

Purpose, status semantics, cost and read-only nature are all covered, and a rich output schema plus full parameter descriptions relieve the description of return-value and parameter explanation. Only minor gaps remain, such as any hint about result ordering or pagination.

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

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

Schema coverage is 100% and both parameters (limit, status enum with default) are fully documented in the schema. The description's mention of statuses repeats the enum values rather than adding filtering or format semantics, so the baseline of 3 applies.

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

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

States a specific verb and resource (list invites) scoped to invites the user has sent, and enumerates the status values. No sibling tool deals with invites, so the agent can distinguish this from list_profiles, list_notes and list_relationships without opening any schema.

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

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

The description implies when the tool applies (checking sent comparison invites and their status) but gives no explicit when-to-use vs when-not, nor any pointer to invite_person as the creating counterpart. Usage is inferable from the name and description rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds value the annotations cannot: a cost signal ('costs 1 unit') and deterministic ordering ('newest first'), both of which matter for planning and budgeting calls.

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 with zero filler, front-loading the resource, scope, and ordering before the usage hint. Every clause earns its place.

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

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

An output schema exists, so return shape needs no explanation, and the description covers scope, ordering, cost, and usage context. Nothing an agent needs in order to call this 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 description coverage is 100%, so the schema already documents 'person' (id/email/name plus disambiguation behavior) and 'limit' (1-100, default 20). The description only echoes the person scoping and ordering, adding no syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('Read the user's saved notes and check-ins'), scopes it to one person, and specifies ordering ('newest first'). An agent can distinguish this from siblings like prep_meeting or add_note without opening any schema.

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

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

Gives explicit context ('Use before a 1:1') and names a companion tool ('with prep_meeting'), which tells the agent when this belongs in a workflow. It does not state when-not to use it or name a competing alternative, so it falls short of a 5.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds genuinely new operational context: it is read-only and 'costs 1 unit', a billing detail no structured field provides. It doesn't discuss pagination behavior beyond the limit param, keeping it from a 5.

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

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

Two tightly packed sentences with zero filler: the resource and returned fields come first, followed by routing guidance and the cost note. Every clause earns its place.

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

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

For a 3-param, zero-required listing tool with full schema coverage, complete annotations, and an output schema to cover return values, the description supplies everything an agent needs: scope, routing to siblings, and cost.

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 parameters (including the context enum's business/romantic/friendship/coparenting weighting) are already documented in the schema. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the work.

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

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

States a specific verb (List) plus resource (people in the signed-in user's EQIQs workspace) and even previews the returned fields (id, name, department, framework completion count). This clearly separates it from get_my_profile or get_profile, which fetch a single 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?

Explicitly says to use it to find someone before calling get_profile, score_compatibility or score_team, giving a clear selection condition and naming the downstream alternatives. It doesn't state exclusions (e.g., when to prefer list_relationships or get_my_profile for a single known person), so it falls just short of a full 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuinely new operational context the annotations cannot express: the call costs 1 unit. It doesn't discuss pagination, but the cost disclosure plus the returned-fields hint ('score and the context') is real added value.

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 sentences with no filler: purpose first, then the usage trigger, then the cost/safety note. Every sentence earns its place and nothing is buried.

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 enumerated, yet the description still signals what comes back (scores and scoring context). For a zero-required-param read tool, purpose, usage, cost, and output shape are all 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?

Schema coverage is 100% with both parameters fully described, including the enum values for context, so the baseline is 3. The description's mention of 'the context it was scored in' loosely aligns with the context filter but adds no format, default, or bounds detail beyond the schema.

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

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

States a specific verb (List) and resource (saved compatibility pairings) and clarifies the payload: each pair's score plus the scoring context. It implicitly distinguishes itself from re-scoring, though it never names the sibling score_compatibility explicitly.

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

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

'Use to recall earlier comparisons without re-scoring' gives a clear situational trigger for selecting this over a fresh scoring call. It stops short of naming the alternative tool or stating exclusions, but the when-to-use is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious context beyond that: a cost of 2 units and the 1-12 attendee ceiling. It does not describe latency or what happens on partial failures, but the quota disclosure is a meaningful addition.

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: purpose and scope first, then input modes, then the read-only/cost footer. No filler, 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?

With an output schema present, the description needn't explain return values, and it covers scope, inputs, cost, and safety adequately for a read-only analysis tool. The only gap is sibling differentiation, which is not required for correct invocation but would help routing.

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 goal, members, and department, including the omit-members-when-using-department rule and the department match/refusal behavior. The description's 'Name attendees or pass a department' largely restates what the schema provides, so the baseline 3 applies.

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

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

The description states a specific verb and resource — 'Build a meeting prep brief' — and details the output (how to communicate with and persuade each attendee, risky pairings) plus the scope (1-12 attendees). This is clearly distinguishable from siblings like score_team, score_compatibility, or generate_narrative.

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 the use case (preparing for a meeting) and gives the two input modes ('Name attendees or pass a department'), which is useful. However, it never states when not to use this tool or which sibling to prefer for adjacent tasks like compatibility scoring or team analysis, leaving routing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description's 'Read-only' is redundant. What it does add beyond structured data is the cost ('costs 1 unit'), which an agent needs before invoking, and confirmation that the output is explanatory (rationale + tips) rather than a bare number.

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

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

Three sentences, each load-bearing: what you get, which sibling to use instead, then the governance/billing caveat. The output detail is front-loaded and nothing is padded.

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

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

An output schema exists, so return values need not be re-explained, and annotations carry the safety profile. The description still covers the remaining agent-facing unknowns: pair-size routing, cost, and the decision-support limitation.

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 person_a/person_b resolution rules (id, email, or full name; disambiguation instead of guessing) and the context enum weighting are already documented. The description adds no further parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb+resource (score two people's working/relating compatibility) plus the concrete output shape: 0-100 score, visual card, sub-scores, rationale, tips. It explicitly distinguishes itself from the sibling score_team by pair size, so an agent can route without opening either schema.

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

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

Names the exact selection condition ('Use for one pair; use score_team for three or more') and adds a governance constraint ('never the sole basis for hiring, promotion or termination'). Both when-to-use and when-not-to-rely-on-it are stated rather than inferred.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds the non-obvious cost ('2 units'), the 'decision-support only' caveat, and the department parameter's refusal behavior. It does not cover auth/permission requirements or pagination/limits, but the added cost and caveat context is real value 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?

Front-loaded with the core action and then a dense enumeration of outputs, with the alternative and cost trailing. Every clause carries information, though the output enumeration runs long enough that a reader must parse carefully.

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 and annotations cover safety, yet the description still supplies the decision-support caveat, unit cost, sibling alternative, and the shape of the result. Nothing an agent needs in order to select and call this 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 description coverage is 100%, so the schema already documents label, context, members, and department, including the enum semantics of context and the 2-12 bound. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('score a whole group') and enumerates exactly what the rollup contains: cohesion score, weakest shared dimension, best-connected/isolated members, pairings to watch, anchor pairings, role mix gaps. It also explicitly contrasts itself with the sibling score_compatibility, so an agent can route without opening schemas.

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

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

'Use instead of looping score_compatibility for 3+ people' gives an explicit alternative plus the numeric threshold that selects it. The schema reinforces member-vs-department selection, and the 'decision-support only' framing sets expectations about how results 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?

Annotations already declare readOnly/idempotent, so the bar is low, yet the description still adds real behavioral context: a cost of 1 unit, a consent precondition for personal frameworks, and an interaction protocol (one question at a time, verbatim, A/B answers only). None of that is derivable from the structured fields.

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

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

Front-loaded with the core purpose and packed with no filler across four short sentences. It is dense — purpose, protocol, no-arg behavior, consent, and cost in one paragraph — but every clause carries 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?

An output schema exists, so return values need no explanation, and the description covers the remaining agent-facing concerns: the no-argument listing mode, consent gating, interaction protocol, and cost. Nothing needed to invoke it correctly appears to be 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% and the schema already documents the omit-to-list behavior, but the description adds value the schema cannot: per-value semantics that some framework values are 'personal' and require explicit user consent. It goes slightly beyond the baseline 3 for a fully documented single 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?

States a specific verb+resource (fetch the questions for one EQIQs framework) and immediately clarifies the delivery mode ('inside the chat'). It is clearly separable from siblings like submit_assessment, which presumably records results rather than starts a session.

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

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

Gives concrete when-to-use conditions: call with no framework to list uncompleted frameworks, and obtain explicit consent before personal frameworks (attachment, love language). It does not explicitly name the sibling that handles the opposite half of the flow (submit_assessment), so routing to alternatives is left implicit.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description earns credit for what it adds beyond them: the write overwrites a prior result for the same framework, the call costs 1 unit, and output is plain language. The overwrite notice is the key disclosure, though it sits slightly in tension with destructiveHint=false.

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 front-loaded sentences covering action, side effect, return, and cost, with zero filler. The overwrite constraint and cost are surfaced early rather than buried.

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

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

For a two-parameter mutation with an output schema present, the description supplies the prerequisite tool, the overwrite behavior, cost, and the return style. Return value details are legitimately left to the output schema; only the per-framework overwrite scope nuance could be sharper.

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 both parameters, including the A/B answer map and that framework must match start_assessment. The description reinforces the provenance of 'answers' but adds no format or shape detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('Score the answers') and ties it to the sibling tool that produces the input ('collected via start_assessment'), then names the effect ('save the result to the signed-in user's profile'). This clearly separates it from score_compatibility, score_team, and start_assessment without opening any schema.

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

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

The phrase 'answers collected via start_assessment' establishes the required upstream call and the precondition for use. It does not state exclusions (e.g., what to do for a different framework or when no assessment was started), but the workflow context is clear enough to invoke correctly.

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=false, so the safety profile is covered. The description goes beyond them by disclosing a cost ('costs 2 units') and the 'Decision-support only' framing, plus noting that thin data is surfaced alongside rankings. It does not describe refusal/failure modes beyond what the schema says about department.

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?

Four tight sentences with no waste: capability and output first, then the trigger phrase, then two short constraint statements. Nothing is buried or redundant.

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

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

With an output schema present, return values need not be explained, and the description still summarizes them usefully. Combined with 100% schema coverage, full annotations, and disclosed cost, an agent has everything needed to select and call this 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 kind, members, project, and department thoroughly, including the 2-12 bound and the department fallback behavior. The description restates the 2-12 range and the kind list without adding syntax, format, or interaction detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Rank 2-12 people for leading a kind of work'), names the four kinds of leadership, and describes the output shape (rankings with saved results behind each and thin-data flags). It is clearly distinct from score_team, score_compatibility, and get_profile in the sibling list.

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

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

Gives an explicit trigger phrase ('Use for "who should lead this project?"') and scopes the tool as 'Decision-support only', which tells the agent this is advisory rather than a decision-maker. It does not, however, name a competing sibling or state when to prefer score_team/score_compatibility instead, 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.