Dreambooth Studio

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

The description discloses the OAuth-like flow (user approval via browser), the side effect of creating a new account with a 14-day trial upon approval, and the interaction pattern of waiting for user confirmation. This goes beyond the basic annotations (readOnlyHint=false, destructiveHint=false) and provides meaningful behavioral context.

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?

While multi-sentence, every sentence serves a purpose: stating the core action, explaining the approval link, covering both new and existing users, giving call triggers, and specifying post-call behavior. The description is front-loaded with the primary purpose and contains no redundant wording.

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 that the tool takes no parameters and has an output schema (likely describing the returned link), the description covers all needed context: the interactive flow, the trial creation side effect, when to call it, and how to handle the waiting period. It is complete for a zero-parameter OAuth-like connection tool.

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

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

The tool has zero parameters, so the input schema trivially provides full coverage. No parameter explanations are necessary, and the description does not omit anything relevant. Baseline of 4 applies for zero-parameter tools.

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 verb ('Connect') and resource ('a Dreambooth Studio account') and explains the return of an approval link. It clearly distinguishes this tool from siblings like connection_status or get_credits, which serve different purposes.

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 explicit usage triggers: call when another tool reports no account connected, or when someone asks to connect, sign up, or switch accounts. Also instructs to ask the user to open the link and await confirmation, and explicitly says not to call this tool again while waiting.

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

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

Annotations already mark it as read-only and non-destructive, but the description adds valuable behavioral context: it does not contact Dreambooth, meaning it's a local/cheap operation. This goes beyond the annotations to set performance expectations.

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

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

Two short sentences fully convey purpose, usage guidance, and behavioral notes without redundancy. Information is 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?

Tool is trivial with no parameters and an output schema provided, so description covers all needed context. It includes cost/behavior hints that complete the picture for safe invocation. Nothing additional is required.

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?

No parameters exist, so the description has nothing to add. Baseline of 4 applies per rubric since 0 params require no explanation.

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 checks whether a Dreambooth account is connected to the conversation and identifies which one. It distinguishes itself from sibling tool connect_account by focusing on status rather than action, making the purpose immediately obvious.

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

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

Explicitly instructs the agent to call this tool when unsure whether to run connect_account first, providing a clear decision rule. Also notes it is cheap and read-only, reinforcing when it's safe to invoke. This directly addresses usage context and 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 declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context by specifying what information is returned (credit balance, plan, end date) and clarifying the separation from wallet funds. This goes beyond the annotations without contradicting them.

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 core purpose in the first sentence and usage triggers in the second. Every sentence adds value, including the important distinction from wallet money. 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 zero-parameter read-only tool with output schema and annotations, the description is complete. It covers what, when, and a potential pitfall, while the output schema handles return format details. No significant gaps.

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, so the baseline is 4 per the rubric. The description adds meaning by explaining the tool's output (credits and plan) even though no parameter details are needed. It fully compensates for the lack of parameters.

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

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

The description clearly states the tool retrieves the operator's remaining AI credit balance and current subscription plan including end date. It uses a specific verb (get/retrieve) and resource (credits and plan), and distinguishes it from wallet-related tools explicitly.

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 provides explicit triggers: 'Call this when they ask how many credits are left, whether they can still run AI effects, or what plan they are on.' It also warns against confusing credits with wallet money, effectively guiding the agent away from sibling tools like get_wallet_transactions.

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 the safety profile is known. The description adds useful behavioral context: it returns counts only (not media), and explains the retention-window distinction (active vs. expired). This goes beyond the annotations without contradicting them.

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

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

Two tightly written sentences: the first delivers the core purpose, the second gives usage context. No redundancy or filler; every clause earns its place.

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

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

For a simple read-only tool with 2 optional parameters and an output schema, the description fully covers purpose, usage, and output behavior. The sibling list confirms it is well-differentiated. Nothing important is missing.

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

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

Schema description coverage is 100%, so both parameters are already well-documented. The description reinforces includeExpired's semantics by mentioning 'expired past the retention window,' but it does not add meaningfully new information 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 what the tool does: reports media counts (total, active, expired) for the operator's booths. It uses a specific resource ('this operator's booths') and explicitly distinguishes itself from siblings by noting 'Returns counts only, not the media itself.'

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?

Gives explicit when-to-use guidance: 'Call this when the operator asks how many photos or videos a booth has taken, or whether media is being lost to retention.' However, it does not mention when not to use it or name alternative tools, so it stops 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial context by detailing the returned fields (online status, last seen, app version, camera/printer/internet state). It also discloses the dependency on list_projects for the ID, beyond what annotations convey.

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 redundancy: the first enumerates what the tool returns, the second gives usage context and prerequisite. Information is front-loaded and every phrase 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?

Given the presence of an output schema, the description adequately covers what the tool does, when to use it, and the parameter source. It is complete for a read-only getter and needs no further elaboration.

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 fully describes projectId as 'Project id from list_projects' (100% coverage). The description reinforces this by telling the user to get the ID from list_projects first, adding procedural guidance 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 explicitly states it provides 'full detail for a single booth' with specific fields (name, public link, currency, screen size, live status). This distinguishes it from sibling tools like list_projects or get_gallery_stats by focusing on a single booth's detailed 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?

It clearly says 'Call this when the operator asks about one specific booth, or whether a booth is working,' giving direct context. It also instructs to 'Get the project id from list_projects first,' providing a prerequisite. It does not explicitly name alternatives or when-not-to-use, but the context is strong.

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 readOnly and non-destructive behavior. The description adds valuable context by explaining that cash and voucher money never reaches the wallet ledger, so wallet figures understate income, and that extra-print/AI-effect revenue is reported separately. This goes beyond annotation basics and provides interpretive insight.

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 and every clause carries meaningful information. It is slightly dense but not redundant. A bulleted structure could improve skimmability, but the current format is acceptable 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?

With an output schema present and annotations covering safety, the description fully covers the business logic: revenue channels, grouping options, separate reporting, and the wallet discrepancy. It also provides concrete use-case scenarios, making it complete 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?

The schema provides complete descriptions for all three parameters (to, from, groupBy), so the baseline is 3. The description reinforces the grouping by month/day and the date range, but does not add new parameter syntax or format details beyond what the schema already offers.

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: it returns business revenue from photobooth sessions across all payment channels, grouped by month/day and currency, with extra-print and AI-effect revenue reported separately. This specific verb+resource combination distinctly differentiates it from sibling tools like get_wallet_transactions and get_sessions.

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 instructs to use this tool for any question about income, revenue, or omzet, and recommends it specifically when wallet earnings look too small. This provides clear when-to-use guidance and effectively contrasts with wallet-related 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 declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds useful behavioral context: it returns sessions with totals, supports date ranges and filters, and is for inspecting sessions. It doesn't contradict annotations and adds value beyond the structured fields.

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, each earning its place: purpose, usage trigger, filter capabilities, and explicit alternative. Front-loaded with the core verb and resource, no redundant or vague language.

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 list tool with an output schema, the description covers purpose, usage scenarios, filter options, and alternatives. It doesn't mention pagination details, but the limit parameter and output schema cover that. Minor gap: unclear if 'with totals' means aggregated rows or session-level data with a total field, but output schema would clarify.

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 parameters are already well-documented. The description echoes filter categories (date ranges, per-booth, payment status/channel) at a high level but doesn't add new semantics or clarify edge cases beyond the schema. Thus 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 the tool lists photo sessions recorded on the operator's booths, with totals. It distinguishes from get_revenue_summary by explicitly directing money-related queries to that sibling tool, 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?

Provides explicit when-to-use guidance: 'Call this when the operator asks how busy a booth has been, how many sessions ran in a period, or wants to inspect individual sessions.' Also names the alternative for money totals (get_revenue_summary), giving clear direction on tool selection.

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 (readOnlyHint, destructiveHint, openWorldHint), the description discloses key behavioral traits: the wallet excludes cash and voucher income, so results understate real revenue for cash-taking operators. It also mentions ordering ('newest first') and what types of transactions are included. This is valuable context that annotations alone do not provide, and there is 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?

The description is three sentences, each earning its place: the first defines the resource and scope, the second gives clear usage guidance, and the third provides a crucial misuse warning and alternative. It is front-loaded with the most important information and contains no fluff.

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 this simple list tool, the description covers purpose, included/excluded transaction types, ordering, use cases, and a critical caveat about revenue understatement. Combined with full schema coverage, a true output schema, and annotations, there are no gaps in contextual information. The description is complete for an agent to select and invoke this 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?

The input schema already provides 100% coverage for all three parameters (to, from, limit) with clear descriptions and constraints. The description does not add any additional parameter-specific semantics beyond the general 'newest first' ordering, which is already implied by the schema. With complete schema coverage, a score of 3 is appropriate—the schema carries the burden.

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 opens with a precise definition: 'This operator's wallet ledger: gateway earnings, withdrawals and refunds, newest first.' This clearly identifies the resource (wallet ledger), specific transaction types, and ordering, immediately distinguishing it from sibling tools like get_revenue_summary. The verb 'get' is implicit in the tool name and title, and the description adds enough scope to remove ambiguity.

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 states when to use it ('Use for questions about the wallet, payouts or withdrawals') and when not to use it ('Do NOT use it to answer "how much did I earn"'), naming the alternative tool (get_revenue_summary). This is a model of clear guidance, leaving no doubt about tool selection.

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 annotations already declare readOnlyHint=true and destructiveHint=false, establishing this as a safe read operation. The description adds valuable behavioral context by scoping results to 'this operator owns' and explicitly stating what it does not return (booth designs, page layouts), which goes beyond the annotations without contradicting them.

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

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

The description is compact and structured with three front-loaded sentences: the first presents the primary function and output fields, the second gives usage timing and rationale, and the third states an exclusion. Every sentence carries essential information with no filler, and the core verb 'List' appears at the very beginning.

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 read-only list tool with an output schema present, the description is fully adequate. It covers purpose, when to call it, why to call it (project ID for filtering), and what it explicitly does not return, making the tool's behavior and role among siblings clear.

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 to explain. Per the baseline rule for 0-parameter tools, a score of 4 is appropriate; the description does not need to add parameter details because none exist.

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 the specific verb 'List' and clearly identifies the resource as 'photobooth projects this operator owns', enumerating the returned fields (id, name, slug, active, currency). This specificity distinguishes it from sibling tools like get_project (singular) and other statistics tools, making its purpose unmistakable.

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

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

It gives explicit when-to-use guidance: 'Call this first whenever the operator names a booth' and explains why ('you need the project id to filter any other tool by booth'). It also provides an exclusion by stating 'Does not return booth designs or page layouts', which helps the agent avoid using it for those needs.

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 the read-only nature is covered. The description adds a unique behavioral detail: 'Works without a connected account,' which informs the agent that no authentication or account setup is required. This is valuable context beyond what annotations provide, though it stops short of describing output structure (which an output schema likely covers).

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, immediately front-loads the verb and object ('Search the Dreambooth Studio documentation and FAQ'), and then adds essential usage guidance. No wasted words; every clause contributes to understanding when and how to use the tool.

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 documentation search tool with a complete input schema and an output schema present, the description fully covers its purpose, usage context, and an important behavioral nuance (no account needed). It is complete and self-contained.

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 descriptions for all three parameters (query, limit, locale). The description does not add any parameter-specific semantics beyond what the schema already states. Per the calibration baseline, a score of 3 is appropriate since the schema does the heavy lifting.

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 'Search' and the specific resource: 'Dreambooth Studio documentation and FAQ.' It also lists the exact topics covered, which distinguishes it from sibling tools that operate on accounts and project data. The purpose is unambiguous and highly specific.

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 instructs when to use this tool: 'Call this before answering any question about the product, pricing, packages, hardware, printing, subscriptions, or troubleshooting.' It also provides a clear behavioral directive: 'answer from the docs rather than from memory.' This goes beyond simple context and gives actionable guidance.

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