ZenSched

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

Annotations already establish read-only and non-destructive intent, so the description does not need to repeat those. It adds the valuable behavioral facts that the call requires no authentication and never errors, which are not visible in the annotations and materially affect whether an agent chooses to call it speculatively.

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 cover purpose, invocation timing, and behavioral guarantees with no filler. The most important information is front-loaded in the first 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?

Given no parameters, an output schema, and read-only annotations, the description is sufficient: an agent knows what it does, when to call it, and what to expect regarding auth and errors. The only minor wrinkle is referencing account_get, but that does not undermine completeness.

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 the schema is already complete; the 0-parameter baseline applies. The description has no parameter content to add, but none is needed.

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 opens with a specific verb and resource: it checks whether the connector is signed in as a ZenSched org. This clearly marks it as a status probe rather than an account mutation or recovery action, which distinguishes it from siblings like account_create and account_signin_start.

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

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

It gives explicit placement guidance ('Call this before account_get in a new session'), so an agent knows when it should be invoked. It does not contrast directly against the listed auth siblings or state when not to use it, but the placement plus 'unauthenticated' makes the condition reasonably clear.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, adding little beyond 'this mutates.' The description discloses key behavioral traits: no OTP, immediate return of org_id and zsc_ key, the need to store the key securely, and aggressive rate limiting. This is meaningful context beyond the structured annotations and is not contradictory.

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

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

Three sentences with no filler. The core action is front-loaded, critical security guidance ('Store the key securely') is included, and the alternative follow-up tool is named. Every sentence 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 single-parameter creation tool with an output schema and annotations, the description covers the essential context: why this tool exists, what it returns, security handling, rate limits, and the follow-up path for attaching an email. Nothing needed for calling it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It doesn't add explicit detail about org_name beyond the schema's 'Org Name' title, but with only one required, self-explanatory parameter the gap is minor. The description's focus on org creation makes the parameter's purpose sufficiently inferable.

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

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

States a specific verb and resource: 'Create a ZenSched org without email (MCP-only agents).' It clearly differentiates from signup-style siblings by emphasizing the no-email, no-OTP, immediate-key flow, so an agent can tell it apart from account_signup_start without opening schemas.

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

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

The description clearly indicates the intended context: MCP-only agents that need an org without email. It also names account_set_contact as the follow-up for attaching a contact email later. It does not explicitly state when to avoid this tool in favor of the signup sibling, but the email-context guidance makes the usage boundary reasonably clear.

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

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

The description adds crucial behavior beyond annotations: this is step 1 of a two-step flow, a verification code is sent to the org owner email, the next tool is account_recover_verify, and the overall recovery path revokes all keys. This significantly informs agent expectations, especially since annotations only show readOnlyHint false and destructiveHint false.

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

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

Three short sentences, each adding distinct value: what the tool does, what to call next, and when to use an alternative. The critical warning about revoking keys is placed at the end but clearly highlighted. 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?

Given a single parameter, the step context, next-step guidance, alternative routing, and security warning, this description fully equips an agent to call the tool correctly. The output schema exists, so return-value details are not needed.

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 only says the email property is a string titled 'Email', with 0% description coverage. The description compensates by specifying that the email is the org owner email and that a verification code is sent there, giving real semantic meaning to the only parameter.

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

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

States a specific action (sends verification code to org owner email) and clearly links to the recovery flow as step 1 of 2. It differentiates itself from account_signin_start and names account_recover_verify as the next step, so an agent can distinguish it from siblings without opening schemas.

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

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

Explicitly says when to prefer account_signin_start instead — when only reconnecting is needed — and warns that Recover revokes ALL keys. This is strong routing guidance that prevents misuse.

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

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

The description discloses the critical side effect: 'revokes ALL previous keys,' which goes beyond the destructiveHint annotation by specifying exactly what is destroyed. It also states the positive outcome of issuing a fresh key. This adds concrete behavioral context above the structured 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 sentence of about 25 words that packs the step, action, and consequences into a front-loaded structure with no filler. Every phrase 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?

The description covers purpose, step context, and side effects, and an output schema exists to document return values. However, it leaves some details implicit, such as the origin of the code and explicit sequencing with account_recover_start, so it is not fully complete.

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

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

With 0% schema description coverage, the description must compensate for parameter documentation, but it does not. It only loosely implies that 'code' is a verification code from 'verify the code' and leaves 'email' entirely to inference. It does not explain where the code comes from, its format, or that email must be the account email.

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

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

The description clearly states the tool's purpose: verifying a code as step 2 of a lost API key recovery process. It explicitly differentiates from siblings by specifying it issues a fresh key and revokes all previous keys, and the 'Lost API key (step 2 of 2)' prefix unambiguously places it in the recovery flow.

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 contextual guidance by identifying this as step 2 of 2 in a lost-key recovery flow, letting an agent infer it should follow account_recover_start. It does not explicitly name alternatives or exclusions, but the loss/recovery framing strongly distinguishes it from sign-in verification siblings.

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

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

Annotations already mark readOnlyHint=false and destructiveHint=false, so mutation is expected. The description usefully adds the side-effect nature (emails a code), the 6-digit format, and that keys are not rotated. This is meaningful beyond the annotations, though it does not discuss expiry or resend 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 short sentences pack purpose, workflow step, next sibling, and alternative preference with no filler. Every clause earns its place, and the most important action is front-loaded.

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

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

For a simple one-parameter start-step with an output schema and annotations, the description covers the essential workflow, the sibling to follow, and the side effect. It is slightly terse regarding what 'Recover' refers to exactly, but the sibling list makes that resolvable.

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 only lists 'email' as a string with no description, and schema coverage is 0%. The description compensates by specifying that the email belongs to the org owner and is the address receiving the code. It adds enough semantic meaning for the single required 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 states a clear action: it is step 1 of 2 for reconnecting an existing org, and it emails a 6-digit code to the owner. It also differentiates itself from account_signin_verify by explicitly pointing to the next step, and from the recover flow by saying 'Prefer this over Recover.'

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

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

It gives explicit when-to-use context ('Reconnect an existing org without rotating keys'), sequence context ('Then account_signin_verify'), and an explicit preference against the alternate recover flow. This is strong routing guidance for an 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?

The description adds useful behavioral context beyond annotations: it explains that key rotation is not involved, the verification can be retried, and failure can be handled via account_use_key. It is consistent with the readOnlyHint/destructiveHint 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 compact, front-loads the core purpose, and each sentence adds distinct useful information: what the tool does, where to call it, and what to do if things fail.

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 an output schema, the description covers workflow positioning, retry behavior, and fallback alternatives. The main gap is parameter-level detail, but the overall invocation context is clear enough for an agent.

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

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

The input schema has no parameter descriptions and schema coverage is 0%, so the description must compensate, but it only implicitly explains 'code' as the emailed code. The 'email' parameter is not clarified at all, leaving important semantics unstated.

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

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

The description clearly identifies the action as verifying an emailed code and specifies it is step 2 of 2 for reconnecting an existing org. It distinguishes the tool from siblings by describing the exact workflow position and purpose.

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

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

The description gives explicit usage guidance: call after account_signin_start, and if later org tools fail, retry account_signin_verify or use account_use_key. This directly helps an agent choose between alternatives and sequence calls.

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 indicate this is not read-only and not destructive; the description adds practical behavioral context: it sends a verification email, is rate-limited, and requires no authentication. This informs the agent about side effects and constraints beyond what annotations state.

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 concise sentences front-load the core purpose and immediately cover step semantics, authentication status, rate limit, and the next action. No filler or redundancy.

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

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

The description is sufficiently complete for a two-parameter tool: it names purpose, side effect, next step, authentication requirement, and rate limiting. The output schema can cover return details, and annotations cover safety profile.

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

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

Schema descriptions are absent for both parameters, so the description needed to clarify parameter usage. It only implicitly references email and never explains org_name's role or format. The parameter names are somewhat self-explanatory, but the description does not compensate for the 0% schema coverage.

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

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

The description clearly states the tool's action: creating a ZenSched org in step 1 of 2 by sending a 6-digit verification code to an email. It distinguishes itself from related auth flows like sign-in and recovery by explicitly naming the signup flow and next step.

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

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

The description explicitly says this is step 1 of 2, tells the agent to next call account_signup_verify, and notes that the operation is unauthenticated and rate-limited. This gives clear contextual usage guidance and prevents confusion with sibling tools.

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

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

Annotations are minimal false hints, so the description carries the full burden. It discloses that the tool creates an org, returns org_id and a zsc_ API key shown only once, and enforces a stateful postcondition (Claude.ai must Connect before further org tools). 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?

Two tightly packed sentences with no filler. The purpose is front-loaded, followed by the critical return value warning, and then the postcondition. Every sentence 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?

Given its role as a two-step signup verification tool, the description covers what it does, the flow position, return values (org_id and one-time API key), and the mandatory next action (Connect). An output schema exists for structured return data, so no return-format gap remains.

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 explains 'code' as the emailed verification code, but 'email' is only referenced indirectly as 'the same email' in the Connect instruction. An agent can infer the email should come from signup_start, but the description does not explicitly map both 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?

States a precise verb ('verify') and resource ('the emailed code'), and frames the action as 'Create a ZenSched org (step2 of 2)'. This distinguishes it from sibling tools like account_signin_verify and account_recover_verify while clearly tying it to account_signup_start.

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

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

Explicitly positions itself as step 2 of 2 in the signup flow, implying it should follow account_signup_start. It also provides an explicit exclusion: after this tool, 'do not keep calling org tools until Connect succeeds', which tells the agent exactly when to stop using the org tool family.

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 are minimal, so the description carries the transparency burden. It adds useful context that this uses an existing key and can serve as a re-authentication fallback, but it does not disclose side effects such as whether existing stored credentials are replaced or whether repeated calls are harmless.

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 tightly scoped sentences, each carrying distinct information: function, preference condition, and fallback/negative instruction. No filler or repetition of schema or annotation data.

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 one-parameter authentication tool, the description covers what, when, and how, and names the relevant alternative. Output expectations are handled by the existence of an output schema, and the low complexity means nothing critical is missing.

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

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

The input schema has no field descriptions, so the description must compensate. It adds meaningful detail about the single api_key parameter: it must be an existing key with the zsc_ prefix. It could go further by explaining how to obtain or pass the key, but the parameter is simple and mostly self-evident.

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 opens with a specific verb and object: 'Authenticate this connector with an existing zsc_ API key.' It also differentiates from the sibling account_signin_start by stating this tool is preferred when the key is already in the conversation.

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 clear condition ('when the key is already in the conversation') and an explicit fallback path ('If the connector shows Connected but org tools fail, call this or account_signin_start'). The 'do not look for a Connect button' instruction prevents a common wrong action.

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?

Adds meaningful behavior beyond annotations: submission is free, does not require an account, and is read by a human. This helps set expectations about cost, access, and processing style. 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?

Compact and front-loaded with the core purpose, followed only by high-value operational details. Every sentence contributes selection or invocation guidance.

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 an output schema exists, return value explanation is unnecessary. The description covers purpose, categories, severity, account requirement, and bug-submission specifics. The main missing piece is idempotency_key semantics, which matters for a submit-style 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 0%, so the description carries the burden. It enumerates valid category and severity values and explains how to use context and related_tool for bug reports. Title and body are obvious; idempotency_key is not explained, which is a minor 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?

States a specific action ('File') and resource ('a grievance or product recommendation'), with explicit categories. Clearly distinguishes this feedback tool from the account management and guide siblings.

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

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

Provides clear usage context: free, works without an account, and gives targeted instructions for bug reports (include related_tool and paste error text in context). It does not name alternatives, but no obvious sibling fills the same role.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction exists. The description adds behavioral context by explaining that the tool provides guidance content and which topics it covers, going beyond the bare annotation and clarifying the tool's non-mutating informational role.

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 succinct sentences, front-loads the critical 'START HERE' cue, and packs the guide's scope into a scannable arrow chain. Every sentence earns its place with no filler.

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

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

For a zero-parameter, read-only guide tool with an output schema, the description provides sufficient context to call and use it correctly: what it is, where to start, and what topics it covers. There is no missing information needed for invocation.

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

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

The tool takes zero parameters and the input schema is empty, so there is nothing for the description to document. The baseline for zero-parameter tools is 4, and the description adds no conflicting or missing parameter 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 description clearly states this is an agent guide for ZenSched, using the specific verb 'guide' and naming the resource. It differentiates itself from sibling account tools by positioning itself as the 'START HERE' onboarding tool with a concrete topic list (Connect, fund, locations, workers, shifts, timesheets, feedback_submit).

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?

'START HERE' gives an explicit usage directive: this is the first tool to consult. The sequential arrow chain 'fund → locations → workers → shifts → timesheets' implies the workflow to follow. It does not explicitly name alternatives or when-not-to-use cases, so it earns a 4 rather than a 5.

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