GVRN Incorporation

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

With annotations all false—no safety hints—the description carries the behavioral burden. It clearly states this is a create operation, that the draft is bound to the verified email token, that all fields except the token are optional, and that a draftId is returned for future steps. It does not discuss idempotency, error conditions, or token lifetime, but it discloses the core behavior and side effects well.

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: the first states the core action and scope, the second gives the only prerequisite, and the third explains the return value's purpose. Nothing is redundant, and the most important information is front-loaded. 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?

The tool has 12 parameters and no output schema, so the description must cover return behavior and the workflow context. It does: it identifies the required token, optionality, and the returned draftId for subsequent update/submission/status tools. It could be more complete by describing the exact response shape or failure modes, but for a draft-creation step the essentials 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?

Schema description coverage is 100%, so the schema fully documents each parameter. The description adds important meaning beyond the schema: verificationToken comes from verify_email_otp, every other field is optional, and the result is a reusable draftId. This contextual glue is more than a baseline schema-dependent description.

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 a specific verb and resource: 'Creates a new incorporation request draft.' It further distinguishes this tool from siblings by emphasizing 'new' (vs update_incorporation_draft), 'draft' (vs submit_incorporation), and 'bound to the verified email' (vs verify_email_otp). An agent can clearly identify this as the creation step in the incorporation workflow.

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 usage context: it must be called after verify_email_otp because a verificationToken is required, and the returned draftId is used 'for later updates, submission, and status checks,' which maps to the sibling tools. It does not explicitly name an alternative or state when not to use it, but the flow is strongly 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 provide readOnlyHint=true and destructiveHint=false, so the safe read-only behavior is established. The description adds content scope and the alternative MCP resource URI, but discloses no further behavioral traits such as response format, pagination, or authentication 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, focused sentences. The primary return value is front-loaded, the content list adds concrete value, and the MCP resource note is delivered as a brief secondary detail.

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 retrieval tool, the description is fully sufficient. It states what is returned, summarizes the guide's contents, and notes an alternative access method; no output schema is present but the description covers expectations adequately.

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 input schema is empty, so there is nothing for the description to clarify. With no parameters, a baseline of 4 is appropriate.

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

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

States a specific verb and resource ('Returns the full GVRN incorporation workflow guide') and enumerates the content (fields, email-verification steps, review lifecycle). This clearly distinguishes it from the status, draft, and submission tools in the sibling list.

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

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

The description implies use when the full incorporation workflow guide is needed, but it gives no explicit when-to-use guidance and does not contrast with alternatives like get_incorporation_status or the draft/submit tools. The sibling list is not referenced within the description.

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 safety conflict exists. Beyond annotations, the description adds meaningful behavioral context: the state machine of statuses, the authentication requirement, and the privacy scoping (only the creating email can see the request). This exceeds the annotation baseline significantly.

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 carry complete information with zero filler: the first front-loads the return value and state flow, the second adds the access constraint. Every word serves the agent's decision-making.

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 status lookup with a fully self-documenting schema and clear state enumeration, the description is highly complete. The only minor gap is that it doesn't specify the response format beyond status values, but since no output schema exists, the state list provides sufficient expectations 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 100% description coverage, with both parameters fully documented (draftId format and return reference, verificationToken source). The description adds no additional parameter semantics beyond what the schema already provides, so per calibration guidance the 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?

The description opens with a specific verb ('Returns') and a clear resource ('the current status of an incorporation request'), and it enriches the purpose by enumerating the exact lifecycle states (DRAFT → QUEUED_FOR_REVIEW → UNDER_REVIEW → COMPLETED). This clearly distinguishes it from sibling tools like get_incorporation_guide, which covers informational content rather than a request's 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 explains when this tool is callable: it requires the verificationToken tied to the email that created the draft, and it restricts visibility to that email. This provides clear contextual usage guidance even though it doesn't name alternative tools or explicit 'use this when...' 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?

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?

The description explicitly discloses irreversibility, that the draft becomes read-only, and that a review request is filed. This goes well beyond the destructiveHint=true annotation by saying exactly what state change happens and what the user should expect. It also clarifies the auth need for a verificationToken tied to the creating email.

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

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

Four sentences with the core purpose front-loaded, then prerequisite and irreversibility. The sentence about optional fields being left blank is useful but somewhat tangential to the tool's own parameters, keeping it a half-step below perfect.

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 low-complexity tool with two well-described parameters and strong annotations, the description covers the submission outcome, auth requirement, irreversibility, and resulting state. The return value is simply described as the request status, which is sufficient given no 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%, so the baseline is 3. The description adds meaning by clarifying that verificationToken must belong to the email that created the draft and that this email becomes the contact for the request, which is not fully stated 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?

The description states a specific action: submitting a draft for review by the GVRN team, and says the tool returns the request status. This clearly distinguishes it from siblings like create_incorporation_draft, update_incorporation_draft, and 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?

The description gives clear context for when to call it: after a draft exists and the email has been verified, since a verificationToken is required. It does not explicitly name alternatives or say when not to use it, so it misses the full 'when-not/alternatives' 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?

Beyond the annotations, the description discloses important behavior: patch semantics, array replacement behavior, verification token requirement, and failure after draft submission. This adds meaningful behavioral context that annotations alone do not provide.

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 carrying essential information. The description is front-loaded with the core behavior and then covers requirements and constraints with 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?

For a complex 13-parameter update tool, the description covers the key invocation concerns: operation type, patch semantics, required token, and lifecycle restriction. The schema handles parameter details, and no output schema is declared, so the description is sufficiently complete for correct invocation.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds valuable semantics explaining how parameters are applied: only provided fields are changed and array fields are replaced whole. This goes beyond the schema's field-level descriptions.

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

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

The description states a specific verb and resource: 'Adds or corrects fields on an existing draft.' It also clarifies patch semantics, which distinguishes it from create_incorporation_draft and submit_incorporation. This is clear and not tautological.

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 implies when to use the tool: on an existing draft, before submission. It also states a hard prerequisite (verificationToken for the creating email) and a hard exclusion (fails after submission). It does not explicitly name sibling alternatives, but the context and failure condition provide adequate 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?

The description adds meaningful behavioral details beyond the annotations: the token is valid for ~30 minutes, re-verification issues a fresh token, and the fresh token still reaches the same drafts. It also implies a state-changing operation consistent with readOnlyHint=false, with no contradiction.

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

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

Two sentences with no filler. The core action and output are front-loaded, and the token's role in the broader workflow is stated in the second sentence. 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 two-parameter verification tool with no output schema, the description covers the return value, token expiry, downstream dependency, and idempotency-like behavior. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, and both 'email' and 'code' are already described accurately in the schema. The description's mention of a '6-digit code' matches rather than extends the schema. Since the schema carries the parameter meaning, a baseline score 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 ('verifies'), a specific resource ('6-digit email code'), and the key output ('verificationToken'). It also distinguishes itself from the sibling request_email_otp by focusing on verification rather than sending. The title matches the function clearly.

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 draft tools require this token, which tells the agent when this tool fits in the workflow. It does not explicitly name alternatives or exclusion conditions, but the token requirement provides clear contextual guidance and placement after receiving the email code.

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