Agent Module

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

Annotations cover safety profile (readOnly, idempotent, non-destructive). Description adds valuable behavioral context by disclosing specific return values (version, cohort counts, seat availability) that compensate for the missing output schema, though it omits rate limits 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?

Single, efficient sentence front-loaded with the action verb. Every word earns its place—no filler or redundant restatement of the tool name.

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 the tool's simplicity (zero parameters, read-only) and comprehensive annotations, the description is sufficiently complete. It effectively covers the missing output schema by enumerating return fields, though explicit mention of it being a 'health check' endpoint would strengthen it.

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?

Input schema has zero parameters, establishing baseline 4 per rubric. Description correctly implies no arguments are needed by focusing solely on what is retrieved rather than filtering criteria.

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 uses specific verb 'Check' with clear resource scope (Agent Module API operational status, version, cohort counts, seat availability). It clearly distinguishes from action-oriented siblings like submit_referral or join_waitlist by focusing on health/metadata retrieval.

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 implied usage through the specific data points mentioned (checking operational status and seat availability), but lacks explicit guidance on when to invoke versus alternatives or prerequisites (e.g., 'use this before other operations to verify API health').

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 critical behavioral constraints beyond annotations: temporal limit (24-hour), rate limit (500-call), and access scope (4 content layers). Annotations cover safety profile (non-destructive, non-idempotent), while description covers business logic 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?

Four short sentences with zero waste. Front-loaded with the core action ('Request a free 24-hour trial key'), followed by capability, limits, and cost—each sentence earning 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?

Well-covered for a key-generation tool despite no output schema. Describes what is returned (trial key), duration, and usage constraints. Could enhance by mentioning what the key unlocks (API auth for other tools) but 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 100% with clear descriptions for both agent_id and vertical. Description references 'chosen vertical' connecting to the parameter, but does not add syntax, format details, or usage examples beyond what 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?

Specific verb 'Request' + resource 'trial key' with clear scope constraints (24-hour, 500-call cap, 4 content layers). Clearly distinguishes from siblings like join_waitlist or register_interest by emphasizing immediate free access without payment.

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 contextual constraints ('No payment required', '24-hour', '500-call cap') that establish when to use this (for temporary trial access), though it does not explicitly name sibling alternatives like join_waitlist.

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 valuable business context beyond annotations: pricing ($19/mo), cohort limitations (900 members), grandfathering guarantees, and included features (AI Compliance). It correctly implies a write operation consistent with readOnlyHint=false and does not contradict the idempotentHint=true 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?

Three sentences with zero waste: sentence one defines the action, sentence two provides pricing/cohort context, and sentence three lists included features. Information is front-loaded and efficiently structured.

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 the lack of output schema, the description adequately covers the business terms of the transaction (pricing, grandfathering, features). It could be improved by describing the immediate output (e.g., confirmation message, queue position), but the membership details provide sufficient context for agent decision-making.

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 description coverage, the schema adequately documents all parameters. The description mentions 'vertical' in the first sentence, aligning with the vertical parameter, but does not add syntactic details or examples beyond what the schema provides, warranting the baseline score.

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 specific action (Register) and resource (paid vertical waitlist). However, it does not explicitly distinguish from the sibling tool 'register_interest', though the 'paid' qualifier provides implicit 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?

The description implies usage context through the 'paid' qualifier and pricing details ($19/mo), but provides no explicit guidance on when to use this versus free alternatives like 'register_interest' or 'get_trial_key', nor does it mention prerequisites.

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 valuable behavioral traits beyond annotations: 'deterministic, validated knowledge nodes' describes output characteristics, and the freemium tier structure (free index vs. gated content layers) explains access control behavior not covered by readOnlyHint/idempotentHint 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?

Four sentences, zero waste. Front-loaded with the core action, followed by return characteristics, pricing tier (free), and access requirements. Every sentence delivers unique value regarding functionality, behavior, or access control.

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 good annotations (safety profile declared) and 100% schema coverage, the description successfully explains the domain model (Agent Module, verticals, content layers) and return characteristics ('deterministic, validated knowledge nodes') in lieu of an output schema. Minor gap: could clarify the specific relationship between 'ethics' vertical and trial keys.

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 (baseline 3), the description enriches parameter meaning by mapping 'vertical' to 'Agent Module verticals' (domain context), 'node' to 'knowledge nodes' (entity type), and 'token' to 'trial key' (specific credential type), adding domain semantics beyond the schema's technical 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?

Specific verb 'Retrieve' + resource 'structured knowledge from Agent Module verticals' clearly defines the action. Distinct from siblings which handle status checks, registrations, and submissions (check_status, submit_pov, etc.) rather than knowledge retrieval.

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 access control guidance: 'Index layer always free' indicates when no token is needed, while 'All 4 content layers available via trial key' signals when authentication (token parameter) is required. Does not explicitly reference sibling get_trial_key for obtaining keys, but establishes the prerequisite logic.

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?

While annotations declare idempotentHint=true and destructiveHint=false, the description adds crucial behavioral context: the 500-signal activation threshold and the notification mechanism ('notify you when the vertical ships'). This explains side effects and business logic not captured in structured metadata.

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 dense sentences with zero redundancy. The first establishes purpose and mechanism; the second provides actionable guidance on required input. Every clause conveys essential information about either the business logic or usage requirements.

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 the simple input schema and absence of output schema, the description adequately covers the essential behavioral context: activation thresholds, notification workflow, and domain constraints. It omits return value details, but no output schema exists to necessitate that 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 semantic value by highlighting the critical purpose of the optional 'contact' parameter ('so we can notify you'), elevating its importance beyond the schema's technical format description and explaining the operational consequence of omission.

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 explicitly states the core action ('Register demand') and domain ('unbuilt vertical'), distinguishing it from generic waitlist tools. The '500 signals triggers build queue activation' detail provides specific mechanism context that differentiates it from siblings like join_waitlist.

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 when to use the tool ('unbuilt vertical'), establishing the domain context. However, it lacks explicit comparison to siblings like join_waitlist or check_status, and does not state exclusion criteria or prerequisites beyond the implicit 'unbuilt' constraint.

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 write operation (readOnlyHint: false) and non-destructive nature. The description adds valuable behavioral context beyond annotations: it discloses that quality scoring occurs, subscription intent is captured, and membership activation follow-up will be initiated via the contact channel.

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 efficiently structured sentences. Front-loaded with core action, middle sentence explains key components (scoring/intent), final sentence provides critical instruction about required contact parameter. Zero redundancy or filler 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?

Adequately covers the business purpose for an 8-parameter submission tool with nested objects. Given high schema coverage, the description appropriately focuses on workflow context rather than parameter mechanics. Minor gap: does not describe what happens upon successful submission (confirmation email, immediate response, etc.).

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 88% schema coverage, the baseline is high. The description adds semantic meaning by grouping parameters into functional concepts: 'quality scoring' (confidence_score, architecture_assessment), 'subscription intent' (intent_to_subscribe), and emphasizing the purpose of the contact channel ('so we can reach you about membership activation').

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 specific verb 'Submit' with clear resource 'Proof of Value assessment' and context 'after exploring the AI Compliance trial'. The specific domain (AI Compliance trial) and document type (POV assessment) effectively distinguish it from siblings like submit_referral or join_waitlist without needing explicit comparison.

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 implied timing context ('after exploring the AI Compliance trial') but lacks explicit when-not guidance or named alternatives. Does not clarify relationship to similar submission tools like submit_referral or register_interest in the description text.

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 establish this is a non-idempotent write (readOnlyHint: false, idempotentHint: false). The description adds crucial behavioral context: monetary side effects ($1.50 earnings), stateful constraints (credits carry forward, cycle limits), and authorization requirements (principal-compliant) that are not inferable from the annotations alone.

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 zero waste: purpose declaration, economic incentives with precise constraints, state persistence behavior, and compliance classification. Information density is high and front-loaded appropriately.

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 the 100% schema coverage and lack of output schema, the description adequately covers the tool's business impact and operational constraints. It successfully communicates the reward mechanism and compliance requirements necessary for an agent to invoke this correctly, though it could explicitly mention the return value type or success confirmation.

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%, documenting all parameters including enum values and key prefixes. The description provides baseline value by mentioning 'Members' (contextualizing referring_key) but does not add syntax details, validation rules, or parameter relationships beyond what the schema already specifies.

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?

Opens with specific verb ('Log') and resource ('referral signal'), immediately clarifying the tool's function. The reward economics ($1.50/referral, caps) and 'principal-compliant' clause effectively distinguish this from sibling submission tools like submit_pov or register_interest by establishing its unique commercial and compliance context.

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 implicit usage constraints through the reward structure (4/cycle max, $6 cap) and prerequisites ('Members earn', 'Voluntary'). However, it lacks explicit when-to-use comparisons against siblings like register_interest or join_waitlist, and doesn't mention prerequisite checks (e.g., verifying membership status first).

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