printing-labs

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

With no annotations, the description carries full burden. It discloses side effects: creates a calendar event with Meet link unless Phone Call, registers the meeting, and sends emails. It also adds the consent requirement. It does not cover failure modes or reversibility, but the disclosed behaviors are sufficient for an agent to understand the tool's impact.

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 three sentences, front-loaded with the core action and side effects, then prerequisites and consent. Each sentence contributes essential information with no redundancy or filler, making it concise and well-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 tool's complexity (9 parameters, 5 required) and absence of an output schema, the description adequately covers the process side effects and prerequisites. It does not describe return values, but with schema covering parameters and the description covering behavior, it is sufficiently complete for correct selection and 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 baseline is 3. The description adds meaningful context: the mode affects whether a Meet link is created, and time must be from get-meeting-slots (already in schema, but reinforced). This extra behavioral nuance about mode is not in the schema, slightly increasing the value.

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 'Book' with a clear resource 'consultation with the Printing Labs team' and lists concrete outcomes (Google Calendar event, registration, emails). It clearly distinguishes this from sibling tools, especially get-meeting-slots, by describing the booking action and its side effects.

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 provides explicit prerequisites: the time must come from get-meeting-slots, and the agent must have user consent and real contact details. It clarifies the sequential relationship with get-meeting-slots. However, it does not explicitly state when not to use the tool or mention alternative tools, so it falls short of a 5.

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?

With no annotations, the description carries the full burden and does so well. It discloses the computation steps (quantity-discount tiers, GST), validation of minimum order quantity, that the next discount tier is shown, and the limitations of indicative pricing. This gives the agent a solid model of what the tool does and doesn't do.

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, front-loaded with the primary action, and every clause adds information: computation method, validation, next-tier output, and a caveat. 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?

Despite having no output schema, the description adequately communicates what the tool returns: effective price, next discount tier, and validation status. It covers the main behavioral aspects (tiers, GST, MOQ, indicative pricing) and is sufficient for an agent to select and invoke the tool correctly.

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?

Since schema description coverage is 100% and both parameters are well-described, a baseline of 3 is appropriate. The description adds some context by mentioning quantity-discount tiers and MOQ validation, which slightly enriches the 'quantity' parameter, but it doesn't add substantial parameter-level details 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 opens with a specific verb ('Compute') and resource ('effective bulk price') and clearly identifies the inputs (product and quantity). It distinguishes itself from siblings like search-products and request-quote by focusing on pricing calculation rather than product discovery or final quoting.

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 (to get an indicative bulk price) and explicitly warns that final quotes come from the sales team, effectively steering users away from using this for binding quotes. It doesn't explicitly name alternatives, but the context of siblings like request-quote makes the distinction 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?

With no annotations, the description carries the full burden of disclosure. It mentions the API key requirement, the creation side effects (email invites), the return values (claim + HR dashboard links), and the fulfillment flow. It omits details on reversibility or idempotency, but primary behaviors are transparent.

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 dense sentences, front-loaded with purpose and auth, and conveys all necessary high-level information without 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 no output schema and no annotations, the description covers the purpose, authentication, flow, and return values. It could mention edge cases or failure modes, but for a creation tool with a clear goal, it is reasonably 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?

The input schema has 100% coverage with descriptive property definitions, so the baseline is 3. The description adds minimal extra meaning beyond the schema (e.g., 'chosen kit' maps to kitProductSlug). No compensation 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 clearly states a specific verb+resource: 'Creates a Swag Drop for the chosen kit, invites each employee by email, and returns the claim + HR dashboard links.' This uniquely identifies the tool's function and distinguishes it from siblings like request-quote or track-order.

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 provides clear context for use: 'turn new hires into welcome-kit claim links in one call' and 'HR/HRIS automation.' It doesn't explicitly mention alternatives or exclusions, but the context is strong enough to infer when this tool is applicable.

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?

With no annotations, the description must carry the behavioral disclosure burden. It implies the data is curated ('verified facts') but does not state whether the operation is read-only, how the data is returned, or any limitations. The description adds little beyond content categories, leaving safety and execution behavior opaque.

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 that front-loads the core purpose ('Verified facts about Printing Labs') and then lists covered topics efficiently. It is concise without excessive length, though the comma-separated list could be slightly overwhelming.

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 no-parameter tool, the description gives a reasonable overview of content scope. However, it does not clarify the output format or structure (e.g., JSON fields, plain text) or any service-specific behavior. Since there is no output schema, describing the return value would improve 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 has zero parameters, so the description need not explain input semantics. Per the baseline for no-parameter tools, a score of 4 is appropriate; there is no schema information to contradict.

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 tool as providing verified facts about Printing Labs, enumerating specific content areas like services, fulfillment regions, and contact info. This distinguishes it from product-focused siblings like get-product-details and list-catalogs, though it lacks an explicit verb beyond the tool name.

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

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

The description gives no explicit guidance on when to use this tool versus siblings. It merely lists content categories, leaving the agent to infer that this is for general company information. No exclusions or alternative tool mentions are provided.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context by noting that slots reflect the live calendar, implying real-time data freshness. While it doesn't explicitly state that the operation is read-only or describe return format, the verb 'get' and the context strongly imply a non-mutating lookup, and the description is transparent enough for a simple read tool.

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, well-crafted sentence that packs the essential information: purpose, team, time zone, and usage context. It is front-loaded with the core function and avoids redundancy, making it highly 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 one-parameter tool with no output schema, the description adequately covers the key aspects: what it does, when to use it, and that it provides live data. It doesn't detail the return structure, but the name and description imply a list of slots, and the siblings context (book-meeting) helps the agent infer its purpose. This is sufficient for the tool's simplicity.

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 already provides a comprehensive description of the 'date' parameter, including format and range (today to +60 days, IST). The description adds no additional semantic detail beyond a generic 'for a given date', so a baseline score of 3 is appropriate since schema coverage is 100%.

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 function: retrieving available consultation slots with the Printing Labs team for a given date. It uses a specific verb ('get') and resource ('meeting slots'), and mentions the team context, distinguishing it from the sibling tool 'book-meeting' which handles booking.

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 explicitly instructs to 'Use before book-meeting', providing a clear directive on when to use this tool relative to its sibling. The context that 'slots reflect the live calendar' reinforces its role as a pre-booking check, making the usage guidance precise and actionable.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It identifies the tool as returning public details and lists the specific data returned (pricing, GST, stock signal, etc.), which strongly implies a read-only lookup. It does not mention not-found behavior or rate limits, but for a simple retrieval tool this is adequate.

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?

A single dense sentence states the action, input, and complete list of output fields with no filler or redundancy. The key purpose is front-loaded, and 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?

With only one required parameter and no output schema, the description covers the input origin, accepted forms, and the essential return fields. It could add error-handling or not-found behavior, but for this simple tool the description provides enough context for safe selection and 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 schema already documents the sole parameter with an example, but the description adds important semantics: the slug is a permalink from search-products results and can also be a numeric id. This extra context about parameter provenance and accepted forms goes beyond the bare 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 opens with "Full public details for one product or bundle" — a specific verb-resource-scope statement. It clarifies the input as a permalink slug from search-products results or a numeric id, and enumerates the covered fields, clearly distinguishing this from sibling tools like search-products or calculate-bulk-price.

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 the slug comes from search-products results, indicating that this tool should be used after a search to retrieve full details for a single product. It does not explicitly list exclusions or alternative conditions, but the intended context is 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?

With no annotations, the description carries the transparency burden. It discloses the return fields but does not state whether the operation is read-only, whether limits or pagination apply, or any other behavioral traits. For a list tool this is somewhat acceptable but still lacks explicit safety cues.

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 that is front-loaded and concise. It lists the key attributes without unnecessary verbosity, 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?

For a zero-parameter, simple list tool with no output schema, the description covers the essential return fields. It could mention ordering or pagination, but given the simplicity, it is mostly 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?

There are zero parameters, and schema coverage is at 100%, so the baseline of 4 applies. The description adds no parameter information 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 clearly states the tool lists every published catalogue with specific attributes (title, description, page count, file size, direct PDF URL). It distinguishes from sibling tools by focusing on PDF catalogues rather than product categories or details.

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 for accessing all published PDF catalogues, but does not explicitly state when to use it versus alternatives or when not to use it. No exclusions are mentioned.

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?

No annotations are provided, so the description carries the transparency burden. It details the return data (live counts, URLs, preset-bundle count) but does not explicitly confirm whether it is read-only or requires authentication. For a simple listing tool, this is adequate but not rich.

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

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

The description is a single, dense sentence covering all essential aspects: the resource (categories), the additional data (counts and URLs), and the extra bundle count. No unnecessary 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 the zero-parameter, no-output-schema nature, the description is complete in explaining what the tool does and what it returns. It provides enough information for an agent to select and invoke the tool appropriately.

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 description clarifies that it returns 'all' categories, implying no filtering. With no parameters to document, the baseline is high; the description adds no parameter semantics but does not need 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 explicitly states what the tool does: lists all Printing Labs catalog categories along with live product counts, canonical category page URLs, and the preset-bundle count. This distinguishes it from sibling tools like list-catalogs (which likely lists catalogs) and search-products (which searches products).

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 for retrieving category-level information but does not explicitly state when to use this tool versus alternatives such as list-catalogs. The context is clear, but there is no exclusion or alternative 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?

With no annotations, the description carries the full burden and excels: it discloses real-world consequences (creates a real lead, team receives via CRM+email+WhatsApp, requester gets confirmation) and emphasizes consent. This goes beyond typical mutation descriptions.

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, front-loaded with the action, followed by consequences and a constraint. Every sentence earns its place with zero waste.

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 7-param mutation tool without output schema, the description covers purpose, consequences, and consent requirement. Slightly lacks guidance on when to prefer this over related tools, but overall complete enough 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 description coverage is 100%, so baseline is 3. The description reinforces that contact details must be real and that email receives confirmation, but doesn't add new parameter-specific meaning 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 verb and resource: 'Submit a corporate quote request to the Printing Labs sales team.' It also distinguishes from siblings by noting it creates a real lead, unlike search-products or get-product-details.

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 provides clear context: acts on the user's behalf, requires explicit consent and real contact details. It lacks explicit mention of alternatives (e.g., calculate-bulk-price), but the conditional consent constraint gives practical usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the 'live' nature of the catalog and output as URLs, but does not disclose ordering, default behavior when no filters are applied, or potential rate limits. This leaves some behavioral gaps.

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, front-loaded with the primary action, and covers purpose, filters, and output in a compact manner. No fluff or redundant information is present.

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 5 optional parameters and no output schema, the description provides adequate context by explaining the search scope, filters, and return type. It lacks a note on pagination or result ordering, but the schema covers limit details, and the description mentions canonical URLs.

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 already provides 100% coverage with descriptive parameter definitions. The description merely summarizes these filters without adding new semantic meaning beyond the schema. Therefore, it meets the baseline for high 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 searches Printing Labs' live corporate-gifting catalog, listing product types and available filters. It uses a specific verb 'Search' and a resource, and the mention of 'canonical product page URLs' distinguishes it from sibling tools like list-catalogs and get-product-details.

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 provides clear context for when to use this tool: when a user wants to search the corporate-gifting catalog with filters. It implies a distinct use case from siblings by focusing on search rather than listing catalogs or product details, but does not explicitly state alternatives or exclusions.

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?

No annotations are provided, so the description carries the burden. It discloses that the order must exist and that the email and order ID must match, which hints at read-only behavior and potential validation. However, it does not explicitly state side effects, error behavior on mismatch, or authentication requirements, leaving some gaps.

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 concise sentences, front-loaded with the primary purpose and followed by the key prerequisite. Every word contributes to the tool's understanding, with no fluff or repetition of schema details.

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 only two parameters and no output schema, the description is nearly complete. It explains what the tool does (live status timeline) and the input requirements. It does not detail the timeline structure, but for a simple read-only tracker, this is an acceptable level of 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 input schema already fully describes both parameters (orderId, email) with 100% coverage. The description adds value by explaining the relationship between them—both must match—which is not encoded in the schema. This helps the agent understand the semantic constraint beyond individual parameter definitions.

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 with a specific verb and resource: it provides a 'live status timeline' for an existing order. It naturally distinguishes from siblings, which focus on products, meetings, quotes, and catalogs, none of which overlap with order tracking.

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 by specifying the required inputs: order ID and email, and adds the matching constraint. It implies when to use the tool (when you have these identifiers and need status), though it does not explicitly name alternatives or exclusion criteria.

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