mcp-server

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

Annotations provide only a title with no safety hints. The description compensates by disclosing data usage ('Feedback is used to improve future responses (RAG, analytics)'), which explains the side effects and persistence model. Does not mention idempotency or failure modes, but covers the critical behavioral aspect of data lifecycle.

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?

Well-structured with markdown headers organizing content into logical sections (When to use, Ratings, Categories, Feedback usage). Front-loaded with the core purpose. Length is appropriate given the tool's social/UX complexity, though the Ratings and Categories sections partially duplicate schema enums.

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 feedback collection tool with 100% schema coverage and no output schema, the description is complete. It covers invocation timing, parameter semantics, UX patterns, and data disposition (RAG/analytics). No gaps remain that would prevent correct agent 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 coverage is 100% (baseline 3). The description adds valuable semantic context beyond the schema: it frames ratings as satisfaction levels ('helpful and accurate', 'not satisfactory'), poses categories as evaluative questions ('Was the response accurate?'), and explains the RAG purpose of 'original_question'. This narrative framing aids agent reasoning.

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 opening sentence 'Collects user feedback on the provided response' provides a specific verb (collects) and resource (user feedback). It clearly distinguishes this tool from its analytics-focused siblings (execute_query, create_aggregation_view, etc.) by establishing a meta-level feedback function.

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?

Contains an explicit 'When to use this tool:' section with specific triggers ('After providing an analysis, a SQL query...'), includes UX guidance ('Naturally suggest: Was this response helpful? 👍 👎'), and defines the emotional context for soliciting feedback. While no alternatives are listed, none exist in the sibling set.

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 provide only a title with no safety hints. The description adds critical behavioral constraints: enforced naming rules (quanti_agg dataset, llm_ prefix), automatic dataset creation if missing, the distinction between CREATE and CREATE OR REPLACE operations, and the hard limit of 20 active views per project. No contradictions with annotations exist.

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 markdown structure with clear headers (When to use, Naming rules, SQL format, Example, Limits) front-loads critical information. Each section serves a distinct purpose—constraints, usage triggers, and examples—though the overall length is substantial, it avoids 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?

Given this is a complex write operation with strict schema constraints and no output schema, the description comprehensively covers naming enforcement, usage limits, and behavioral side effects (auto-created datasets). Minor gap: it does not describe the return value or error behavior when constraints are violated.

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?

While schema coverage is 100% (baseline 3), the description significantly enhances the 'sql' parameter by detailing the exact naming constraints (quanti_agg dataset, llm_ prefix), providing SQL format options (MATERIALIZED VIEW vs. PROCEDURE), and including a concrete code example that demonstrates valid syntax.

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 opening sentence explicitly states the tool creates 'a materialized view or stored procedure in the project's BigQuery data warehouse for data pre-aggregation.' It clearly distinguishes from sibling execute_query (on-demand vs. materialized) and list_aggregation_views (read vs. write operations) by emphasizing persistent storage creation.

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 dedicated 'When to use this tool' section provides explicit trigger phrases ('create a view', 'save this as a table', 'materialize this query') and specific scenarios (cross-channel reports, slow queries benefiting from materialization). This clearly delineates when to use this tool versus execute_query or other siblings.

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 behavioral annotations provided (only title), the description carries the full burden. It adequately discloses persistence ('saves'), visibility rules ('member' vs 'project' scope with team sharing implications), and content flexibility (SQL vs prompt-based). However, it lacks details on error handling (e.g., duplicate slug behavior) or idempotency, preventing a top score.

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?

Well-structured with markdown headers that front-load intent and organize supporting details (When to use, Available scopes, Best practices). Slightly verbose but every section provides actionable guidance for tool selection and invocation; no 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?

For an 8-parameter creation tool with no output schema, the description comprehensively covers the primary logic branches (scope selection, conditional project_id requirement, SQL vs prompt content modes). Minor gap: does not describe the return value or success confirmation on creation.

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%, setting a baseline of 3. The description adds valuable best-practice guidance beyond the schema: concrete examples for slug format (weekly_campaign_performance), usage guidance for SQL templates ('if it's generic and reusable'), and clarifies the relationship between scope='project' and the project_id requirement.

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 precise action verb ('Creates and saves') and clear resource ('use case'), immediately clarified as a 'reusable analysis'. This effectively distinguishes it from siblings like execute_query (which runs queries) and update_use_case/delete_use_case (which manage existing ones).

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?

Contains an explicit '**When to use this tool:**' section with specific trigger phrases ('save this analysis', 'remember this query') and contextual cues ('After building a SQL query the user wants to reuse'). This clearly signals when to select this tool over alternatives like execute_query or get_use_cases.

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 destructiveHint=true annotation, the description adds crucial behavioral context: the operation marks the view as 'dropped in Quanti's tracking' while noting that 'the actual BigQuery object may need manual cleanup.' This clarifies the exact scope of destruction. It also documents the 20-view limit constraint.

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?

Excellent structure with clear visual hierarchy (main action, When to use, Warning, Tip). Every sentence serves a distinct purpose. The warning about BigQuery cleanup is appropriately prominent for a destructive operation. 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 destructive 2-parameter tool with no output schema, the description provides adequate context including prerequisites, usage triggers (the 20-view limit), and cleanup warnings. Could be improved by mentioning error handling (e.g., what happens if view_id doesn't exist) or idempotency, but covers the essential behavioral traits.

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 fully documents both parameters including the instruction to get view_id from list_aggregation_views. The description's 'Tip' section reinforces this mapping but does not add significant new semantic meaning beyond what the structured 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?

The description opens with a specific verb ('Deletes') and clearly identifies the resource ('aggregation view/materialized view or procedure') and scope ('from the project'). It effectively distinguishes from sibling tools like create_aggregation_view (inverse operation) and list_aggregation_views (prerequisite for obtaining IDs).

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 an explicit 'When to use this tool' section with three specific scenarios, including the concrete constraint of 'maximum number of views (20)'. Includes a 'Tip' explicitly naming list_aggregation_views as a prerequisite, establishing clear workflow ordering.

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

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

Beyond annotations (destructiveHint: true), adds crucial context: states action is 'irreversible' and 'permanently' deletes, specifies auth constraint 'You can only delete use cases you created', and recommends confirmation workflow. Does not describe cascading effects or error states, but covers primary safety concerns.

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?

Well-structured with markdown headers (When to use, Warning, Permissions, Tip). Front-loaded with the core action. Every sentence earns its place; no redundancy. Appropriate length for a destructive operation requiring safety warnings.

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 single-parameter deletion tool with no output schema, covers irreversibility, ownership permissions, and confirmation needs. Missing explicit mention of error cases (e.g., 'not found') or potential cascading effects, but sufficiently complete given the tool's narrow scope and existing safety documentation.

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 the use_case_id parameter fully documented in the schema (type, format, data source). Description does not add parameter syntax details, but with complete schema coverage, 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 states 'Permanently deletes a use case you created'—a specific verb (deletes) + resource (use case) combination. It distinguishes from siblings like create_use_case and update_use_case by emphasizing 'permanently' and ownership constraint 'you created'.

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?

Contains explicit 'When to use this tool' section with bullet points covering explicit user requests and cleanup scenarios. Includes warning about irreversibility, permission constraints, and a tip to ask for confirmation—comprehensive guidance for a destructive operation.

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 declare readOnlyHint and idempotentHint; description adds critical BigQuery-specific behavioral constraints not in annotations—specifically the table formatting requirements ('Use dataset.table... Do NOT prefix with a project_id') which prevent common query errors.

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?

Extremely efficient—three sentences with bold formatting for scanability. Front-loaded with safety constraint ('read-only'), followed by resource, then specific syntactic rules. Zero冗余.

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 complete parameter coverage and clear behavioral constraints, description suffices for invocation. However, lacks any indication of return format (rows vs objects), result limits, or timeout behavior, which would be valuable for BigQuery execution given potential for large result sets.

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?

Despite 100% schema coverage (baseline 3), description adds significant value beyond schema: provides concrete table format examples (e.g., 'prod_google_ads_v2.campaign_stats') and explicit negative constraints ('Do NOT prefix') that clarify the sql parameter semantics more vividly than schema alone.

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 specific verb 'Executes' and clear resource 'read-only SQL SELECT query', explicitly scoping to BigQuery. The 'read-only' and 'No data modification allowed' clauses clearly distinguish this from sibling mutation tools like create_aggregation_view, delete_use_case, and update_use_case.

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 states 'No data modification allowed' establishing clear boundaries for when NOT to use. However, lacks explicit pointer to which sibling tool should be used for writes (e.g., create_aggregation_view) or when to prefer list_* convenience methods over raw SQL.

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 idempotentHint=true. The description adds that it searches 'docs.quanti.io' (external source context) but does not elaborate on behavior like result ranking, empty result handling, or rate limits. No contradictions with annotations.

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

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

Excellent structure with bold headers front-loading critical information. Bullet points for usage scenarios and exclusions maximize information density. No redundant or wasted sentences despite the length.

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 documentation search tool of low complexity, the description is complete. It covers purpose, usage boundaries, parameters, and sibling differentiation. Minor gap: does not describe the return format (excerpts vs. full pages), though this is less critical given the tool's straightforward utility.

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%, establishing a baseline of 3. The description adds value by providing concrete query examples ('how to configure Google Ads?', 'what is the lookback window?') and explicitly listing valid topic filter values, reinforcing parameter intent beyond the schema strings.

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 ('Searches') and resource ('official Quanti documentation'), clearly stating the tool's function. It distinguishes from siblings through the explicit 'This tool does NOT replace' section naming get_schema_context, list_prebuilds, and others.

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?

Contains explicit 'When to use this tool' section with concrete scenarios (e.g., 'how to configure BigQuery?', 'what is a connector?') and a 'This tool does NOT replace' section listing specific alternatives. Provides perfect guidance for agent 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?

Annotations declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it specifies exactly what data is retrieved ('name, prompt or SQL template, project') and explains the origin context (redirected from Quanti interface). No contradictions with annotations.

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

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

Three sentences total, front-loaded with purpose. First sentence declares the action. Second sentence provides workflow context. Third sentence clarifies return value and execution intent. Zero redundancy—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?

Despite no output schema, the description comprehensively lists the returned data structure ('name, prompt or SQL template, project'). It covers the complete workflow (pre-configuration → redirect → retrieval) for this single-parameter read operation. Nothing critical 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% (launch_id fully described). Baseline is 3. The description adds workflow context about the parameter's source ('redirected here with a launch_id', 'provided in the initial prompt'), integrating the UUID into the narrative of how the user arrives at this tool.

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 specific verb ('Retrieves') and resource ('full context of a Quanti launch session'). Clearly distinguishes from sibling tools like get_project_context or get_schema_context by specifying the unique workflow: 'pre-configured an analysis from the Quanti interface and was redirected here with a launch_id'.

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 when-to-use context: when 'the user has pre-configured an analysis from the Quanti interface and was redirected here with a launch_id.' Explains the prerequisite (launch_id from redirect) and implied next step (get details to execute). Lacks explicit 'when not to use' or named alternatives, but the workflow specificity provides strong implicit 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety profile. The description adds value by disclosing what data is retrieved ('active connectors, available datasets'), but does not mention pagination, caching, error conditions, or authentication requirements beyond the structured 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 efficiently structured sentences with zero waste. The first sentence front-loads the action and scope; the second provides prerequisite context. Every word 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?

Given the tool's simplicity (2 parameters, flat schema, 100% coverage) and presence of readOnly/idempotent annotations, the description adequately covers purpose, content scope, and usage prerequisites. No output schema exists, but the description reasonably summarizes the return value conceptually.

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%, establishing a baseline of 3. The description adds meaningful workflow context by specifying that the project_id parameter should be sourced from list_projects ('Use the folderId obtained from list_projects'), providing semantic linkage beyond the raw schema 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 states a specific verb ('Gets') and resource ('context of a project'), with parenthetical clarification of what the context includes ('active connectors, available datasets'). It references 'list_projects', hinting at workflow relationships with siblings, but does not explicitly contrast its function against all available alternatives.

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 prerequisite guidance ('Use the folderId obtained from list_projects'), establishing a clear workflow dependency on the sibling tool. However, it lacks explicit 'when not to use' guidance or named alternatives for different use cases.

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 declare readOnlyHint and idempotentHint, so the description doesn't need to cover safety. It adds valuable behavioral context: it specifies the return structure (tables, fields, semantic definitions) and discloses a critical formatting constraint—'Use ONLY the dataset.table format...NEVER add a project_id'—which prevents query errors.

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?

Well-structured with two focused paragraphs: purpose/invocation timing first, critical formatting constraints second. The bold/caps 'IMPORTANT' section is appropriately aggressive to prevent destructive formatting errors. No extraneous sentences, though the formatting warning could be considered slightly visually noisy.

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 no output schema, the description compensates by explaining what gets returned (tables, fields, semantic definitions). It adequately covers the relationship to sibling tools (specifically execute_query) for a 5-parameter tool. Could strengthen by mentioning default behaviors (max_tables: 5) in description text.

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%, establishing baseline 3. The description elevates this by providing an example question ('What are the campaign spend this month?') and crucial contextual constraints about the project_id parameter (don't prepend it to table names despite it being a required parameter).

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

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

The description clearly states it 'Builds the schema context' and 'Returns relevant tables with their fields,' specifying the resource (BigQuery schema metadata). It distinguishes from execute_query by instructing to call it 'before writing SQL,' though it doesn't explicitly differentiate from similar context tools like get_project_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 explicit temporal guidance: 'Call this function with the user's question before writing SQL.' This clearly establishes when to invoke the tool in the workflow. However, it lacks explicit 'when not to use' guidance or named alternatives (e.g., when to use get_project_context instead).

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 cover readOnly/idempotent safety; description adds valuable domain context that use cases contain 'SQL templates and business definitions' (helps agent understand return value nature). Doesn't explain relevance ranking or result format, so moderate value-add beyond annotations.

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

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

Three well-structured sentences: purpose, content explanation, usage guidance. Each earns its place. Slightly qualifying because sentence 3 somewhat overlaps with sentence 1's intent clause, though 'discover' adds the exploration angle.

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?

Good domain context explaining what use cases are. Absent output schema means description should hint at return structure—it does by mentioning SQL templates/business definitions. Could strengthen by noting results are ranked by relevance to the question.

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%, establishing baseline 3. Description maps 'user's question' to the question parameter semantically, but doesn't add syntax guidance, example values, or relationships between category and question parameters beyond what's 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?

Clear verb 'Searches' and resource 'use cases'. Explains what use cases contain (SQL templates, business definitions). However, it doesn't explicitly differentiate from sibling 'list_my_use_cases' or 'list_project_use_cases'—it hints at search vs list with 'discover' but lacks explicit contrast.

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 'Use this function to discover available analyses' which implies exploratory usage. However, it lacks explicit when-to-use guidance versus the various list_* siblings or prerequisites for the question parameter. Adequate but not directive.

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 declare readOnlyHint=true and idempotentHint=true. Since no output schema exists, the description adds significant value by detailing the JSON array response structure (ID, full_name, type, SQL, description, creation date). However, it omits pagination behavior, permission requirements, or performance characteristics for large projects.

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?

Excellent structure with bold headers ('When to use this tool:', 'Response format:') creating clear information hierarchy. Purpose statement is front-loaded. Bullet points improve scannability. No redundant or filler text.

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 single-parameter list operation with good annotations, the description is complete. It compensates for the missing output schema by fully describing return fields, provides usage guidance, and distinguishes from sibling mutations. No critical gaps remain.

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 100% description coverage with project_id fully documented ('The project folderId (e.g., p57d4af1b)'). Description does not explicitly discuss parameters, but with complete schema coverage, no additional parameter semantics are required in the description text.

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 specific verb 'Lists' plus resource 'aggregation views (materialized views and procedures)' and scope 'created for a project'. The parenthetical clarification distinguishes this from generic views, and the verb clearly differentiates it from sibling tools create_aggregation_view and delete_aggregation_view.

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?

Contains explicit 'When to use this tool:' section with three specific scenarios including natural language triggers ('what views exist?', 'my aggregations') and workflow guidance ('Before creating a new view to check it doesn't already exist', 'To get the view ID for deletion'). Explicitly maps to sibling operations.

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 cover read-only/idempotent safety, the description adds crucial behavioral context: the visibility constraints ('private and only visible to you') and the structural contents of returned use cases ('business description and optionally a SQL template').

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?

Well-structured with clear markdown headers (**What is**, **When to use**, **Visibility**). Information is front-loaded with the core action, and every sentence serves a specific purpose without 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 lacking an output schema, the description adequately completes the picture by defining what a use case is (the items being listed) and its visibility constraints. Given the tool's simplicity (zero params) and the existence of sibling tools, this level of description is sufficient 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?

Input schema contains zero parameters. Per evaluation rules, this establishes a baseline score of 4, which is appropriate as there are no parameter semantics to describe.

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 the specific action 'Lists' and resource 'your personal use cases', explicitly defining the scope as 'member' to distinguish from the sibling 'list_project_use_cases'. It defines the resource type 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?

Provides explicit 'When to use this tool' section with three distinct scenarios (retrieving saved items, duplicate checking, ID retrieval for mutations). While it differentiates implicitly via 'scope: member' and 'private', it does not explicitly name the alternative tool (e.g., list_project_use_cases) for project-scoped queries.

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 declare readOnlyHint and idempotentHint; the description adds significant behavioral context including the complete JSON response structure (fields, types, is_metric flag meaning) and clarifies that the optional project_id parameter 'verifies project access' rather than filtering results. No contradictions with annotations.

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

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

Uses markdown headers (**What is a prebuild?**, **When to use**) to structure dense information efficiently. The content is front-loaded with the core purpose, followed by conceptual definitions, usage scenarios, sibling differentiation, response format details, and examples—every section serving a distinct purpose without 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?

Given the absence of an output schema, the description comprehensively compensates by detailing the exact response format including field metadata (name, type, description, is_metric) and explaining the semantic difference between metrics and dimensions. This fully addresses the tool's complexity and return value structure.

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?

While the schema has 100% description coverage, the description adds valuable semantic context by enumerating concrete SKU examples (googleads, meta, tiktok-organic, amazon-dsp, etc.) and clarifying the access verification behavior of the optional project_id parameter.

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 opening sentence 'Lists pre-configured reports (prebuilds) available for a connector' provides a specific verb and resource. It explicitly distinguishes from the sibling tool get_schema_context via a dedicated comparison section explaining that list_prebuilds discovers which reports exist while get_schema_context retrieves actual BigQuery schema.

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?

Contains an explicit 'When to use this tool:' section with four specific scenarios, including critical sequencing guidance 'BEFORE get_schema_context'. It clearly contrasts alternatives by mapping list_prebuilds to catalog discovery and get_schema_context to effective data retrieval.

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 cover read-only/idempotent safety. Description adds valuable scope context ('accessible by the user') clarifying authorization-based filtering, and behavioral pattern ('discover') indicating catalog enumeration. No contradictions with annotations.

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

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

Two sentences, zero waste. First sentence defines operation, second provides workflow guidance. Information-dense and appropriately front-loaded.

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?

Adequate for a discovery tool with no output schema. Explains what it returns (projects list) and workflow context. Minor gap: doesn't describe project entity structure/fields returned, but sufficient for tool 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?

Zero parameters present, meeting the baseline score of 4. No parameter documentation required or present.

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 'Lists' + resource 'projects' + scope 'accessible by the user'. The phrase 'discover available projects' clearly positions this as the enumeration/discovery entry point, distinguishing it from sibling retrieval tools like `get_project_context` which imply prior selection.

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?

Excellent explicit guidance: 'Call this function first to discover available projects.' Establishes clear workflow order (discovery before project-specific operations) and implicitly contrasts with tools requiring a project identifier.

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 declare readOnlyHint and idempotentHint; description adds valuable visibility context ('visible to all project members') explaining the collaborative/sharing model without repeating annotation hints. 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?

Excellent markdown structure with bold headers ('When to use', 'Visibility'), bullet points for scannable triggers, and zero wasted words. Main action is front-loaded in the first sentence.

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?

Comprehensive for a read-only list operation: covers what entities are returned, visibility scope, usage triggers, and prerequisites (need project_id from list_projects). Appropriate given annotations cover safety profile and no output schema exists.

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% for the single project_id parameter, which is fully documented in the schema. Description provides baseline adequate coverage by referencing 'project team' contextually but does not add parameter syntax or format 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?

Uses specific verb 'Lists' with clear resource 'use cases shared with the project team' and distinguishes scope from siblings like list_my_use_cases via 'project team' and 'colleagues' language, reinforced by the '(scope: project)' notation.

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?

Contains explicit 'When to use this tool:' section with three concrete scenarios including the specific trigger phrases 'team analyses' and 'project use cases', plus workflow guidance to check before sharing to avoid duplicates (implicitly referencing create_use_case).

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 declare readOnlyHint/idempotentHint; description adds critical behavioral context not in structured data: defines 'scheduled query' concept, and crucially documents the JSON response format/fields since no output schema exists. No contradictory information.

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?

Well-structured with markdown headers and clear sectioning. Purpose is front-loaded in the first sentence. Length is justified by the need to explain domain concepts (what is a scheduled query) and compensate for missing output schema, though the 'What is' section adds slight verbosity.

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?

Fully compensates for missing output schema by documenting the JSON response structure and fields. Parameters fully covered by schema (100% coverage). Annotations cover behavioral safety. Combined, the definition provides complete information necessary for invocation and response handling.

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 100% description coverage. Description mentions available filters but largely mirrors schema text (e.g., examples 'prod_reports', 'active'/'disabled'). With complete schema coverage, baseline 3 is appropriate as description provides organizational value but limited semantic extension.

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 'Lists' + resource 'scheduled queries' + scope 'in the project's BigQuery'. Clearly distinguishes from sibling execute_query (which runs queries) and other list tools by specifying 'scheduled queries' as the target resource.

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?

Contains explicit '**When to use this tool:**' section with detailed bullet points covering diagnostic, audit, and status-check scenarios. Effectively maps user intents ('what are my BigQuery pipelines?') to the tool. Lacks explicit naming of alternative tools (e.g., 'use execute_query to run ad-hoc queries'), preventing 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 minimal annotations provided, the description carries full behavioral burden: it discloses the long-running nature ('10-30 minutes'), async completion signal ('email when results are ready'), and precise side effects (writes to 'mmm_channel_summary' and 'mmm_weekly_contributions' tables).

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?

Excellent structure with bold headers front-loading critical information (Prerequisite, Duration, Results). Every sentence provides essential operational context without redundancy; no 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?

Despite lacking an output schema, the description fully compensates by specifying result locations (specific table names), notification mechanism (email), and follow-up actions (query via execute_query), making it complete for this long-running operation.

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 100% description coverage, establishing a baseline of 3. While the description reinforces the origin of 'account_id' from 'setup_mmm' in the Prerequisite section, this information is already present in the schema property descriptions, adding minimal new semantic 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 opens with a specific verb ('Launches') and resource ('Marketing Mix Modeling study'), and immediately distinguishes this tool from its sibling 'setup_mmm' by specifying it operates on 'previously configured' studies.

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 states the prerequisite ('Must have called setup_mmm first'), mentions the specific output destination (data warehouse tables), and references the sibling tool 'execute_query' for retrieving results, providing clear when-to-use 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 minimal annotations (title only), description carries full burden effectively. Explains MMM concept, SQL dialect requirements (BigQuery/Snowflake/Redshift), column schema constraints (time column requirements), and granularity standards. Could improve by stating whether configuration is persistent or idempotent.

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?

Well-structured with clear headers (What is MMM?, Recommended workflow, Input queries format). Content is front-loaded with purpose statement. Slightly verbose but every section earns its place by providing necessary domain context for a complex statistical modeling 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?

Comprehensive for a 9-parameter configuration tool with no output schema. Covers domain concept (MMM), workflow integration, input validation rules, and data warehouse compatibility. Missing only explicit success/failure behavior description, but validation step implies user review before execution.

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% (baseline 3). Description adds substantial value beyond schema by detailing input_queries structure: specific required columns per role ('kpi', 'channel', 'exogenous'), time column format requirements, and SQL dialect adaptation needs. This contextualizes the raw schema significantly.

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 ('Configures') + resource ('Marketing Mix Modeling study'). The 'Recommended workflow' section explicitly distinguishes this from siblings by stating get_schema_context must be used first and run_mmm comes after validation, creating clear sequencing boundaries.

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 5-step workflow including prerequisites ('Use get_schema_context to discover') and successor actions ('Call run_mmm to launch'). The validation step (step 4) implies when-not-to-proceed, offering clear decision points.

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 minimal annotations (only title), description carries the burden. It adds critical permission context ('You can only modify use cases you created') and implies mutation. However, it lacks disclosure on failure modes (invalid UUID), idempotency, or return values, which are important behavioral gaps for a mutation 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?

Excellent structure with bold headers (**When to use**, **Permissions**, **Tip**) creating scannable sections. Main purpose is front-loaded in the first sentence. Zero redundancy; every line provides actionable guidance not found in structured fields.

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 100% schema coverage but no output schema and minimal annotations, the description is nearly complete. It covers prerequisites, permission constraints, and typical update scenarios. Minor gap: no mention of error handling for invalid IDs or the response format, though this is partially mitigated by the prerequisite tip.

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% (baseline 3). Description adds value by functionally grouping parameters in the 'When to use' bullets (e.g., linking 'description or SQL' to specific use cases) and explicitly referencing use_case_id acquisition via sibling tools in the tip, providing workflow context beyond raw schema 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?

Opens with specific verb 'Updates' + resource 'use case' + scope 'that you created', clearly distinguishing it from sibling create_use_case (new vs. existing) and delete_use_case. The 'When to use' bullet points further clarify the specific editable fields (description, SQL, category).

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?

Explicit 'When to use this tool' section lists three specific scenarios (improve description/SQL, fix errors, change category). The 'Tip' explicitly names prerequisite sibling tools (list_my_use_cases, list_project_use_cases) to obtain the required ID, providing clear workflow guidance.

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