Maqui Analytics

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

With no annotations, the description carries full burden. It discloses the returned metrics (path, page views, etc.) but does not detail behavioral traits like rate limits, pagination, or what happens when no data exists. Adequate but not comprehensive.

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

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

Two sentences, front-loaded with purpose and key metrics. Every sentence adds value, 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?

Given the tool's simplicity (1 parameter, no output schema), the description sufficiently states what it does and when to use it. It lacks examples of output format, but overall complete enough for this complexity.

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 parameter (date_range), and the schema description includes examples. The tool description adds no extra information beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool provides the most visited pages from GA4 with specific metrics (path, page views, sessions, unique users, etc.) and gives usage examples like 'páginas más vistas' or 'top landing pages', distinguishing it from sibling tools like ga4_sources or ga4_summary.

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 lists explicit use cases ('Usar para...'), indicating when to use the tool, but does not mention when not to use or alternatives among siblings. It provides clear context for typical 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?

No annotations are provided, so the description carries the burden. It states the tool returns sessions, users, and conversions, implying a read-only query. However, it does not disclose any behavioral constraints like rate limits, data freshness, or whether multiple calls are needed.

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: first defines the tool's output, second gives example user queries. It is front-loaded and contains no filler. Every sentence adds value.

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

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

For a simple tool with one parameter and no output schema, the description is adequate. It names the key metrics returned. It could be improved by noting that the data is from GA4 and may have sampling, but given the simplicity, it's mostly complete.

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

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

Schema coverage is 100% for the single parameter 'date_range'. The schema already describes its format with examples. The description does not add new semantic meaning beyond what is in the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states 'De dónde vienen los visitantes del sitio: source/medium...' with specific examples (google/organic, facebook/social) and metrics (sesiones, usuarios, conversiones). It effectively distinguishes from siblings by focusing solely on traffic sources.

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

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

The description provides explicit usage contexts in Spanish: 'Usar para "de dónde viene el tráfico", "fuentes de tráfico", "canales de adquisición", "qué porcentaje es orgánico vs pagado".' This tells the agent exactly when to invoke the tool.

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?

There are no annotations provided, so the description must convey behavioral traits. It lists metrics but does not disclose response format, data freshness, read-only nature, or any limitations. For a simple summary tool, the lack of behavioral detail is acceptable but not thorough.

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 concise with three sentences, each serving a clear purpose: listing metrics, providing a usage directive, and explaining typical client intent. No redundant information.

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 tool with one parameter and no output schema, the description adequately covers purpose and usage. However, it lacks specification of return format (e.g., table, text) which could help an agent anticipate output 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?

The input schema has one parameter (date_range) with 100% description coverage, so description adds no extra value. The baseline score of 3 is appropriate.

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

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

The description clearly states the tool provides web traffic metrics from GA4 (sessions, users, page views, etc.) and explicitly instructs when to use it for typical client questions about visits and traffic. This differentiates it from sibling tools like ga4_pages or ga4_sources.

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 'Usar SIEMPRE para preguntas sobre visitas, tráfico del sitio, etc.' which provides strong usage context. It does not explicitly list alternatives or when not to use, but the sibling tools are available in context for more specific 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?

Without annotations, the description must disclose behavioral traits. It states the tool returns per-campaign data with specific fields, but does not mention any side effects (though none expected), data freshness, or limitations like pagination. Basic transparency is present but could be more explicit.

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 concise with one sentence listing outputs and example queries. It is front-loaded and every part adds value 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 simplicity of the tool (one optional parameter, no output schema), the description covers core functionality and use cases. It could mention the output format (e.g., list of campaigns) but overall is sufficient.

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 covers 100% of parameters with detailed description including examples. The tool description does not add parameter information beyond what's in schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states it provides a campaign-by-campaign breakdown of Google Ads with specific metrics like name, status, spend, clicks, etc. It also includes example queries that distinguish it from sibling tools like gads_keywords or gads_summary.

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

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

The description provides clear example use cases ('qué campañas de Google Ads tenemos', 'campaña que mejor funciona') which help the agent decide when to use this tool. However, it does not explicitly state when not to use it or compare with alternatives like gads_summary.

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

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

No annotations exist, so description must reveal behavior. It implies read-only data retrieval (no side effects), but doesn't explicitly state it's non-destructive, require permissions, or detail rate limits or data freshness. Adequate but not rich.

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

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

Two sentences, no redundant words. Front-loads purpose and metrics, then usage guidance. Highly efficient.

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

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

For a simple tool with one parameter, the description fully explains purpose, usage, and differentiation. No output schema needed as return type is implied by context.

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 covers 100% of the single parameter (date_range) with examples. The description adds no additional parameter info beyond what's in the schema, so 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 returns keywords bid on in Google Ads with specific metrics (spend, clicks, conversions, CPC, match type). The verb 'pujamos' and the list of metrics distinguish it from sibling tools.

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 provides example queries ('keywords que compramos', 'palabras clave de mis campañas') and warns not to confuse with search terms, differentiating it from gads_search_terms. This gives 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?

The description states that it shows exact terms with clicks and spend, implying a read-only operation. Since no annotations are provided, the description carries the burden, but it does not disclose additional behavioral traits like permissions or scope (e.g., no user/workspace filtering).

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 concise sentences front-load the main purpose and usage, with no wasted words.

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

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

Given low complexity (1 parameter, no output schema), the description covers purpose, usage, and examples adequately. It does not specify return format, but that is not required when 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 parameter 'date_range', which already has a description. The tool description adds context but does not enhance understanding of the parameter beyond what the schema 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?

Clearly states the tool shows real user search queries that triggered Google Ads, with exact terms, clicks, and spend. It distinguishes from siblings by focusing on search terms rather than keywords or campaigns.

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 provides use cases: finding opportunities (new keywords) and exclusions (irrelevant queries). Also gives example user intents like 'what users search'. However, it does not explicitly mention when not to use or suggest 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?

No annotations are provided, so the description must convey behavioral traits. It lists metrics but does not state whether the tool is read-only, whether it aggregates data, or any side effects. The description is insufficient for a tool with no 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?

The description is concise and front-loaded with the key purpose. Each sentence serves a purpose: defining the tool, listing metrics, and providing usage examples. No extraneous information.

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

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

The description explains the tool's scope and usage but lacks details about return format, pagination, or how it differs from more specific tools like gads_campaigns. Given the simple schema, it's adequate but not fully complete.

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

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

The input schema has 100% description coverage for its single parameter, so the description does not need to add parameter details. It adds no new meaning beyond the schema, meeting the baseline.

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 performance metrics for Google Ads (Search/Display/YouTube) and lists key metrics. However, it does not explicitly differentiate from sibling tools like gads_campaigns or gads_keywords, which provide more granular data.

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

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

The description provides explicit usage context with example queries (e.g., 'Google Ads', 'campañas pagas'), indicating when to use the tool. It lacks guidance on when not to use it or mention of alternative tools.

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

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

No annotations provided, so description carries full burden. Describes returned data and filters but does not explicitly confirm it's read-only or disclose rate limits or side effects.

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?

Concise, front-loaded with key info, no unnecessary words. Every sentence adds value.

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

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

Covers purpose, data returned, filters, prerequisite. No output schema needed given simple structure. Complete for the tool's complexity.

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%; description adds context by explaining data fields and pipeline statuses beyond the schema. Baseline is 3, and description elevates it.

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 retrieves leads/prospects from forms and campaigns with contact data and pipeline status. It distinguishes from sibling tools focused on analytics, sales, reviews, etc.

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 keywords for when to use ('leads', 'prospectos', etc.) and a prerequisite (CRM-enabled account). Lacks explicit when-not-to-use guidance, but sibling tools are distinct, so it's clear enough.

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

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

No annotations are provided, so the description carries the burden of disclosure. It clearly states the platforms covered and the data returned (average rating, total count, response rate, latest reviews with details). However, it does not mention potential limitations like pagination, number of latest reviews, or authentication requirements. Still, it adds significant value beyond the input schema.

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 of moderate length. The first sentence describes the tool's output, and the second provides usage triggers. No fluff, every part earns its place. Front-loaded with the most important information.

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 no output schema, the description compensates by detailing the returned fields (average rating, count, response rate, latest reviews with author, rating, text, responded status). For a tool with only two simple optional parameters and no nested objects, this is highly complete. It could mention the number of latest reviews returned, but it's still robust.

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 detailed descriptions for both parameters (date_range with examples, min_rating with range). The description does not add further parameter semantics beyond usage context. Baseline 3 is appropriate as the schema already handles parameter documentation.

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

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

Clearly states it retrieves reviews from Google Business Profile and Facebook, including specific metrics like average rating, total count, response rate, and latest reviews with author, rating, text, and response status. The description also provides example user queries, distinguishing it from sibling tools that focus on other platforms (GA4, GSC, IG, Meta, etc.).

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 lists when to use the tool: for terms like 'reseñas', 'reputación', 'qué dicen los clientes', 'rating en Google', 'reviews'. This provides clear usage context, though it does not explicitly exclude cases where alternative tools might be better, but the sibling tools are sufficiently different.

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

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

No annotations are provided, so the description must fully disclose behavior. It indicates the data it returns (sales metrics) but does not mention whether the operation is read-only, if any data is modified, authentication requirements, rate limits, or if results are real-time. The description is partially transparent but missing key behavioral details that an agent needs.

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 extremely concise: two sentences. The first delivers the core functionality and metrics, the second provides usage keywords and a constraint. No wasted words, and the most important information is 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?

Given the tool's scope (simple sales report with one parameter and no output schema), the description covers the essential data returned and the prerequisite. However, it lacks details on output format, update frequency, or whether historical data is computed on the fly. For its simplicity, it is reasonably complete but could include more operational context.

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% with one parameter. The description adds value by providing example date range formats (e.g., 'últimos 30 días', '2025-01-01 a 2025-01-31') and stating the default behavior (últimos 30 días), which goes beyond the schema's basic description.

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

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

The description clearly specifies that the tool retrieves restaurant sales data from the Fudo POS system, listing specific metrics like total billed, ticket count, average ticket, and channel breakdown. It also provides Spanish keywords for usage, effectively distinguishing it from sibling tools which cover web analytics, ads, and social media domains.

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

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

The description provides explicit keywords (e.g., 'ventas', 'facturación', 'ingresos') and a critical constraint: 'Solo disponible para restaurantes/locales con Fudo conectado.' While it does not explicitly state when not to use it or compare to alternatives, the sibling set is diverse enough that the purpose alone guides selection. It slightly lacks depth in exclusion criteria.

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

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

No annotations are provided, so description must cover behavioral traits. It does not mention read-only, auth requirements, or side effects. While likely a read-only query, the lack of explicit behavioral context is a gap.

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: first defines output, second provides usage guidance and sibling differentiation. No wasted words; information density is high and 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?

Given the simplicity (1 param, no output schema, no nested objects), the description covers purpose, data fields, usage examples, and sibling distinction. Could mention source (Search Console) or data freshness, but overall adequate.

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% for the single parameter (date_range). The description does not add meaning beyond the schema's explanation, so 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 returns pages with best organic visibility from Google Search Console, listing fields (URL, clics, impresiones, CTR, posición promedio). It distinguishes from ga4_pages, which covers total traffic.

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 use cases provided: "páginas con mejor SEO", "qué URLs rankean", "landings que reciben tráfico orgánico". Also explicitly states when not to use (for total traffic) and directs to ga4_pages.

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?

Lists the output fields (query, clicks, impressions, CTR, position) beyond schema. No annotations exist, so description carries burden. Lacks mention of read-only behavior or pagination, but for a listing tool this is acceptable.

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

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

Two sentences, front-loaded with core function and metrics. No wasted words, efficient and clear.

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 one parameter, no output schema, and no nested objects, the description adequately describes output and usage. Agent can confidently decide when to invoke.

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?

Single parameter `date_range` is fully described in schema (100% coverage). Description adds no further parameter details beyond context of use cases, which aligns with baseline score.

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

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

Description clearly states it returns organic Google search queries with metrics (clicks, impressions, CTR, position). Includes example use cases and explicitly differentiates from sibling tool `gads_search_terms`.

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 when to use (e.g., 'por qué nos encuentran', 'queries SEO') and when not to use (paid advertising via `gads_search_terms`). Names the sibling tool as an alternative.

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

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

No annotations exist, so description carries full burden. It adds context (organic only, not paid/GA4) but lacks details on data frequency, aggregation behavior, or any side effects.

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 concise sentences with bold emphasis on usage guidelines. Purpose is front-loaded and every line adds value with 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?

For a simple summary tool with one parameter and no required fields, the description covers purpose, scope, and usage boundaries. Could mention output format but acceptable given sibling tools handle details.

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 a detailed description for date_range. The tool description adds no additional parameter meaning beyond the schema, meeting baseline.

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 provides organic search visibility metrics (clicks, impressions, CTR, avg position) and explicitly excludes paid and GA4 data, distinguishing it from siblings like ga4_summary.

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 keywords to use (SEO, posicionamiento, etc.) and a direct alternative (ga4_summary) for 'visitas al sitio', giving clear when-to-use and when-not-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?

No annotations are provided, so the description carries full burden. It states the output (daily series with absolute and percentage) but does not explicitly confirm it is a read-only operation or disclose any behavioral traits beyond that. Adequate but could be more explicit.

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—short and to the point. The first sentence defines the core functionality, and the second provides usage context. 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?

Given the simplicity (single parameter, no output schema), the description adequately covers the tool's purpose and typical queries. It could mention read-only nature but is otherwise complete for a data retrieval 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?

Schema coverage is 100%, so baseline is 3. The description adds no new information about the date_range parameter beyond what the schema already provides (e.g., examples). No additional semantics are contributed.

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 returns daily series of absolute follower count and percentage growth over time, and provides specific usage phrases. It distinguishes from sibling tools like ig_summary or ig_hashtags by focusing on follower evolution.

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 includes explicit usage keywords (e.g., 'growth of followers', 'gained/lost followers', 'audience evolution'), guiding when to use. However, it does not mention when not to use or suggest alternatives, missing a small opportunity.

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

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

No annotations are provided, so the description carries full burden. It adds the behavioral detail that results are sorted by average reach, but does not discuss side effects, authentication, rate limits, or other operational traits. The ordering detail elevates it above a baseline 2.

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 concise sentences: first defines the tool, second states its utility, third gives example queries. No wasted words, 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?

Given a single optional parameter and no output schema, the description sufficiently covers purpose and usage. It could mention return format (list with reach counts) but is complete enough for a simple 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?

Schema coverage is 100% and the parameter description in the schema is clear. The tool description does not add further meaning beyond the schema, so baseline 3 applies.

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 returns hashtags used in Instagram posts sorted by average reach, and provides example queries like 'hashtags que funcionan', distinguishing it from sibling tools like ig_top_posts and ig_summary.

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

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

The description explicitly says when to use the tool (for identifying tags that generate visibility) and gives example use cases, but does not mention when not to use or alternatives among sibling tools.

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

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

No annotations are provided, so the description carries full burden. It explicitly states the tool is for organic content, lists the metrics returned, and implies read-only aggregated access. No destructive behavior or side effects are mentioned, which is appropriate for a simple aggregated metrics 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?

Two concise sentences that front-load the purpose and scope, with no wasted words. Every sentence adds value.

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

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

Given the simple schema (one optional parameter) and no output schema, the description covers purpose, scope, metrics, and usage hints. It is complete enough for an AI agent to decide when to call it, though it could mention the default behavior (last 30 days) which is in schema.

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

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

Schema coverage is 100%, and the description adds example date formats (e.g., 'últimos 30 días', 'enero 2025'). However, the schema already describes the parameter well; the description offers useful examples but not significant additional meaning beyond schema.

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

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

The description clearly states it provides organic (non-paid) Instagram metrics, lists specific aggregated metrics (reach, engagement rate, likes, etc.), and explicitly references queries about Instagram, social media, reach, or engagement. This differentiates it from sibling tools like gads_summary (paid) and ga4_summary (analytics).

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 specifies when to use: for organic Instagram questions without paid ad context. While it does not explicitly list exclusions or alternatives, the context and sibling tools imply that paid-related queries should use gads_summary or meta_summary. The guidance is clear and practical.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, authentication needs, rate limits, data freshness, or pagination behavior. For a data retrieval tool, this lack of behavioral context is a significant gap.

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

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

The description is a single, front-loaded sentence that conveys the main purpose efficiently. The inclusion of example phrases is slightly redundant but not excessive. It earns its place by providing contextual usage hints.

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 low complexity (3 optional parameters, no required), the description covers the basics: what it returns (caption, date, metrics, permalink) and sort options. However, it lacks details on output structure, maximum post count, or error handling. With no output schema, more explicit return info would be helpful.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions sorting options (engagement, reach, etc.) and includes example date ranges in the schema. The description adds minimal extra meaning beyond the schema, primarily listing return fields which are not 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 it returns top-performing Instagram posts sorted by metrics, and includes caption, date, metrics, and permalink. It provides usage phrases like 'mejores posts', which indicates its purpose. However, it could more explicitly differentiate from sibling tools like ig_summary, though the context of returning individual posts is implied.

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

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

The description gives example use cases ('mejores posts', 'qué contenido funcionó') but does not provide explicit guidance on when not to use this tool versus alternatives like ig_summary or ig_hashtags. It implies usage for performance queries but lacks exclusions or comparisons.

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

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

No annotations provided. Description implies read-only query by listing output fields, but does not disclose behavioral traits like pagination, timezone handling, or data limits. Partially transparent but lacks detail.

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: first lists output, second gives usage examples. Front-loaded with action word, no fluff. Highly concise.

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 list tool with one param and no output schema, description explains return values (fields) and usage context well. Lacks mention of parameter, but schema covers it. Nearly complete.

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

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

Input schema has one parameter (date_range) with 100% coverage and examples. Description does not reference the parameter or add beyond schema, so baseline 3 applies.

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 clearly states verb 'Desglose' (breakdown) and resource 'Meta Ads campaña por campaña'. It lists specific output fields (nombre, objetivo, estado, gasto, alcance, clics) and provides example queries. This distinguishes it from siblings like meta_summary.

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 gives example queries ('campañas de Meta Ads', 'qué objetivos tenemos en Facebook', 'performance por campaña') indicating when to use. Does not state exclusions or alternatives, but context from sibling names helps.

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

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

No annotations are provided, so the description must carry the burden. It implies read-only behavior by listing metrics, but does not explicitly state that the tool is non-destructive, idempotent, or safe. Adding 'read-only query' would improve transparency.

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 concise: two sentences plus a zero-waste list of metrics and usage examples. Every part serves a 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?

For a single-parameter tool with no output schema, the description adequately covers the metrics returned and usage context. It could mention the output format or aggregation (e.g., daily totals), but is sufficient for an AI agent to understand what results to expect.

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 covers the single parameter date_range with a description. The tool description does not add extra meaning beyond what's in the schema, but listing metrics in the description provides context for how the parameter affects results. Baseline 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the tool's purpose: 'Performance de Meta Ads (publicidad pagada en Facebook e Instagram)' and lists key metrics (gasto, alcance, etc.). It distinguishes itself from sibling tool ig_summary by specifying it's for paid ads.

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

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

The description provides explicit usage examples ('Usar para "Meta Ads", "Facebook Ads"...') and an explicit exclusion ('NO confundir con ig_summary (orgánico, no pagado)'). This gives clear when-to-use and when-not-to-use guidance.

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