Evercraft Career Command

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds that the tool returns capability boundaries and supported actions, but it does not add details like response shape, rate limits, or authorization needs. This is acceptable because the annotations carry the behavioral burden and nothing contradicts them.

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

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

The description is a single front-loaded sentence with no filler, repetition, or wasted words. Every phrase contributes to defining what the tool reads and returns.

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 parameterless, read-only capability tool, the description is nearly complete: it states the read action and the broad categories of returned information. Since there is no output schema, the description carries the burden of indicating what comes back, and it does so at a useful but general level.

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

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

The tool has zero parameters and the schema fully documents that empty parameter surface, so the baseline of 4 applies. There are no parameter ambiguities to resolve, and nothing in the description misleads an agent about expected arguments.

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

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

The description uses the specific verb 'Read' and names a concrete resource: Career Command machine-commerce boundaries and supported premium practice actions. This distinguishes it from the interview-sprint sibling tools, which deal with offers, status, checkout, and actions. An agent can tell what this tool is for without needing the schema.

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

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

The description gives no explicit guidance about when to choose this tool over siblings, nor does it mention exclusions or prerequisites. It implicitly suggests using it when capability information is needed, but that is left to inference. No alternative tool is named or contrasted.

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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds a meaningful behavioral detail beyond those annotations: 'Creates no checkout or payment obligation,' which tells the agent that this tool has no side effects related to the checkout flow. This is useful context, even if partly redundant with the read-only hint.

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, each earning its place: the first states the action and resource, the second reinforces read-only status, the third adds the side-effect disclaimer. It is front-loaded with the verb and resource and contains no filler.

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

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

This is a simple, parameterless, read-only tool with annotations covering safety and idempotency. The description fully explains what the tool does, its non-mutating nature, and the absence of payment obligation. No output schema exists, so no return-value details are required.

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

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

There are zero parameters, and the schema has empty properties, so the description has no parameter burden. The baseline of 4 for a zero-parameter tool applies; the description does not need to add parameter-level detail because none exist.

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

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

The description states a specific verb ('Read'), a specific resource ('current Evercraft Interview Sprint terms'), and explicitly frames the operation as read-only with no checkout or payment obligation. This clearly distinguishes it from the sibling prepare_interview_sprint_checkout, which creates an obligation, and from get_interview_sprint_status, which reads status rather than terms.

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

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

The description gives clear context that this is a safe, read-only operation and contrasts it with checkout/payment obligations. It implies when to use this tool instead of prepare_interview_sprint_checkout, though it does not explicitly name alternatives or state when-not-to-use 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 establish read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond those annotations by stating the payment-verification dependency, the 7-day bounded token, and the 'remaining premium actions' payload. No contradiction with annotations.

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

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

The description is a single dense sentence with no filler. It front-loads the verification purpose, includes the critical payment condition, and states the returned payload, so every clause earns its place.

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

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

For a small read-only status tool, the description covers the precondition, the returned access token, the validity bound, and the remaining premium actions. It could be improved by naming the parameters and describing the unpaid-checkout case, but the essential selection criteria are present.

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

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

The schema has two required parameters with no descriptions and 0% schema description coverage, yet the description does not explain order_key or session_id. The Evercraft checkout context helps infer their domain role, but an agent cannot tell which identifier maps to which concept or what values are acceptable.

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

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

The description states a specific action (verify the Evercraft Payments checkout) and a precise result (return the 7-day Career Sprint access token and remaining premium actions). The 'only after provider-confirmed payment' condition also separates this from the checkout-preparation and action-running sibling tools.

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

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

The description clearly gives a timing precondition: call only after provider-confirmed payment. It does not explicitly name alternatives or contrast itself with siblings, but the payment-confirmation condition is enough to guide an agent's 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 flag this as non-read-only and non-idempotent; the description adds valuable context: the $19 price, the required human confirmation, and the warning that creating a checkout is not proof of payment. No contradiction with the annotations.

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

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

Two purposeful sentences with the precondition front-loaded and no filler. Every clause carries operational 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 two-parameter tool with annotations covering the write/side-effect profile, the description is nearly sufficient: it gives the precondition, price, secure context, and a key caveat about payment proof. The return shape is unspecified, but with no output schema the invocation path is still clear.

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

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

Schema description coverage is 0%, so the description must compensate. It does interpret user_confirmed_payment as the human's explicit agreement to pay $19, but it adds nothing about the email parameter beyond what the schema's format and pattern already state. Partial compensation for a simple two-parameter tool.

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

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

States a specific verb ('prepare') and resource ('secure Evercraft Payments checkout') with a clear precondition. It is readily distinguishable from the sibling get*/run actions even without naming them.

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

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

Gives a precise when-to-use condition: only after the human explicitly agrees to pay $19 for the 7-day Interview Sprint. It does not explicitly route away from sibling tools, but the precondition and the 'not payment proof' caveat provide clear usage context.

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

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

The description adds a meaningful behavioral fact beyond the annotations: calling this tool consumes a premium action. It also clarifies that the tool is for practice rather than live-interview assistance. It does not mention auth or response behavior, but it does not contradict any annotation.

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

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

The description is only two sentences and is well front-loaded: the first sentence states the core behavior, the second lists capabilities and a key boundary. Every sentence carries useful information and there is no filler.

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

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

Given 12 parameters and no output schema, the description is not complete enough to support correct invocation. It omits mode-specific parameter requirements, prerequisite linkage to checkout/status tools, and any indication of what the response returns. An agent knows the tool's purpose but not enough detail to reliably build valid calls.

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

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

Schema description coverage is 0%, so the description must compensate. It only paraphrases the enum modes and never explains which of the 12 input fields (role, answer, skills, job_description, candidate_background, etc.) are required or expected for each mode. An agent would have to guess the correct payload.

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

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

The description states a clear action ('Consume one verified premium action') and a clear context ('pre-interview preparation'), then lists the supported capabilities. It does not explicitly name or contrast sibling tools such as prepare_interview_sprint_checkout or get_interview_sprint_status, so the differentiation is clear but 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?

The 'pre-interview preparation' context and the enumerated modes imply when the tool should be used, and the last sentence is an explicit when-not ('Not for covert live-interview answer feeding'). However, there is no guidance about prerequisites, checkout/offer dependencies, or when to prefer sibling status/capability tools.

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