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?

Goes well beyond the annotations: discloses that certain accepted parameters are silently ignored and discarded, states the return value (new profile id), and gives a cost of 1 unit. The silent-drop behavior is a non-obvious trait an agent could easily get wrong.

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 short sentences, front-loaded with the action and its allowed fields, then the exclusion rule, then return value and cost. Every sentence carries decision-relevant information with no padding.

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 details need not be expanded, and the description still summarizes the id. For a non-idempotent create with 9 parameters, it covers creation scope, exclusions, alternative tool, cost and result — nothing essential is missing.

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

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

Schema coverage is already 100%, so the baseline is 3; the description earns a notch more by grouping the accepted type labels (MBTI, DISC, Enneagram) and flagging the trap parameters that are accepted but never persisted. It leaves email and department unmentioned, though the schema covers them.

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?

Names a specific verb and resource ('Add a new person to the user's workspace') and immediately scopes what can and cannot be set. It also names the sibling it is not (invite_person), so an agent can distinguish the two without reading 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?

Explicitly states the negative case — birthdate, attachment style and scores are never saved here — and points to invite_person as the correct alternative when the person must self-report. That is a clear when-to-use/when-not-to-use routing rule.

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

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

Beyond the readOnly/destructive/idempotent annotations, the description discloses pricing, latency relative to siblings, and a privacy behavior ('withholds personal-life signals' under business context). It does not explain the non-idempotent behavior hinted at by idempotentHint=false, leaving a small 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?

Four short sentences, front-loaded with the premium label and the core action, then the pair condition, then the privacy constraint, then the cost/latency caveat. No filler; every sentence 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?

With an output schema present, return values need not be described, and the description covers cost, latency, privacy scope, and ambiguity handling. It is nearly complete, though it leaves the audience restriction's rationale to the schema rather than stating it for the agent's decision-making.

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

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

Schema coverage is 100%, so the schema already documents focus, length, person, context, audience, compare_with, and confirm_cost in detail. The description only adds the pair-mode framing for compare_with, which is largely duplicative, 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 artifact ('write a plain-language coaching narrative'), the scope ('for one person, or for a pair when compare_with is given'), and the synthesis basis ('all 21 frameworks'). This is clearly distinct from siblings like get_profile, prep_meeting, or score_compatibility.

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 clear selection context: single vs pair mode via compare_with, context gating ('Business context stays on working behavior only'), and a trade-off warning ('Slower than other tools. Costs 5 units'). It does not explicitly name a cheaper alternative tool to use instead when speed or cost matters, so it stops short of 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 read-only, idempotent, non-destructive, and closed-world. The description adds value beyond these by disclosing the cost ('costs 1 unit'), the consent prerequisite for personal frameworks, and the exact interaction protocol (one question at a time, A/B only). It does not cover rate limits or error behavior, but the added context is substantial.

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, then usage instructions, then constraints and cost. Every sentence serves a purpose and the description is tight, though slightly dense with multiple imperatives in a row.

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

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

Given the output schema exists (so return values need no explanation) and annotations cover safety/idempotency, the description supplies the missing behavioral and consent context. The only notable gap is failing to clarify the 'context' enum parameter, but overall it is sufficiently complete for correct invocation.

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

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

Schema description coverage is 67%, so the schema documents two of three parameters. The description adds meaning for 'framework' (omitting it lists remaining frameworks) and for 'personal_consent' (explicit consent required for personal frameworks), but does not explain the 'context' enum (business/personal). This partially compensates for the coverage gap, warranting a baseline 3.

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 ('Get') and resource ('questions for one EQIQs framework') and clarifies the mode ('list what the user has not completed yet' when no framework is given). It does not explicitly differentiate from the sibling submit_assessment, but the start-vs-submit distinction is implied by 'so the user can take it inside the chat'.

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 clear operational context: ask questions one at a time, word for word, accept only A or B; call with no framework to list remaining frameworks; personal frameworks need explicit consent. It lacks explicit when-not-to-use or a direct comparison to alternatives like submit_assessment, but the usage conditions are well specified.

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

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

Annotations cover readOnly=false, idempotent=true, destructive=false, so safety is largely declared. The description adds genuinely new operational context: it overwrites a prior result for that framework, costs 1 unit, and returns plain-language output. There is mild tension between 'overwrites an earlier result' and destructiveHint=false, but overwriting one's own saved result for a framework is consistent with idempotentHint=true and not a true contradiction.

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

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

Three tight sentences, front-loaded with the core action and effect, followed by return format and cost. No filler; 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 needn't be explained, and the description still notes plain-language results. It covers workflow origin, overwrite behavior, and billing cost. The one gap is no guidance on personal_consent, which the schema documents but the description never reinforces for a write that saves personal data.

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 75%, so the schema already documents answers, framework, context, and personal_consent. The description adds little parameter-level detail beyond implying the framework key ('for that framework'); it never mentions the consent or context parameters, 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?

Specific verb pair (score + save) and a precisely named resource (answers collected via start_assessment), with the effect on the user's profile stated. It clearly distinguishes itself from its sibling start_assessment by describing what happens to that tool's output.

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 establishes the prerequisite and sequence explicitly: it scores 'answers collected via start_assessment' and ties the framework key back to that call. It gives clear context but no explicit exclusions or 'use X instead' branching, so it stops 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 cover read-only, idempotent, non-destructive, and closed-world traits. The description adds useful non-annotation context: it costs 1 unit, is decision-support only, and notably does not rank people — an important behavioral trait for a tool named suggest_lead.

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

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

Three short sentences with no wasted words. The core scope and the key non-ranking constraint are front-loaded, though the first sentence is somewhat dense.

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 already explains return values, and annotations cover safety. The description adds cost, decision-support framing, and the non-ranking behavior, leaving little missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description restates the 2-12 member limit and the four work kinds, adding minimal meaning beyond what the schema provides.

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

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

The description states a specific purpose: discussing leadership considerations for a group of 2-12 people, with optional voluntary work kinds, and explicitly notes it does not rank people. This distinguishes it from scoring siblings like score_team or score_compatibility, though no sibling is named.

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 says 'Decision-support only' and implies the tool is for exploring leadership considerations rather than making final decisions, but it never explicitly states when to use this tool versus alternatives such as score_team or score_compatibility. Usage is implied rather than directed.

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