GVRN Incorporation

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

The description discloses that the tool creates a draft bound to the verified email and returns a draftId. Annotations (readOnlyHint: false, etc.) provide no extra safety context. The description adequately covers the behavior beyond annotations, though it could mention potential error conditions or side effects.

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, each serving a distinct purpose: stating the action and its constraints, and explaining the return value for future use. No irrelevant information, front-loaded with the core purpose.

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, no output schema, and no nested objects, the description covers the key aspects: required precondition (verificationToken), optional nature of other fields, and the returned draftId for follow-up steps. It could mention error handling or validation but is otherwise 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?

Schema description coverage is 100%, so the UI schema already explains each parameter. The description adds the important detail that verificationToken is required and others optional, but otherwise does not provide additional meaning beyond the schema. 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 clearly states 'Creates a new incorporation request draft' with a specific verb ('creates') and resource ('incorporation request draft'), and distinguishes from siblings like update_incorporation_draft by focusing on initial creation. It also specifies the binding to verified email and use of provided fields.

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 requires a verificationToken from verify_email_otp and notes all other fields are optional, giving clear context for proper usage. It indirectly suggests this is a first step by mentioning that the returned draftId is used for later updates, submission, and status checks, but it does not explicitly state when not to use it or name 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 set readOnlyHint=true, so the description adds limited behavioral insight. It lists the guide's contents but doesn't disclose side effects or permissions. 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 sentences, no redundant words. Front-loaded with the core action and content summary. Every sentence adds value.

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 tool with no output schema, the description fully covers what it returns and its scope. No missing critical details.

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 has no parameters (coverage 100%), so baseline is 4. Description adds value by explaining what the returned guide includes, beyond the empty 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?

Description clearly states it returns the full GVRN incorporation workflow guide and specifies the content fields, email-verification steps, and review lifecycle. This distinguishes it from siblings like create_incorporation_draft or get_incorporation_status.

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?

Mention of an alternative MCP resource provides some context, but no explicit guidance on when to use this tool versus siblings or when not to use it. The usage is implied but not fully 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?

The description aligns with the readOnlyHint annotation (true) by stating it returns status without modification. It adds transparency about the authentication requirement (verificationToken) and visibility constraint (only to the email). No contradictions 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 concise sentences that front-load the main purpose (returns status) and then provide critical authentication context. No redundant or 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 lists the possible statuses, which is helpful for an agent. However, it does not describe the full response format (e.g., whether other fields are included). Given the tool's simplicity, this is adequate but could be more 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?

Both parameters (draftId, verificationToken) are fully described in the schema (100% coverage). The description adds value by linking draftId to 'create_incorporation_draft' and verificationToken to 'verify_email_otp', clarifying their origins beyond the schema.

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

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

The description clearly states the tool returns the status of an incorporation request, listing the possible states (DRAFT → QUEUED_FOR_REVIEW → UNDER_REVIEW → COMPLETED). It distinguishes from sibling tools like create_incorporation_draft (which creates) and submit_incorporation (which changes status).

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 specifies that a verificationToken is required and that requests are only visible to the associated email, providing clear usage context. It implies when to use this tool (after draft creation and email verification) but does not explicitly state when not to use it or mention alternatives like submit_incorporation.

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?

Discloses code expiry (10 minutes) and rate limiting per email, which are behavioral traits beyond annotations. 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 sentences, no wasted words. First sentence states the main action, second explains flow and constraints. Front-loaded and efficient.

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 tool with annotations present, the description covers the flow, next steps, and important constraints (expiry, rate limiting). No missing information for correct usage.

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 has 100% description coverage for the single parameter 'email' with a clear description. Tool description adds no additional parameter information beyond schema, so baseline of 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?

Clearly states 'Sends a 6-digit verification code to the given email address', specifying the action, resource, and outcome. Distinguishes from sibling verify_email_otp by explaining the 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?

Explains that the code is exchanged via verify_email_otp and authorizes draft tools, giving context on when to use. Mentions expiry and rate limiting, but does not explicitly state when not to use or 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?

Adds irreversibility context (draft becomes read-only, review filed) beyond destructiveHint annotation. Lacks details on failure modes or response format.

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 efficient sentences front-loaded with purpose, followed by prerequisite and side-effect warning. 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?

Covers purpose, prerequisites, irreversibility, and return value. No output schema, so lacks detail on status values, but sufficient for a simple submission.

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 already describes draftId and verificationToken origins. Description adds context that token's email becomes contact, complementing 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?

Specifically describes submitting a draft for review by GVRN team, returning status. Distinguishes from sibling creation and update 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?

States requirement for verificationToken from email verification, implying sequence. Does not explicitly exclude already-submitted drafts, but irreversibility hint covers it.

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

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

Beyond annotations (idempotent, non-destructive), the description adds crucial details: patch semantics with array replacement (not merging) and the failure condition after submission. No contradictions 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?

Three tight sentences: purpose with semantics, prerequisite, and failure condition. Every sentence carries essential information with no 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?

For a tool with 13 parameters and no output schema, the description covers key behavioral aspects (patch, token, failure). It relies on the schema for parameter details, which is adequate given the 100% coverage.

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 100% schema coverage, the baseline is 3. The description adds value by clarifying patch behavior and array replacement semantics, which are not in the parameter descriptions. The verificationToken requirement is reinforced.

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 'adds or corrects fields on an existing draft' with explicit patch semantics. It distinguishes from sibling 'create_incorporation_draft' by targeting an existing draft, making the purpose unambiguous.

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 specifies that a verificationToken from verify_email_otp is required and that the tool fails after submission, providing clear temporal context. However, it does not explicitly list when not to use or mention alternatives, though the sibling context makes it obvious.

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 it's not read-only, and the description adds useful behavioral context: token lifetime (~30 min), re-verification issues a fresh token that still reaches same drafts. 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 sentences, no fluff, front-loaded with core purpose and token validity, then additional context. 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?

Returns a verificationToken and mentions draft tools dependency. Lacks failure scenarios (e.g., invalid code), but overall sufficient for usage without output schema.

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

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

Schema coverage is 100%, but the description adds value by specifying the code is 6-digit (more restrictive than schema's 4-10 length) and clarifying email must be the same one the code was sent 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 clearly states it verifies a 6-digit email code and returns a verificationToken valid for ~30 minutes. It distinguishes from sibling tools like create_incorporation_draft or request_email_otp by focusing on the verification 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?

It explains the token is needed for draft tools and re-verification behavior, providing clear context for when to use. However, it lacks explicit 'when not to use' or alternatives.

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