Applystead

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, so irreversibility and external effect are covered. The description adds genuinely new behavior: on the approve_only path the member has no packet and Applystead both prepares and sends it, meaning the send is not preceded by member packet review, which is not derivable from annotations or schema.

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

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

A single front-loaded sentence that leads with the action and exclusivity claim, then the two input pathways. It is dense with nested parentheticals and reads as a run-on, but every clause carries load-bearing 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 high-stakes, non-idempotent mutation with no output schema, the description covers both call shapes and the source of every non-required input. It omits what the agent should expect on success/failure and does not warn about repeat invocation given idempotentHint=false, which leaves a modest gap.

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

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

Schema description coverage is 100%, so the per-field baseline is 3. The description adds relational semantics the schema lacks — that the three digest/preparation fields travel together as one packet and that approve_only is the mutually exclusive alternative with no packet — plus the origin of each value (get_applications packet).

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 ('Sends one application to the employer') and explicitly claims exclusivity ('the only tool that applies'), so the agent can distinguish it from all sibling manage_*/get_* tools without opening a 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?

Clearly routes between the two invocation modes: the packet path (preparation_id + review_digest + authority_digest from get_applications packet) versus approve_only for a job marked approveOnly in get_applications ready/approvals. It names the upstream tool that supplies the inputs but does not state prerequisites (e.g. must a packet be reviewed first?) or failure conditions.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds the tool's identity as a coaching assistant but nothing beyond that — no note on latency, session continuity, or how modes differ behaviorally.

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

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

A single well-formed sentence with zero filler, front-loading the actor and the action. Nothing could be trimmed without losing meaning.

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

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

For a tool with rich enum parameters, no output schema, and full annotation coverage, the description is thin but the structured fields carry the load. It does not clarify what Otto returns or how 'plan'/'coach' modes differ in practice, leaving some agent uncertainty.

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 five parameters (including the mode/topic enums) are already documented in the schema. The description's mention of 'search, an application or a company' loosely echoes company_slug/application_id but adds no syntax or format detail beyond what the schema provides. 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 (Ask) and resource (Otto, a job search coach), and scopes the subject matter to the member's search, an application, or a company. It is clearly distinguishable from the CRUD-style siblings, though it relies on the branded name 'Otto' which the description helpfully glosses.

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?

Implies when to use it by naming the topical domains (search, application, company), but gives no explicit when-not guidance or pointers to alternatives. There is no sibling that overlaps, so the omission is less costly, but the agent still gets no signal on what Otto is not for.

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/no-open-world, so the safety profile is covered. The description adds real behavioral context beyond that: results reflect the state 'when Applystead last read it' (staleness), and untracked postings come back as 'unknown' rather than an error — both material for interpreting the result.

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

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

The first sentence front-loads the key outcome, but the final sentence explaining that 'Apply with Applystead opens an Applystead account that tailors a résumé...' is promotional context that does not help an agent invoke this read-only check. The opening is also a sentence fragment, weakening structure.

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 no output schema, the description carries the burden of explaining returns, and it does so by naming the tracked/open/unknown states and the pay field. Error handling and any rate-limit or auth caveats are absent, but for a one-parameter read tool the coverage is largely sufficient.

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

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

Single parameter with 100% schema description coverage, so the schema already documents the https URL fully. The description's phrase 'employer's job posting link' restates the schema without adding format or constraint detail, making the baseline 3 appropriate.

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

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

The description states what the tool reports — whether a job posting link was still open when last read, plus its listed pay — and enumerates the possible outcomes (tracked/open/unknown). It is phrased as a return-value fragment rather than an action verb, and it never contrasts itself with siblings like get_jobs or search_jobs, but the resource and check semantics are unmistakable.

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

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

There is no when-to-use guidance: nothing says to call this before applying, to verify a link, or how it relates to get_jobs/search_jobs/apply_to_job. The mention of 'Apply with Applystead' is contextual background, not routing advice.

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

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

Annotations already declare destructiveHint=true and openWorldHint=false, so the description's added value is the disclosure that deletion is gated behind an emailed confirmation code — a required auth/verification step not visible in the annotations or schema. It still omits what happens to the account's data and whether deletion is reversible.

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

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

Two tight sentences, front-loaded with the destructive scope before the action mechanics. Nothing is redundant with the title or the enum listing.

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 high-stakes destructive tool with no output schema, the description covers the workflow and parameter discovery adequately, and annotations cover the safety profile. It stops short of stating consequences (data loss, irreversibility, whether the account can be restored), which an agent invoking confirm should know.

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

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

Schema coverage is only 50% and the enum values carry no per-value text, but the description explains what send_code and confirm mean and provides a discovery path for the undocumented nested params ('call with action "help" for each action's fields'). That meaningfully compensates for the gap, though the actual param fields remain unnamed.

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 (delete the member's Applystead account) and immediately names the mechanism's two actions, send_code and confirm. It is unambiguous against siblings like get_account or update_profile, none of which share this destructive scope.

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

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

The description makes the required sequencing explicit: send_code emails a code, confirm deletes with it, and 'help' lists each action's fields. That tells an agent which action to call first, but it offers no when-not guidance or warning about the irreversibility of confirm.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds essentially nothing beyond that: no note on what 'full export' returns, no data-volume or rate-limit caveats, no permission requirements, and 'help' is already exposed in the schema enum. It mostly restates the action list rather than disclosing behavior.

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

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

Two sentences, front-loaded with the resource, and reasonably efficient. The action list appears redundantly in the prose sentence and again as 'Actions: ...', which is minor waste but not bloat.

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?

As a nine-action dispatcher with a free-form nested params object and no output schema, the description is thin: it never states what each action accepts or returns, relying on a 'help' round-trip. Because there is no output schema, return values are out of scope, but the per-action input contract is still 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?

With schema coverage at 50% (action has no description; params does), the description needs to compensate. It does enumerate every action value, but that merely duplicates the enum, and it explicitly defers per-action field semantics to action 'help' instead of describing them. Partial compensation, no added field-level meaning.

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

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

The description names the resource (the member's account) and enumerates the facets it exposes via the action enum, so an agent knows this is a multi-action read surface. It does not explain how it differs from overlapping siblings like get_membership, get_profile, or whoami, which lowers it below a 5.

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

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

There is no guidance on when to choose get_account over get_membership/get_profile/whoami or the manage_* counterparts. The only procedural hint is 'Call with action "help"', which explains internal discovery rather than usage against alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the mapping of the three actions to categories of answer data, and says nothing about result size, pagination, or permissions. No contradiction, but modest added value over annotations.

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

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

Two compact sentences with no filler, and the resource scope is front-loaded ahead of the action list. It is appropriately sized, though the second sentence is essentially a pointer rather than 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 dispatcher tool with a nested freeform params object, no output schema and a required help call, the description tells the agent how to obtain field definitions but leaves the callable parameters undocumented up front. This is a workable pattern but forces a discovery round-trip to invoke the tool correctly.

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

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

Schema coverage is 50%: the action enum is self-documenting, but the freeform params object (additionalProperties=true) is entirely opaque. The description partly compensates by associating library/finished/ask_library with answer categories, but it explicitly defers field-level detail to a runtime "help" call rather than explaining the parameters.

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

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

The description names the specific data retrieved (saved answers, finished questions, questions about them) and enumerates the three actions, so an agent knows this is a read tool for answer content. It is clear enough to distinguish from most siblings, though it never contrasts with manage_answers, which is the natural write-side counterpart.

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

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

There is no guidance on when to choose this tool over alternatives such as manage_answers, nor any prerequisite or exclusion statements. The only procedural hint is to call action "help", which is about discovering fields, not about selecting the tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the safety profile, so the bar is lower. The description usefully discloses the dispatcher pattern and the cross-tool data dependency for apply_to_job, but says nothing about pagination, return shape, or rate limits.

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

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

The facet list in the first sentence and the action list in the second sentence largely overlap, so some of the prose is redundant. It is front-loaded and compact, but the enumeration style reads as dense keyword stuffing rather than clean structure.

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 10-action dispatcher with no output schema and a free-form params object, the description is adequate but thin: an agent cannot tell what 'packet', 'job_page', or 'live' return without a runtime help call. It exposes the discovery mechanism but leaves per-action behavior and return context unexplained.

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

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

Schema coverage is 67% with one enum-bearing dispatcher param and a free-form 'params' object; the action enum itself documents the selectable operations. The description adds real value by telling the agent to call action 'help' to enumerate each action's fields, but it inlines none of those field semantics, so it only partially compensates for the opaque params object.

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

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

The description names the resource (applications) and enumerates the scope it covers, with an explicit action list that makes the tool's breadth concrete. It distinguishes itself partially by referencing that packet data (preparationId/reviewDigest/authorityDigest) is what apply_to_job needs, though it never draws the line against the manage_applications write counterpart.

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

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

Usage is implied rather than stated: the mention that packet carries digests 'apply_to_job needs' hints at a pre-apply workflow, and the help-action pointer tells the agent how to discover per-action usage. There is no explicit when-to-use/when-not guidance and no routing against siblings like manage_applications.

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

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

The annotations already declare readOnly=true, idempotent=true and destructive=false, so the safety profile is covered. The description adds the 'help' discovery pattern and the multi-action dispatch model, which is useful, but says nothing about what each action returns, pagination, or rate behavior beyond the annotations.

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

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

Two tight sentences with the resource list front-loaded and the help instruction following. Nothing is padding, though the sentence fragment structure ('The interview assistant's settings...') reads as a noun phrase rather than a complete directive.

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?

This is a nested-object dispatcher tool with no output schema, and the description offloads per-action field knowledge to a runtime 'help' call. That escape hatch keeps it from being inadequate, but an agent cannot act on 'settings', 'devices', or 'recording' without first issuing a second call, so the definition is only minimally self-sufficient.

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

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

Schema description coverage is 67% and the enum is already present in the schema; the description merely repeats the action values (settings, devices, recordings, recording) and points to 'help'. The 'key' parameter is never explained in the description, and 'params' semantics are deferred entirely to a help call rather than clarified here.

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

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

The description names the resource ('the interview assistant') and enumerates the readable sub-resources (settings, paired devices, call recordings), and the title supplies the verb 'Read'. This lets an agent distinguish it from the write-side manage_assistant, but the description never names that sibling explicitly, so differentiation relies on inference.

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 explains the dispatch mechanic ('Call with action "help" for each action's fields') and lists the valid actions, implying how to invoke it. However, it gives no guidance on when to choose get_assistant over manage_assistant or the other get_* tools, and no prerequisites are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds that it exposes settings and résumés and documents the 'help' discovery action, which is modest context. It does not describe return format or what the settings object contains.

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 short sentences with no padding, and the resource is named first. The phrasing is slightly awkward but there is no wasted text.

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

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

For a read tool with nested params and no output schema, the description is thin: it names the resource and defers field details to a 'help' call rather than explaining what the settings action returns. The annotations carry the safety context, so this is minimally adequate.

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

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

Schema coverage is 50%; the action enum (settings, help) is already in the schema. The description somewhat reinforces the action concept and points to 'help' for field discovery, but adds no concrete semantics for the open-ended 'params' object beyond what the schema 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?

The description is a noun phrase ('The member's Auto apply settings and résumés') with no explicit verb, forcing the agent to infer that it reads/retrieves. It does distinguish itself from the update_auto_apply sibling only via the tool name and the readOnly annotation, not through the text. The 'Actions: settings' fragment is terse and unclear.

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

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

There is no guidance on when to use this tool versus update_auto_apply or the other get_* tools. The only actionable instruction is to call action "help", which is a discovery hint rather than a usage condition.

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 the safety profile is covered structurally. The description adds nothing about side effects of the odd actions (e.g. whether connect_link produces an authorization URL or schedules something), and mentions no auth or rate-limit behavior.

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

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

It is short, but the sentence order is odd: a long noun list precedes the actual action enumeration, and the action list duplicates the schema enum verbatim, spending words without adding meaning. The one genuinely useful sentence is the help pointer at the end.

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 nine-action dispatcher with a nested, free-form params object and no output schema, the description does not explain what non-obvious actions such as event_context, schedule_sources, or connect_link actually return or require. An agent must call help before it can reliably choose an action.

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 75%, so mail_message_id and calendar_event_id are already well documented in the schema. The description's action list simply repeats the enum, and the nested 'params' object's action-specific fields remain opaque in both places — the agent must invoke help to learn them, which the description does correctly point to.

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

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

The description names the resources covered (member's calendar, events, mail invitations, job search schedule, calendar-connect page) and enumerates the actions, so the agent can tell this is a multi-action read surface. It is distinguishable from manage_calendar only via the read/write naming convention, not from any explicit statement.

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

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

No when-to-use guidance beyond 'call with action help for each action's fields'. There is no routing advice versus manage_calendar for mutating calendar operations, and no hint about which action corresponds to which user intent.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive). The description adds behavioral context about what the response contains: company page, newest open jobs, Apply links, and an explanation of the Apply with Applystead flow. However, it doesn't describe pagination, result limits, behavior when the company is not found, or what 'newest' means quantitatively.

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

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

The description is two sentences but the second sentence is largely promotional explanation of the Apply with Applystead feature rather than operational guidance for invoking this tool. The core purpose is not front-loaded; the agent must parse through feature marketing to understand what gets returned. It earns partial credit for being brief.

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

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

For a read-only tool with full schema coverage and annotations handling safety, the description covers return content but omits error behavior, pagination, limits, or edge cases. The Apply with Applystead explanation is arguably out of scope for this specific tool. Adequate but with clear gaps for an agent needing to call it correctly.

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

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

Schema coverage is 100% and the single parameter has a complete description including format alternatives (name or slug), length constraints, and required status. The description adds no parameter information beyond what the schema provides, which is the correct baseline when schema does all 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+resource ('A company's open roles and company page'), clearly distinguishing it from get_jobs and search_jobs which are generic job queries. However, the phrasing is awkward and buried in marketing language rather than front-loading the core purpose. An agent can infer it retrieves company-scoped job listings but the description could more directly state this.

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

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

No explicit guidance on when to use this tool vs get_jobs, search_jobs, or check_job_posting. The description never names alternatives or conditions that select this tool. The agent must infer from the name that this is company-scoped, but nothing confirms that inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only a resource inventory; it says nothing about auth requirements, pagination, or what 'API balance and usage' returns, so it adds modest value beyond the annotations.

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

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

Very brief and front-loaded, with the resource list first and the help hint last. It is a noun fragment rather than a full sentence ('Connected apps, API keys...'), which costs a little clarity, but nothing is padded 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?

There is no output schema and the params object is free-form, so the help-action disclosure is the key completeness mechanism and it is present. That said, an agent still cannot tell from the description alone what the list response contains or how it relates to manage_connections.

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 50%: the action enum is self-documenting, and the params object carries its own description. The description reinforces the discovery pattern by telling the agent to call action "help" for each action's fields, which compensates partially for the untyped additionalProperties params, but adds no field-level semantics.

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 enumerates the resources it exposes (connected apps, API keys, webhooks, API balance and usage) and the supported action (list), so an agent knows what it reads. However, it never explicitly distinguishes itself from the sibling manage_connections, leaving the read-vs-write boundary to be inferred from the get_ prefix and annotations.

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

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

Usage is implied by the 'list' action and the read-scoped resource set, and the description gives a meta-hint to call action "help" for field discovery. It offers no explicit when-to-use guidance and does not route the agent to manage_connections for mutations.

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 fully cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the burden is lightened. The description contributes one genuinely new behavioral fact — the Premium eligibility requirement — but says nothing about what a list returns, pagination, or that person requires a key.

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 short, front-loaded sentences with no filler; the resource and available actions come first. The help-invocation note is somewhat redundant with the schema's params description, costing a little.

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 multi-action dispatcher with a nested freeform params object and no output schema, the description is thin: it does not say what person requires, what list returns, or how many contacts to expect. The Premium note and help pointer are helpful but not sufficient to fully guide invocation.

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

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

Schema coverage is 67%: the action enum is self-explanatory and person_key carries its own description and pattern. The description adds the help-action discovery mechanism, which is useful, but it does not explain the freeform params object or how it differs between list and person.

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

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

The description names the resource (the member's contacts and one person's profile) and enumerates the actions (list, person), so an agent can tell this reads contact data rather than mutating it. It does not name the manage_contacts sibling as the write counterpart, so sibling differentiation is only implicit.

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 tells the agent how to discover per-action fields (action "help") and flags a Premium gate, which is useful context. It never states when to use this versus manage_contacts, get_outreach, or get_profile, so routing is left 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds only the action enumeration, which already exists in the enum, plus the help pointer. No return shape, no auth or rate-limit context — little 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?

Two sentences, front-loaded with what the tool returns before the action list. The enumeration partly duplicates the schema enum, but the text is tight and free of 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?

There is no output schema, so the description must carry return-value meaning; it names the resource families but never says what each action yields. With ten actions and a free-form nested params object, it leans entirely on a runtime 'help' call rather than being self-sufficient for selection.

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 50%: params is described but action is an undocumented enum of opaque values like 'analytics_home' and 'analytics_selection'. The description reproduces the enum list without explaining what any action means or returns, though the 'help' action is a meaningful discovery mechanism the schema does not describe.

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

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

The description states the resource set clearly — dashboard, stats, time-away summary, analytics and LinkedIn suggestions — so an agent knows this is a read-only insights multiplexer. It does not, however, differentiate itself from sibling read tools like get_membership or get_profile, leaving overlap to inference.

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

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

The only guidance is operational: 'Call with action "help" for each action's fields.' There is no statement of when to pick this tool over get_membership, get_profile, or other get_* siblings, and no indication of which action suits which question.

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 adds a genuinely useful constraint not present in structured fields: the tool is Premium-gated, and it advertises a self-documenting "help" action.

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 short sentences, front-loaded with the resource and scope, with the action list and help hint following immediately. No wasted words.

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

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

With no output schema, the description usefully names the return domains (setups, sessions, scores, question bank), and the help action compensates for the opaque params object. Action-specific behavior and result shapes are still left to runtime discovery, so it falls short of fully self-contained.

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

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

Schema coverage is 67%, so the schema already documents action, params and session_id. The description only lists action names and defers all field-level meaning to the "help" action, adding little semantics beyond the enum the schema already 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?

States a specific resource (practice interviews) with the data domains it exposes (setups, sessions, scores, question bank) and enumerates its three read actions. It is distinguishable from manage_interview_practice by the read-only action set, though it never explicitly contrasts itself with that sibling.

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 available actions and points to action "help" for field details, which is a discovery path rather than guidance. There is no explicit statement of when to use this read tool versus manage_interview_practice, so usage is only implied by the read-only verb set.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, covering the safety profile completely. The description adds nothing beyond that: no rate limits, pagination, auth requirements, or which actions return what. It simply restates the action list already present in the schema enum.

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

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

Two tight sentences with no filler, and the scope statement is front-loaded before the action list. The long comma-separated resource and action enumerations are dense but each token 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?

For a nine-action multiplexed tool with an opaque `params` object, no output schema, and nested objects, the description is thin but does provide the "help" escape hatch for runtime discovery. An agent knows how to begin but not what any individual action does or returns without a second call.

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

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

Schema coverage is 75%, so the schema already documents event_id and interview_id with format patterns and provenance. The description adds a useful pointer that per-action fields live behind action "help", compensating somewhat for the opaque `params` object, but it gives no direct semantic detail for the 9 action values beyond repeating the enum.

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 enumerates the resource domains it exposes (interviews, rounds, briefings, people, playbooks, company research, calendar feed, question sets) and lists the action verbs, so an agent can tell it is a multi-action read tool. However, it never states a single clear purpose verb+resource beyond the title, and the grab-bag scope makes it hard to distinguish conceptually from siblings like get_interview_practice or manage_interviews.

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

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

There is no when-to-use guidance, no mention of how this differs from manage_interviews (the apparent write counterpart), and no prerequisites. The only usage hint is the meta-instruction to call action "help" to discover fields, which is a discovery mechanism rather than selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds one genuinely useful behavioral detail — the self-discovery mechanism via action "help" — but says nothing about result volume, pagination, or per-action behavior.

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

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

Two compact sentences with zero filler; the action list is front-loaded and the help hint is a single clause. It could lead with a clearer verb+resource framing, but nothing is wasted.

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

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

For a six-action dispatcher with a nested, free-form `params` object and no output schema, the description is only partly sufficient: it names the actions and points to help, but leaves per-action inputs, return shape, and sibling disambiguation entirely unaddressed.

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

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

Schema coverage is 67%; the action enum and company_slug pattern are documented in the schema itself. The description's contribution is routing agents to action "help" for per-action fields, which is helpful given the opaque, additionalProperties:true `params` object — but it does not itself explain any parameter.

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

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

The description enumerates the six concrete operations (matches, newest, explain_match, market_map, market_map_jobs, company) so an agent knows exactly what this dispatcher covers. However, it opens with a loose noun list rather than a verb+resource statement, and it never distinguishes itself from overlapping siblings like search_jobs or get_company_jobs.

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?

Beyond the procedural hint to call action "help" for field lists, there is no guidance on when to use this tool versus search_jobs, get_company_jobs, or check_job_posting. The action names hint at distinct scenarios, but no exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description contributes a useful behavioral fact beyond that — the action='help' discovery mechanism — but says nothing about pagination, result shape, or any limits on the enumerated actions.

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

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

The leading noun phrase establishes scope quickly, but the 18-item action list is a long unpunctuated run-on that is hard to scan and arguably duplicates the schema's enum. The closing help instruction is well placed, but the list itself is bulky relative to the insight it delivers.

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

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

For a read-only, annotated, multi-action tool with no output schema, the definition gives an agent enough to act: full action enumeration plus an explicit self-documentation path via action='help'. The remaining gap is the absent distinction from manage_mailbox and any hint at what each action returns.

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

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

Schema description coverage is 80%, so the baseline would be 3, but the description adds real value by pointing twice to action "help" as the authoritative source for each action's fields, which is the only way to understand the free-form `params` object (additionalProperties: true). It does not, however, clarify how `key`, `index`, and `draft_id` pair with specific actions.

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

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

The description names the specific resource (the member's Mailbox) and enumerates 18 concrete read actions from threads to check_domain, which is far more informative than the bare title 'Read the Mailbox'. It does not, however, contrast itself with the sibling manage_mailbox, so the agent must infer the read/write split from the name and annotations alone.

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

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

There is no statement of when to use get_mailbox versus manage_mailbox, which is the obvious alternative in the sibling list. The only procedural hint is 'Call with action "help" for each action's fields,' which addresses invocation rather than tool selection, leaving the read/write routing entirely 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds that these are previews and confirmation links (i.e., non-mutating informational output) plus the self-describing "help" affordance, but says nothing about auth requirements, rate limits, or what the link actions actually return.

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

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

The "help" hint is well placed and useful, but the nine action names are recited verbatim from the enum, which is redundant bulk in an otherwise short description. Front-loading is weak because the lead sentence is a fragment that lists outputs before stating the tool's role.

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 dispatcher with an opaque additionalProperties object and no output schema, deferring field discovery to action "help" is a defensible strategy, and the annotations cover safety. Still missing is any indication of what the preview/link actions return or how the nested params differ per action, leaving the agent dependent on a second round trip.

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

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

Schema description coverage is 50% (the params object is documented, the action enum is not), and the description's enumeration of the nine action values merely duplicates the enum already present in the schema, adding no semantic detail. Its only genuine contribution is pointing at action "help" for the opaque nested params object, so it neither compensates for nor worsens the coverage gap.

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

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

The description identifies this as a read-only preview surface for plan/term/Premium upgrade changes, cancellation questions, and confirmation links, which separates it from the write-side manage_membership sibling. However the opening is a sentence fragment that lists returned artifacts rather than stating a clear verb+resource, so the purpose is inferred rather than declared.

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 tells the agent to call with action "help" to discover each action's fields, which is a usable invocation guideline, but it never states when to use get_membership versus manage_membership or when a preview should precede an actual change. Usage is only implied by the read-only framing.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. Beyond that the description adds genuine context: the feature is Premium-gated (an entitlement requirement the agent otherwise cannot know), preview returns the exact wire message a send would deliver, and campaigns carry an approval state. Pagination and rate limits are not disclosed.

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?

No filler sentences and the resource list is front-loaded before the action list and the help pointer. It loses a point for the run-on opening clause, which nests parentheticals so heavily that mapping prose back to individual actions takes effort.

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 ten-action dispatcher with an opaque `params` object and no output schema, the description names every action and gives the agent a discovery mechanism, but field-level and return-shape semantics are deferred to a second 'help' call rather than described here. It is workable but leaves meaningful gaps for a tool of this complexity.

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% and the action enum is fully documented in the schema, so the baseline is 3. The description's real contribution is enumerating the valid actions in prose and pointing to action "help" as the discovery path for the free-form `params` object, but it adds no syntax or field detail beyond the schema for campaign_id/outreach_id.

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

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

The description names the resource domain (outreach threads, cold-context people, suggestions, previews, mailbox campaigns) and enumerates the nine concrete actions, so an agent can tell what this tool covers without opening the schema. It is weaker on sibling differentiation: it never states that writes belong to manage_outreach, and the opening prose is a dense noun list rather than verb+resource.

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

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

Usage is only implied by the action names and the parenthetical glosses ('the exact message a send would deliver' for preview). There is no explicit when-to-use vs. when-not, nor any routing to manage_outreach or send_email for the write/send cases. The one concrete usage hint is 'Call with action "help" for each action's fields'.

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 the safety profile is fully covered. The description adds useful context by listing the data categories returned and the sub-action decomposition, but says nothing about pagination, ordering, or what happens to params for the help action. Adequate against a lower annotation-driven bar.

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

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

Two tight sentences: the first front-loads what data is returned, the second enumerates actions and the help affordance. Zero filler. It could be marginally sharper about the help mechanism, but the structure is sound.

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?

There is no output schema, so the description reasonably lists returned data categories and points to the help action for field discovery. However, for a multi-action tool with an opaque params object, it does not describe per-action inputs or return shapes, leaving the agent dependent on a discovery round-trip to call it correctly.

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

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

Schema coverage is 50%, and the params object is free-form (additionalProperties: true), so the description must carry weight. It does meaningfully explain the help escape hatch for discovering action fields, which the schema only gestures at, but it never describes what any action's params actually contain. That partial compensation lands at the baseline.

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

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

The description names the resource and its contents (member profile, job search preferences, saved questions, photo) and enumerates the three read actions, so an agent can tell this is the read-side counterpart to update_profile. It lacks an explicit verb in the description body (the verb only appears in the title) and does not name the sibling it complements, so it falls just short of a 5.

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

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

No when-to-use guidance is given. With siblings like update_profile, get_account, whoami and get_membership in scope, the description never says when to pick get_profile over those alternatives or when not to. The only procedural hint is 'Call with action help', which is a how-to, not usage 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 cover readOnly/idempotent/non-destructive/non-open-world, so the bar is lower, but the description adds genuinely useful context beyond them: 'nothing is saved', which resolves the ambiguity that actions named create_from_profile and export might persist data. It still omits any auth or rate-limit detail.

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

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

Two tight sentences with no filler; the resource scope is front-loaded and the action enumeration plus help pointer follow. The only blemish is the fragmentary, slightly awkward opening clause, which reads like a list rather than a sentence.

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 no output schema, the description should convey return behavior, and it only sketches it (résumés, a master résumé, a PDF/Word file) without describing format or structure. The help action offloads parameter discovery, but an agent still lacks return-value detail for a multi-action tool.

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

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

Schema coverage is 50% and the params object (additionalProperties=true) is only described by a pointer to the help action. The description restates the action list already present in the enum and offers the help mechanism for field discovery, so it does not compensate for the undocumented per-action fields.

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

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

The description enumerates the resources exposed (saved résumés, a profile-built master résumé, PDF/Word export) and the three read actions, and the title supplies the verb 'Read'. It implicitly contrasts with the sibling manage_resume_studio, but the opening is a verbless noun-phrase fragment rather than a crisp statement of purpose.

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

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

It gives a discovery instruction ('Call with action "help" for each action's fields') and the 'nothing is saved' caveat, which is useful context. However, it never states when to use this read tool versus the manage_resume_studio sibling, leaving the selection to inference from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the non-obvious fact that per-action parameter schemas must be discovered through a help action, but says nothing about error behavior, empty states, or what an unconfigured setup returns.

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

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

Two short sentences with the resource scope front-loaded and the action list immediately after; no filler. The opening clause ("Where first-time setup stands") is slightly awkwardly phrased, but nothing is wasted.

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

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

For a four-action dispatcher with no output schema, the description identifies what each action reads but never characterizes the shape or content of those returns, nor the relationship to run_setup. It is adequate to call the tool but leaves the agent guessing about results.

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

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

Schema description coverage is 67%: action (enum) and ingestion_id (with pattern and provenance from run_setup import_resume) are documented in the schema, while params is loosely specified. The description repeats the action names already present in the enum and points to the help action for field discovery, which is a modest addition rather than new semantic detail.

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

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

The description names the resource (first-time setup) and its readable facets — setup status, résumé import progress, and job previews — then enumerates the four read actions, so an agent knows exactly what it can retrieve. It doesn't explicitly contrast itself with the sibling run_setup, but the read-oriented framing makes the division reasonably inferable.

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 explains the tool's own dispatch mechanic — call action "help" to discover each action's fields — which is a useful invocation guideline. However, it gives no when-to-use/when-not guidance and never names run_setup as the mutation counterpart, so the choice between reading and running setup is left 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 carry the important profile (destructiveHint=true, readOnlyHint=false, idempotentHint=false), so the bar is lower. The description adds the action vocabulary but does not disclose which actions are irreversible, what 'delete' actually removes, or whether any action requires confirmation — context the annotations don't supply.

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 short sentences, front-loaded with the effect summary before the action list, with no filler. Listing all seven actions partly duplicates the enum, but it conveys the verb semantics the enum alone doesn't.

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

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

For a destructive, multi-action tool with no output schema and a free-form nested params object, the description gives a discovery path but no return-value or failure expectations, and no indication of which of the seven actions cause irreversible data loss. Adequate but with clear gaps.

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

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

Schema coverage is 67%, with 'params' being a free-form object (additionalProperties: true) whose fields are entirely undocumented in the schema. The description compensates partially by routing the agent to action 'help', but it never describes the per-action fields itself.

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 concrete verbs (improve, keep, edit, delete) against a named resource (answers in the library), and the action enumeration makes the tool's scope unambiguous. It implicitly separates itself from the read-only get_answers sibling, though it never names that sibling 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?

The only real guidance is the discovery hint 'Call with action "help" for each action's fields,' which is useful but procedural rather than situational. Nothing says when to use this versus get_answers/manage_applications, nor any precondition for the write actions.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and non-idempotent, so the safety profile is covered. The description adds only a high-level enumeration of what each action does ('pass on one', 'edit its packet', 'rate the queue') and says nothing about reversibility, permissions, or side effects beyond the annotations, so added value is modest.

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 short sentences, with the action summary front-loaded before the enum listing and the help pointer. It is efficiently sized, though the trailing action enumeration and help note overlap with what the input schema already exposes.

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

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

For a destructive, multi-action dispatcher with a nested free-form params object and no output schema, the definition is thin: no per-action detail, no return description, and the only completeness aid is the pointer to the 'help' action. It is minimally viable rather than rich, though the absence of an output schema excuses missing return semantics.

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

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

Schema coverage is 67% and the nested 'params' object is effectively opaque. The description's action list mirrors the schema's enum and its 'help' hint duplicates the schema's own params description, so it adds little parameter meaning of its own, though it does at least flag that per-action fields exist.

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

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

The description names a specific resource (job applications) and enumerates the five real actions, so an agent understands this is a multiplexed dispatcher rather than a single verb. It is clear, but it never distinguishes itself from near-neighbors like apply_to_job or get_applications, so the sibling differentiation is left to inference.

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

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

The only explicit routing guidance is 'Call with action "help" for each action's fields,' which is a discovery mechanism rather than a when-to-use rule. There is no statement of when to prefer this tool over apply_to_job, get_applications, or the other manage_* siblings, so usage is only implied.

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

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

Annotations already declare destructiveHint=true, non-idempotent and openWorld=false, so the agent knows this tool can cause damage. For a multi-action dispatcher that context is coarse though: the description does not say which specific actions are irreversible (delete_recording vs update_settings), which is the key behavioral fact an agent needs here. It adds action granularity but not per-action risk.

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 filler, and the action enumeration is front-loaded right after the summary of what can be changed. Efficient for a dispatcher tool, though the final help sentence repeats the same instruction already present in the params schema description.

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 nested, free-form multi-action tool with no output schema, the description omits per-action parameters and per-action destructiveness, deferring both to a runtime "help" call. That is a deliberate design, but it leaves the description incomplete on its own for correctly invoking a destructive action.

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

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

Schema coverage is 67%: the key parameter is documented, but params is a free-form object whose shape depends on the chosen action. The description partially compensates by pointing to action "help" for each action's fields, which is a functional but indirect substitute for documenting params inline.

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

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

The description names a specific resource (the interview assistant) and enumerates the concrete operations via the action list (update_settings, remove_device, delete_recording, file_recording, unfile_recording). This lets an agent tell it apart from the read-only get_assistant, though it does not explicitly address the overlap with the sibling tool literally named update_settings.

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

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

Usage is implied through the enumerated actions and the instruction to call action "help" for field details, which is a genuinely useful operational hint. However, there is no guidance on when to prefer this tool over get_assistant or update_settings, and no when-not or precondition information.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so safety is partly covered. The description adds genuine non-obvious context: events are written to the member's own calendars and no invitations are sent, which disambiguates the RSVP/invitation actions from actual emailing. It does not describe reversibility or auth requirements for the destructive actions, so it is not 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?

Capabilities, scoping constraint, action list, and the help pointer are front-loaded and easy to scan. The 16-item action enumeration duplicates the schema enum verbatim and could arguably be trimmed, but it is efficient for a dispatcher tool and nothing is 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?

This is a highly complex tool (16 actions, nested params object, no output schema), yet the description mitigates the complexity by naming the scope, the side effects, and a discovery mechanism ('help') for per-action fields. Return values are not explained, but there is no output schema and the help affordance covers the biggest gap.

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

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

Schema description coverage is 80%, so most parameters carry their own documentation and the baseline is 3. The description only repeats the action enum (already in the schema) and defers field-level meaning to the runtime 'help' action, adding no per-action parameter semantics of its own. It therefore neither adds value nor compensates for the undocumented nested 'params' object.

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 resource (calendars/events/job search schedule) and enumerates all 16 supported actions, so an agent knows this is the write-side calendar hub. It clearly contrasts with the similarly-named read sibling get_calendar by emphasizing create/change/delete. It stops short of explicitly naming get_calendar as the read alternative, which keeps it out of 5 territory.

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

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

Usage is implied by the action names and the tool is a routing dispatcher, but there is no explicit when-to-use/when-not guidance versus siblings like get_calendar or manage_interviews. The one strong signal is 'Call with action "help" for each action's fields,' which tells the agent how to discover per-action parameters. That is a useful but narrow piece of guidance for a 16-action tool.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered structurally. The description adds which concrete resources get destroyed and where keys/webhooks originate (Agents & API), but says nothing about reversibility, confirmation, or auth requirements.

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

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

Three short sentences, front-loaded with the core destructive actions before enumerating the action names and the help affordance. Slight redundancy between listing the actions and pointing at help, but nothing is wasted.

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

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

For a multiplexed action-dispatch tool with a free-form nested params object and no output schema, the description covers the available actions and routes the agent to the "help" action for per-action fields, closing the main gap. It could say more about which id pairs with which action, but the schema covers that.

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 80% and the eight-hex/32-hex id formats plus their provenance are documented in the schema itself. The description restates the action enum values already present in the schema, adding only the "help" discovery hint, which the params field description also carries. Baseline 3 is appropriate.

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

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

The description names three specific verbs and their resources (disconnect a connected app, revoke an API key, remove a webhook), so the agent immediately knows this is the write/destroy counterpart to get_connections. It does not explicitly name get_connections as the read sibling, leaving that differentiation implied rather than stated.

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

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

Usage is implied through the enumerated actions and the pointer to action "help" for per-action fields, which is genuinely useful routing. However, there is no explicit guidance on when to use this versus get_connections, nor prerequisites (e.g., obtaining the id first).

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is carried by structured data. The description adds useful context (Premium requirement, the action model, and the self-documenting 'help' call) but does not disclose reversibility, what remove_all actually destroys, or auth requirements.

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

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

Compact and front-loaded: capabilities first, then the action list, then the discovery hint. Every sentence earns its place, though the enumerate-actions line partly duplicates the enum.

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 an action-dispatch tool with a nested free-form params object and no output schema, the description does enough to make the tool usable via the 'help' path and notes the Premium gate. It stops short of explaining the params contract or the destructive scope of remove_all.

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

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

With 67% schema coverage and an opaque additionalProperties params object, the description's main contribution is pointing to 'help' for field discovery - but that mechanism is already stated in the schema's params description. The action list merely repeats the enum, so little new meaning is added.

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

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

States a clear verb set (add, remove, import) and resource (the member's contacts), and enumerates the exact actions supported. It is distinguishable from the read-only sibling get_contacts, though it never names that sibling to route the agent 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?

Usage is only implied by the mutation verbs and the '(Premium)' gating note. It offers a 'help' action for field discovery but gives no when-to-use vs alternatives or prerequisites beyond the tier restriction.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact – that this is a Premium-gated capability – but says nothing about what delete/cancel actions destroy or whether they are recoverable.

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

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

Purpose is front-loaded, followed by the action inventory and the help tip in three tight sentences. The action list largely duplicates the enum in the schema, which is mild redundancy, but overall there is little wasted text.

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 12-action multiplexed tool with a nested params object and no output schema, the definition is largely self-sufficient: it names the capabilities, the Premium gate, and the help mechanism for per-action fields. It stops short of per-action guidance, but the help escape hatch covers the biggest hole.

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 80% and the three id parameters are well documented in-schema, but the free-form `params` object (additionalProperties: true) is the real gap. The description compensates by directing the agent to action "help" to discover each action's required fields, adding meaning the schema cannot express.

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

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

The description names a specific domain (interview practice) and enumerates every operation across setups, questions, and sessions, so the agent knows exactly what the tool covers. It does not, however, explicitly contrast itself with the read-side sibling get_interview_practice, which is the one thing keeping it from a 5.

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

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

It gives a concrete navigation aid – "Call with action 'help' for each action's fields" – but never states when to use this tool versus get_interview_practice or when-not to use it. Usage is implied through the action list rather than spelled out as a 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds little beyond that: it never flags which actions are destructive (detach_recording) or irreversible, nor notes that some actions (mark_invite_seen, rate_tracking) behave differently from the create/update framing. It does not contradict the annotations, but it leaves value on the table.

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

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

The purpose statement is front-loaded, which is good, but the 19-action enumeration largely restates the enum already present in the input schema, consuming most of the description's length without adding semantics. The help pointer is the one sentence that 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 20-action megatool with no output schema and a free-form params object, the description gives only action names plus a help-discovery escape hatch. Action names are largely self-describing and the help action provides a fallback, but there is no per-action meaning, required-parameter hint, or result behavior to help an agent choose correctly on the first call.

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

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

Schema description coverage is 86%, so the individual id parameters (check_id, event_id, invite_id, interview_id, follow_up_key) are already documented with cross-references to get_interviews. The description's 'call help' pointer for the free-form params object is useful but duplicates the schema's own property description verbatim, adding no new information.

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 opening sentence names specific verbs (create, update) and a broad resource set (interviews, rounds, notes, transcripts, recordings, etc.), and the action enumeration makes the tool's mutation scope concrete and distinct from the read-only sibling get_interviews. It stops short of a crisp single-purpose statement because 'create and update' undersells actions like score_round, mark_invite_seen, or rate_tracking, but the action list compensates.

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

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

No guidance on when to use this tool versus get_interviews or the other manage_* siblings, and no indication of which action to pick for a given intent. The only directive, 'Call with action "help" for each action's fields,' is a discovery mechanism for parameters rather than usage 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 destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description reinforces this implicitly by listing clearly destructive actions (delete_label, remove_attachment, disconnect_sender, cancel_domain_order), but adds no explicit statement of irreversibility, permissions, or side effects beyond what the annotations and action names convey.

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

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

The resource scope and the send_email exclusion are front-loaded before the long action enumeration, which is dense but necessary for routing a 22-action dispatcher. The first sentence is a run-on, but nothing is redundant.

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

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

For a complex, multi-action tool with a nested 'params' object and no output schema, the description supplies the action list and a help mechanism, which covers discovery adequately. It does not, however, explain return values or per-action effects, leaving meaningful gaps for an operation this broad.

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 83%, so the schema already documents key, draft_id, attachment_id and connection_id. The description's main contribution is directing the agent to call action "help" to discover the fields of the free-form 'params' object, which is modest added value over the schema's own note.

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

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

The description names the resource scope precisely (threads, labels, settings, forwarding, drafts, held/drafted replies, sending accounts, domain order, owned domain) and enumerates all 22 actions, so an agent knows this is the mailbox mutation dispatcher. It also names the sibling it is not (send_email), which aids differentiation. It stops short of a single crisp verb+resource because the surface is intentionally broad.

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

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

It explicitly routes the sending case away from this tool ('Sending is send_email') and points to action "help" for per-action fields, giving a clear entry path. However it does not distinguish against the read-side sibling get_mailbox or indicate which of the 22 mutating actions to prefer in overlapping situations.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the safety profile is covered. The description adds genuinely non-structured context: 'Payment happens on a page the member opens' (the agent never handles payment), that pricingAcceptance must be the exact accepted value, and that the member, not the agent, performs cancellations. It does not disclose what a checkout mutates or the result of a completed purchase, keeping it at 4.

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

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

The content earns its place, but it is delivered as one long run-on sentence mixing actions, pricing sources, payment flow and cancellation policy before finally listing the action names. Front-loading the action vocabulary or splitting the policy text from the routing text would make it far easier to scan.

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

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

For a six-action destructive router with no output schema and only a generic params object, the description covers the essentials: the action vocabulary, where prices come from, that payment is member-side, and that cancellation is out of scope. The remaining gap — post-action return behavior and what each purchase changes — is a minor omission given the 'help' action exists for per-action fields.

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 50% and the action enum has no per-value description in the schema, so the description compensates by explaining what each action does and by pointing to action "help" for per-action fields. It also clarifies that params is free-form per action and that pricingAcceptance must be the exact accepted value. This is meaningful added meaning beyond the bare enum.

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 enumerates the six concrete actions (start_checkout, billing_portal, cancellation_feedback, buy_domain, buy_api_credits, buy_extra_campaigns) and states what each accomplishes, so an agent can tell it is a membership/billing action router rather than a read tool. It distinguishes itself from read siblings by naming get_account, get_membership and get_outreach as the pricing sources. It stops short of 5 because the opening sentence is a scattered list rather than a crisp statement of the tool's single job.

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

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

It gives strong negative guidance: 'Cancelling is never done through an agent' and routes the member to the Membership page on applystead.com — a clear when-not. It also tells the agent where to obtain prices before invoking (get_membership preview, get_outreach packs). It doesn't explain when to choose billing_portal vs start_checkout vs cancellation_feedback, so it falls short of explicit alternative selection.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, and the description's destructive verbs (discard, remove, cancel, close_thread) are consistent with that. It adds genuinely new behavioral context beyond the annotations: which capabilities require a Premium plan and the existence of a terms-acceptance prerequisite. It stops short of saying whether discard/cancel are reversible or what happens to already-sent campaigns.

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 capability enumeration before the Premium and routing caveats, which is the right order for a dispatcher tool. It is dense and long, but each clause maps to a distinct action or constraint, so little is wasted; the run-on sentence structure makes it slightly harder to scan than it could be.

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 13-action dispatcher with no output schema and a free-form nested params object, the description covers capabilities, tiering, prerequisites and cross-tool routing. The remaining gap is that per-action field requirements are deferred entirely to an extra action "help" call, which the agent must know to make before invoking a real action.

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 80%, so the baseline is 3, but the description adds real value by decoding opaque action names into behaviors (e.g. 'record the outcome' = resolve, 'redraft' = regenerate, 'close a thread' = close_thread) rather than just repeating the enum. It also documents the escape hatch for the nested 'params' object via action "help", though it never explains that object's shape directly.

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 (draft/manage) and resource (outreach messages to people at companies), then enumerates the full scope across two sub-domains (messages/threads and Mailbox campaigns). It explicitly carves sending out to send_email send_outreach/send_campaign, so an agent can separate this tool from the sibling that actually sends.

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 states the key routing rule ('Sending is send_email send_outreach or send_campaign') and discloses the Premium gate on sending, terms, outcomes and campaigns, which tells the agent when calls will fail. It does not, however, contrast itself with get_outreach (read side) or explain the ordering between accept_terms and the drafting actions, leaving some usage inference to the agent.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent behavior, so the safety bar is lower. The description adds one useful fact beyond them — that job links/descriptions are persisted with the account — but it does not warn that save may overwrite prior studio content, which is the key destructive risk.

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 verbs and only a few sentences, though the action names are effectively listed twice (once as verbs, once in the 'Actions:' line). Tight overall with minimal waste.

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

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

For a destructive multi-action dispatcher with a nested, undocumented params object and no output schema, the description covers the surface but leaves the destructive semantics and full parameter space to a help call. Adequate but with clear gaps.

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 50% and the nested params object is opaque. The description adds real value by specifying the mechanism to enumerate fields (action "help"), but it conveys no field-level semantics itself and defers everything to a runtime call.

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

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

The description names concrete actions (save, tailor, refine, read_job_link) and what each does at a high level, distinguishing this write/mutation dispatcher from the sibling read tool get_resume_studio. It is a multi-action conglomerate, so each verb is only lightly characterized, but an agent can tell what the tool is for.

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 tells the agent to call with action "help" to discover each action's fields, which is useful routing guidance, but it never says when to use this tool versus get_resume_studio or apply_to_job. Usage is implied rather than contrasted with alternatives.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds the multi-step sequence and the existence of a help/discovery action, but says nothing about what 'destructive' means here, whether steps are resumable, or what cancel_import discards.

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

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

The flow is front-loaded in the first sentence and the action list follows; it is short and free of filler. Slight redundancy in restating the actions after already describing them keeps it from a 5.

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 high-complexity orchestration tool with a dynamic nested 'params' object and no output schema, the description covers the happy path and the discovery mechanism, but omits sequencing requirements, auth/permission needs, and the consequences of the destructive/cancel actions.

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

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

Schema coverage is 67% and the enum already lists every action value, so the description's action list is largely redundant. The one real addition is pointing to action "help" as the way to discover the free-form 'params' fields, which the schema cannot enumerate — enough for baseline 3, not more.

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 gives a concrete verb+resource (run first-time setup) and enumerates the actual workflow steps and action values, so an agent knows this is a multi-step setup orchestrator rather than a read. It does not explicitly distinguish itself from the sibling get_setup (read vs. mutate), which holds it back from a 5.

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

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

Usage is implied by 'first-time setup' and the ordered flow (import → answer → approve → finish), but there is no explicit when-to-use/when-not guidance or comparison to get_setup/update_profile. The 'call with action help' pointer is invocation guidance, not tool-selection guidance.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context. It does so: results are ordered newest first, each result carries an Applystead job page link, an Apply with Applystead link, and a jobId that can be passed to manage_applications add_job. That forward-path affordance is genuinely useful and not derivable from annotations.

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

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

The first sentence is well front-loaded and earns its place. The trailing sentence about Apply with Applystead opening an account that tailors a résumé is product marketing rather than tool-selection information, and dilutes the definition.

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 no output schema, the description usefully sketches what a result contains (job page link, Apply link, jobId) and the ordering. It stops short of covering pagination/limit interaction or result shape in detail, but is largely sufficient 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 100% and all seven filters (kind, limit, query, company, pay_listed, remote_country, posted_within_hours) are documented in the schema. The description adds no filter syntax, default, or combination guidance, 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 ('Search open jobs'), plus meaningful scope ('posted on their own career sites, newest first'), which distinguishes it from aggregator-style job listings. It does not explicitly name siblings like get_jobs or get_company_jobs, so an agent must infer the boundary itself.

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

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

No when-to-use or when-not-to-use guidance relative to the many sibling tools (get_jobs, get_company_jobs, check_job_posting). The mention that a jobId feeds 'manage_applications add_job' describes a downstream action, not a selection rule for this tool.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the agent knows this mutates state irreversibly and reaches outside the system. The description adds real value by revealing that the tool's surface spans both true sends and a settings toggle (full_auto_replies turns automatic replies on or off), which is not visible from the name alone. It still omits what a successful send returns and any permission or throttling constraints.

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

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

Front-loaded with the purpose, then the action list, then the help affordance in two tight sentences. The long action enumeration earns its space because it is the tool's actual dispatch contract, though the list could have been ordered or grouped (sends vs. the auto-reply toggle) for faster scanning.

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

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

For a 7-parameter dispatcher with a free-form nested params object and no output schema, the description supplies the essential missing piece (how to learn each action's fields) and clarifies the mode-switching action. It stops short of describing return values or failure behavior, but with no output schema that is the main remaining gap rather than a fatal one.

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 86%, so the schema already documents key, draft_id, campaign_id, outreach_id and mail_message_id. The description compensates for the one real gap: the free-form nested 'params' object, by explaining that each action's fields are enumerated via action "help" — meaning the agent knows how to discover the per-action contract it cannot see in 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 and resource ('Send email from the member's Applystead Mailbox') and then enumerates the exact action surface (send_draft, reply, confirm_held_reply, send_ai_reply, full_auto_replies, send_outreach, send_campaign). An agent can immediately tell this is a single dispatch tool covering all outbound mail actions rather than one of the read-side siblings like get_mailbox or get_outreach.

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

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

Usage is implied by the action enum and the explicit 'Call with action "help" for each action's fields' hint, which is a useful operational instruction. However, there is no when-to-use/when-not guidance and no routing against alternatives such as manage_mailbox or manage_outreach, which the agent must infer.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds that résumés can be added or removed (a destructive sub-operation) and that sub-fields are discoverable via 'help', but does not say what precisely gets destroyed, whether changes are reversible, or any auth/permission requirements.

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

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

Two compact sentences, front-loaded with the purpose before the action list and the help pointer. Nothing is bloated, though the action enumeration largely duplicates the schema enum.

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 multi-action mutation tool with a nested, schema-less 'params' object and no output schema, the description is thin: it defers all field-level detail to a runtime 'help' call rather than surfacing it inline. Pointing at the discovery mechanism is a reasonable stopgap, but an agent cannot construct most calls from the definition alone.

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

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

Schema coverage is 67% and the enum of actions is already in the schema, so re-listing the action names adds nothing. The one genuinely useful addition is the guidance that 'help' lists each action's fields, which partially compensates for the opaque 'params' bag, but the description does not document resume_id or the per-action fields itself.

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 gives a specific verb+resource ('Turn Auto apply on or off... manage the résumés it uses') and enumerates the concrete actions, so the agent knows this is the mutation counterpart to the sibling get_auto_apply. It stops short of explicitly contrasting itself with that read tool, so it does not fully reach the 5 bar of sibling differentiation.

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 lists available actions and points to 'action "help"' as the discovery path, which implies how to invoke it, but never states when to use this tool rather than get_auto_apply or the other manage_* siblings, and gives no prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the safety profile is covered structurally. The description adds real context by listing the operatively destructive action (remove_photo) and the LinkedIn import capability, but says nothing about permissions, whether changes are reversible, or what happens if params are omitted. It does not contradict the annotations.

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

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

Front-loaded scope statement, then the action list, then the help hint — a sensible ordering with no filler. The action list duplicates the schema enum, which is mildly redundant but defensible as an at-a-glance routing aid for a multi-action tool.

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 an 8-action multiplexer with a free-form nested params object and no output schema, the description covers the action surface and provides a discovery path for the undocumented fields, which is the key gap an agent would hit. Missing details (per-action required fields, destructive-action warnings, auth needs) are handled only indirectly via `help`.

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

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

With only 50% schema coverage and a free-form `params` object whose fields are entirely undocumented, the description compensates by routing the agent to the `help` action to discover per-action fields. That is meaningful semantics beyond the schema. It does not, however, state which params are required per action or give any field examples inline.

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 gives a specific verb ("Change") and resource ("the profile") and enumerates the sub-domain it covers: job search, work authorization, answers, photo, and LinkedIn import. It clearly reads as a write-side counterpart to get_profile. It stops short of differentiating itself from the other update_* siblings for overlapping data (e.g. answers), so it is clear but not fully disambiguated.

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

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

The only usage instruction is the introspection hint "Call with action \"help\" for each action's fields," which is genuinely useful for driving the tool. However, there is no guidance on when to use this tool versus manage_answers, get_answers, manage_applications, or the other update_* siblings, even though save_answers clearly overlaps with manage_answers.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=false, and idempotentHint=false. The description adds no behavioral detail beyond this: it never says that delete_review destroys data, that redeem_voucher is irreversible, or which actions side-effect outside the account, even though listing those actions implies varied risk.

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-loads the purpose reasonably, but the second sentence re-lists all eleven enum values that are already fully specified in the schema, creating redundancy. The first sentence also paraphrases many of the same actions, so the text carries duplication without new 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 ten-action dispatcher with a nested params object and no output schema, the description offers only the action names and a pointer to 'help'. It does not describe what any individual action does organizationally or what it returns, leaving the agent to rely entirely on the help call.

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

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

Schema coverage is 50%, with the nested 'params' object essentially undocumented. The description compensates partially by directing the agent to the 'help' action for per-action fields, but it repeats a hint already present in the schema's params description and adds no syntax or per-action field detail.

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 (Change) plus the resource (account settings) and enumerates the ten concrete actions plus the help action, so the agent knows exactly what this dispatcher covers. It is distinguishable from update_profile and update_auto_apply, though bundling unrelated operations like redeem_voucher and resend_verification_email under 'settings' is a slight mismatch of scope.

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

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

Provides one useful usage instruction — call action 'help' to discover each action's fields — but gives no guidance on when to choose this tool over siblings such as update_profile or manage_membership. Usage is only implied by the action list.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the remaining burden is small. The description does add the meaningful qualifier "connected" — i.e., the authenticated caller rather than an arbitrary user — but discloses nothing about caching, auth requirements, or failure modes.

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

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

A single compact sentence with no filler, and the key qualifier ("connected") is front-loaded. It is a noun phrase rather than a verb-led statement, which slightly weakens the framing but costs nothing in length.

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

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

For a zero-parameter, read-only tool with a full output schema, the return fields need not be re-explained and annotations carry the safety profile. The definition is essentially complete, with the only real gap being the absence of routing guidance versus sibling identity/profile 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-wise for the description to clarify or omit.

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

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

The description names the specific resource (the connected Applystead member) and enumerates the returned fields (id, name, email, plan), so an agent can tell what it obtains. It lacks a verb and does not differentiate itself from close siblings such as get_profile, get_account, or get_membership.

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

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

No when-to-use guidance is given, and no alternative is named or excluded despite several plausible siblings (get_profile, get_account, get_membership) that could also return identity data. The agent must infer that this is the cheapest identity check.

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