Buscador Google

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

Annotations already establish readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds behavioral context beyond annotations by explaining the browser login flow, token permanence vs session-only scope, and no-arg behavior. It does not describe error cases or response format, but it covers the key interaction patterns.

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 longer than average but every segment adds information: login method, permanent config option, session-only option, and no-arg behavior. It is well-structured with 'Best' and 'Or' markers, though slightly dense and could be tightened.

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 covers invocation scenarios and the no-arg link behavior, but there is no output schema and the description does not specify what the tool returns when a token is passed, such as success/failure indicators or session details. For a tool with a nontrivial interactive flow, this is a notable gap.

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 0%, but the description fully explains the one parameter: token is a JWT pasted 'after the user pastes', and omitting it triggers the link-return behavior. This compensates completely for the bare schema definition.

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 and resource: authenticate/login for IDE agents via browser token exchange. It clearly distinguishes itself from siblings like report_bug and show_version by explaining the login workflow rather than generic tooling.

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

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

It gives explicit when-to-use guidance: prefer adding the token to server config for permanent access, or paste the token for session-only login, or call with no args to get the login link. This is strong routing guidance with alternatives clearly stated.

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?

As annotations já cobrem readOnly, idempotente e não destrutivo, então a descrição não precisa repetir isso. Ela acrescenta contexto útil além das annotations: limite de até 100 consultas por chamada e quais informações cada resultado traz (título, autores, publicação, ano, citações).

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

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

A descrição é curta, direta e sem redundância. A primeira frase define o propósito e o retorno; a segunda informa um limite operacional importante. Cada frase contribui.

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?

Para um tool com 7 parâmetros, 0% de descrição no schema e sem output schema, a descrição é incompleta. Faltam orientações sobre filtros opcionais, paginação, formato dos resultados e diferenças em relação aos irmãos de busca. O tool é utilizável no básico, mas não o suficiente para uso avançado correto.

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?

A cobertura do schema é 0%, então a descrição precisaria explicar os parâmetros. Ela só esclarece parcialmente 'consultas' ao dizer que aceita até 100 consultas por chamada. Os demais parâmetros (pais, local, idioma, limite, pagina, periodo) não têm significado descrito, dificultando o uso correto.

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?

A descrição usa verbo específico ('Busca'), recurso claro ('artigos no Google Acadêmico') e lista os campos retornados: título, autores, publicação, ano e citações. Isso diferencia o tool dos irmãos de busca (web, imagens, notícias, patentes 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?

O uso é implícito: 'busca artigos no Google Acadêmico' indica que deve ser usado para pesquisas acadêmicas, mas não há orientação explícita de quando preferi-lo a busca_google_web ou a outros irmãos. Não há exclusões ou alternativas nomeadas.

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 establish readOnlyHint=true and idempotentHint=true. The description adds useful behavioral context: the dependency on the cid field, the kind of data returned, and the batch limit. Pagination behavior is not mentioned, but the annotations lower the burden for safety-related 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 three sentences, front-loaded with the core action, and contains no filler. Every sentence adds value: what the tool does, how the identifier is obtained, and the call limit.

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

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

For a read-only tool with no output schema and zero parameter descriptions, the description covers the main purpose and required parameter well. However, it omits the meaning and usage of 'pagina_token', which is important for pagination, and does not clarify the optional 'pais' and 'idioma' parameters. This is a noticeable gap.

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 0%, so the description must compensate. It adds meaning to the required 'cids' parameter by explaining its source (cid from sibling tools) and the 100-item limit. However, it does not explain 'pais', 'idioma', or 'pagina_token', leaving some parameter semantics to inference.

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 and resource: 'Lê as avaliações de um estabelecimento no Google', and lists the data returned (nota, data, texto). It also distinguishes this tool from sibling search tools by explaining that it consumes the 'cid' produced by busca_google_lugares or busca_google_mapas.

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 explicit workflow context: find the place via the sibling tools and then read its reviews using the returned cid. It also states a practical limit of 100 establishments per call. It does not explicitly discuss when not to use the tool, but the guidance is 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?

Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds a useful behavioral constraint: up to 100 queries per call, and discloses what the tool returns. This goes beyond what the annotations provide.

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 with no filler. The core purpose and return fields are front-loaded, followed by the capacity constraint. Every sentence provides useful 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 tool with 7 parameters, no schema descriptions, and no output schema, the description is incomplete. It explains the main purpose and output fields but does not clarify parameter formats, defaults, pagination semantics, or date/period behavior, which are needed for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It only adds meaning for 'consultas' via the 100-query limit; the other six parameters ('pais', 'local', 'idioma', 'limite', 'pagina', 'periodo') receive no explanation, and the enumeration values are left undefined.

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

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

The description clearly states the specific verb 'Busca imagens' and resource 'Google imagens', distinguishing it from the sibling search tools. It also lists concrete return values: image URL, thumbnail, dimensions, and source page.

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 is clear that this tool is for Google image searches, and the capacity limit 'Aceita ate 100 consultas por chamada' adds practical usage context. It does not explicitly mention exclusions or alternatives, but the resource and output make the appropriate use case obvious.

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

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

Annotations already mark readOnly, idempotent, and non-destructive, so the description does not need to restate safety. It adds concrete behavior: up to 100 queries per call, per-city/neighborhood querying, and the returned contact fields. 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?

Three sentences, each adds distinct value: output fields, use case, and batch limit. Information is front-loaded with the most important details and there is no filler.

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 states the return fields and the core usage pattern, which is important given there is no output schema. However, with 7 parameters and no schema descriptions, an agent has to infer several optional parameters and the exact response format. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must carry parameter semantics. It clarifies that a query is by city or neighborhood and that up to 100 queries are accepted, addressing `consultas`, but it leaves pais, local, idioma, limite, pagina, and periodo entirely unexplained. This partial compensation is insufficient for a 7-parameter 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 it searches Google establishments and returns address, phone, website, rating, and review count. Positions itself as 'a ferramenta de prospecção local', which distinguishes it from sibling Google-search tools. This is a specific verb+resource description, not a tautology.

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 frames the tool as local prospecting and says one query per city or neighborhood returns a contact-ready list. It gives clear context for when to use it but does not name sibling alternatives or state when not to use it, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations: it returns twice as many establishments per query, includes coordinates, and accepts up to 100 queries per call. This is useful operational information without contradicting the 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 three concise sentences with no filler. The main purpose and unique selling point are front-loaded, followed by usage guidance and the call limit. 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?

While the description covers purpose, alternatives, and one key limit, it is incomplete for a tool with 7 parameters, no schema descriptions, and no output schema. Key parameter semantics are missing, and the 'periodo' enum values are not explained. An agent would likely need additional information to invoke the tool confidently with non-default parameters.

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 0%, so the description must compensate for parameter clarity, but it only indirectly clarifies 'consultas' by mentioning the 100-query limit. The other six parameters (pais, local, idioma, limite, pagina, periodo) are left completely unexplained, leaving an agent to guess their expected formats and meanings.

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 and resource: it searches Google Maps and returns establishments with latitude/longitude coordinates. It also distinguishes itself from the sibling tool busca_google_lugares by mentioning the alternative by name, making the tool's identity immediately clear.

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 this tool ('quando precisar de cobertura ou do mapa') and when to prefer the alternative ('para volume, busca_google_lugares custa um terço do preço'). This gives an agent clear routing guidance with no need for inference.

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, so the safety profile is known. The description adds useful behavioral context beyond annotations by disclosing the result fields and the capacity limit ('Aceita até 100 consultas por chamada'), which helps set caller expectations.

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

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

The description is three short sentences with no filler. It front-loads the core purpose, then adds usage guidance and a capacity constraint. Every sentence contributes distinct 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?

Despite helpful safety annotations and a clear one-line purpose, the tool has 7 parameters, 0% schema description coverage, and no output schema. The description explains only 'periodo' and loosely references 'consultas', leaving little guidance for the remaining parameters. An agent would likely struggle to construct a fully valid call beyond the required 'consultas' field.

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 0%, so the description must carry parameter semantics. It explains the role of 'periodo' and hints at 'consultas' via the 100-query limit, but it does not clarify 'pais', 'local', 'idioma', 'limite', or 'pagina'. This leaves most required parameter choices undocumented.

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 ('Busca'), a clear resource ('notícias no Google News'), and the main returned fields ('título, fonte, data e link'). This makes the tool's purpose immediately distinct from sibling Google search tools such as busca_google_web, busca_google_imagens, and busca_google_academico.

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

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

The description gives clear usage context: combine with the 'periodo' parameter to monitor a subject over recent hours/days. It does not explicitly mention alternatives or when not to use this tool, so it falls short of a full 5, but the guidance is actionable and not implied.

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

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

The annotations already mark it read-only, idempotent, and non-destructive. The description adds useful behavioral details: it returns clean text plus metadata, it costs twice as much as a web search per URL, and it accepts up to 100 URLs per call. These details go beyond the annotations and do not contradict them.

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

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

Three short sentences deliver purpose, usage timing, cost, and capacity with no filler. 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?

For a simple read-only tool with two parameters and no output schema, the description is mostly complete: it covers what it returns, when to use it, cost, and URL limit. The only clear gap is the undocumented markdown parameter.

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 0% schema description coverage, the description carries the parameter-documentation burden. It explains that the urls array accepts up to 100 URLs per call, but it does not explain the optional markdown boolean or what it changes about the output.

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 that the tool reads a web page and returns clean text plus metadata, which is a specific verb and resource. It also distinguishes itself from the busca_google_* search siblings by saying it is used after a search to open interesting links.

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

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

It gives explicit usage context: use after a search, for opening links that interested. It does not explicitly name a when-not-to-use alternative, but the sibling search tools are clearly the alternative for actual search 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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds a useful behavioral constraint: 'Aceita até 100 consultas por chamada', which informs the agent about batch size limits beyond what annotations provide.

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 short sentences with no filler. The main purpose is front-loaded, and the batch limit is a concise, valuable additional detail.

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?

There is no output schema, so the description should explain return values, but it does not. With seven parameters and zero schema coverage, the optional parameters remain largely ambiguous, making the definition sufficient for a basic call with only consultas but inadequate for confident use of advanced options.

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 0%, so the description needed to compensate for the seven parameters. It only clarifies the query criteria and the 100-query batch limit; optional parameters such as pais, local, idioma, limite, pagina, and periodo are left undocumented, and the enum values of periodo are unexplained.

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 and resource, 'Busca patentes no Google Patents', and lists searchable criteria: título, número, depositante e data. It is clearly distinguishable from sibling tools such as busca_google_academico or busca_google_imagens by the patent-specific target.

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 clearly establishes that this tool is for patent searches on Google Patents, which differentiates it from the other Google search siblings. It does not explicitly state when not to use it or name alternative tools, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context beyond annotations: the operation costs double a web search and accepts up to 100 queries per call. It also discloses what data the search returns, which helps set expectations.

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

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

Three short, purposeful sentences are front-loaded with what the tool does, followed by use cases and operational constraints. Every sentence adds distinct value with no filler or repetition.

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 covers the tool's core purpose, return fields, cost, and batch capacity, which is a solid start. However, with 7 parameters, 0% schema description coverage, and no output schema, it leaves important operational details unexplained, such as how pagination (pagina, limite) behaves, what values periodo accepts, and how country/language/location affect results.

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 0%, so the description carries the burden of explaining the parameters. It only hints at 'consultas' through the batch limit, but does not explain the semantics or formats of pais, local, idioma, limite, pagina, or periodo. The parameter names are somewhat self-explanatory, but the description itself does not compensate for the missing schema 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?

The description uses a specific verb and resource: 'Busca produtos no Google Shopping' and enumerates result attributes (preço, loja, nota, imagem). It also identifies use cases (price research, competition monitoring), which clearly distinguishes it from sibling tools like busca_google_web or busca_google_imagens.

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

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

The description gives clear context for when to use the tool: price research and competition monitoring. It also provides a cost signal ('Custa o dobro de uma busca web por consulta') that helps an agent decide between this and a cheaper web search, though it does not explicitly name alternatives or state when not to use it.

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?

As anotações já declaram readOnlyHint=true, idempotentHint=true e destructiveHint=false, e a descrição não contradiz isso. Ela adiciona contexto comportamental relevante ao informar que aceita até 100 termos por chamada, um limite prático que o agente precisa conhecer.

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

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

A descrição é curta e bem estruturada: a operação vem primeiro, seguida do caso de uso e da restrição de volume. Cada frase agrega informação sem repetir o nome da ferramenta nem o schema.

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?

Para uma ferramenta simples de leitura, a descrição cobre o propósito e o limite de chamada, mas não há output schema e a cobertura do schema é 0%. Faltam detalhes sobre o formato das sugestões retornadas e sobre como 'pais' e 'idioma' afetam a busca, então há lacunas relevantes para uso correto completo.

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?

A cobertura do schema é 0%, então a descrição precisaria compensar explicando os parâmetros. Ela menciona 'termo' e o limite de 100 termos, que se relaciona a 'consultas', mas não explica os parâmetros 'pais' e 'idioma', nem seus formatos esperados. A compensação é insuficiente.

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?

A descrição usa verbo específico ('Devolve') e recurso claro ('sugestões de autocompletar do Google'), diferenciando-se dos irmãos busca_google_web, busca_google_imagens, etc. Também contextualiza a finalidade (SEO e pesquisa de mercado), tornando o propósito imediatamente reconhecível.

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?

A descrição indica claramente quando usar: para descobrir como as pessoas realmente pesquisam um assunto, com aplicações em SEO e pesquisa de mercado. Não menciona exclusões nem alternativas explícitas, mas o contexto de uso é suficiente para orientar a seleção.

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

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

Annotations already mark this as read-only and non-destructive. The description adds valuable behavioral context beyond that: it supports up to 100 queries per call and returns specific fields (title, channel, duration, link). Nothing in the description contradicts the 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 short, front-loaded sentences with no filler. The main action is stated first, and the key limit is added in the second sentence. 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?

For a tool with seven parameters and no output schema, the description covers the core purpose, main returned fields, and an important input limit. However, it does not explain pagination behavior or the meaning of the periodo enum, leaving some ambiguity for an agent.

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 no property descriptions, so the description carries more weight. It usefully clarifies that 'consultas' accepts up to 100 queries, but other parameters—pais, local, idioma, limite, pagina, and the periodo enum—are left mostly to inference from their names and values.

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

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

The description clearly states a specific verb ('Busca'), a specific resource ('vídeos no Google'), and the key output fields (título, canal, duração, link). It is immediately distinguishable from sibling search tools like busca_google_imagens or busca_google_noticias.

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 intended use case—Google video search—is clear, and the added batch constraint ('até 100 consultas por chamada') gives practical usage guidance. It does not explicitly say when not to use it or name alternative tools, so it falls just short of a 5.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond those: it accepts up to 100 queries per call and returns direct answers/knowledge panels only when they exist. This gives an agent meaningful expectations about batch behavior and optional content.

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 sents with no filler. The main action and result types are front-loaded, and the batch capacity is stated efficiently in the second 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?

Despite having no output schema, the description does succinctly describe the principal return components. It is less complete on parameter semantics and on selecting among the many sibling tools, so an agent would still need to infer or probe several details before a fully informed call.

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 0%, so the description must compensate for the seven parameters. The only parameter-related detail is the batch limit ('até 100 consultas'), which sheds light on 'consultas' but not on pais, local, idioma, limite, pagina, or periodo. Most parameters remain unexplained by both schema and 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 states a specific verb ('Busca na web'), the resource (Google), and the concrete output (organic results with title, link, and snippet, plus direct answer and knowledge panel). It also differentiates from sibling tools by being the general web search among specialized verticals like academic, images, and news.

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

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

The description implies when to use it (any general web search), but it doesn't explicitly name alternatives or exclusion criteria such as 'use busca_google_academico for academic searches.' Sibling names provide context, but the description itself offers no direct routing 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 the tool read-only, idempotent, and non-destructive. The description adds meaningful conditional behavior about the response shape, including authenticated, pending[], and connect_url fields. It does not explain what 'pending' contains or partial-connection behavior, but annotations lower the bar.

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

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

Two sentences with no filler. The first sentence states the core purpose, and the second adds the key conditional outcomes. 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?

For a zero-parameter, read-only status tool, the description covers the main purpose, return values, and important conditional states. The only notable gap is the lack of detail about partial-connection states and the meaning of 'pending', but this is not a serious omission given the tool's simplicity and annotations.

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 zero parameters, so schema coverage is trivially 100%. The baseline of 4 applies, and the description does not need to add parameter-level detail.

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

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

The description clearly identifies the tool as a connection-status query returning URLs and authentication state. It is implicitly distinct from the sibling 'authenticate' tool, but it does not explicitly name the alternative, so it stops short of full sibling differentiation.

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

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

The description gives clear context for when the tool is useful: checking whether providers are connected and retrieving connect_url when credentials are missing. It does not explicitly state when to prefer a sibling tool, but the conditions are clear enough for a zero-parameter status endpoint.

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 bare flags (readOnlyHint=false, openWorldHint=true, idempotentHint=false), so burden falls on the description. It discloses key behavioral traits beyond flags: invoke runs tools even when not installed, one-off, without bloating toolkit, returns connect/checkout links, writes require owner/admin, and prompt links open without login. 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?

The description is long, but the tool's complexity (14 actions, 23 params, prompt library, billing, auth) justifies the density. It is organized into coherent blocks: core flow, KEY behavior, install vs invoke, list_tools/billing, writes, prompt library. It is front-loaded with purpose. A few asides like 'consulta um CPF' add color without harm but could be trimmed, keeping it just short of a 5.

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

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

For a tool with no output schema, bare annotations, and high action-dispatch complexity, this description is unusually complete: covers auth and payment edge cases, persistence semantics, permission requirements, and shareable prompt links. The gaps are the unexplained 'resume' action and a handful of secondary parameters, which prevents full completeness.

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

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

Schema coverage is 0% for 23 parameters, so the description must compensate. It does explain the central workflow parameters (action, query, mcp_id, tool_id, arggguments, prompt_*), but leaves several unexplained: the 'resume' action, 'immediate', 'limit', 'message', cancel_reason/cancel_c occasional mention. The description provides a high-level map of the main parameters but does not fully substitute for the missing schema descriptions.

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

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

The description opens with a crisp definition: 'The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It names a specific resource and scope, and clearly distinguishes itself from the concrete sibling search/utility tools (busca_google_*, authenticate, toolkit_info) by centering on the in-platform catalog and runtime. This is a model of purpose clarity for a multi-action tool.

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 gives selection criteria: 'Use install only to make an MCP PERMANENT... prefer invoke for a single/occasional use,' contrasts list_tools with describe, and explains the auth/paid flow (connect link vs checkout/top-up link then retry). It also sections off the prompt library actions and when to use report_bug/request_mcp. This is concrete, actionable guidance for choosing among many behaviors.

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 indicate a non-read-only, non-destructive, idempotent operation. The description adds the useful context that the conversation data is used for reproduction, but it does not disclose side effects, transmission details, or response behavior.

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 tight sentences with no filler. The main purpose is stated first, and the most important usage instruction (include the conversation array) 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?

Adequate for a simple feedback-reporting tool, but it lacks any mention of return behavior or what happens after submission, and it does not clarify the optional 'context' parameter. Since there is no output schema, the description itself must carry that burden.

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 0% schema description coverage, the description helps by explaining the 'conversation' parameter's purpose. However, it does not explain 'context' and only implies the role of 'message' through its name, so it only partially compensates for the missing schema descriptions.

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

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

The description uses a specific verb ('Report') and names the resources: bug, missing feature, or feedback. This scope is clearly distinct from siblings 'authenticate' and 'show_version'.

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 a clear use context ('Report a bug, missing feature, or send feedback') and gives concrete guidance to include the conversation array for reproduction. It does not explicitly state exclusions or alternatives, but the siblings are unrelated enough that this is a minor omission.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the 'current' qualifier, implying dynamic version retrieval, but it doesn't disclose output format or whether any external call is made. This is acceptable for a simple version query.

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

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

A single, focused sentence conveys the tool's purpose without redundancy. The key information, 'current MCP platform and adapter versions,' is front-loaded and every word is meaningful.

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

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

For a zero-parameter, read-only version-inspection tool, this description is fully sufficient. The annotations cover the behavioral safety aspects, and the description clearly states what information will be shown. No additional context is necessary.

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

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

The tool has zero parameters, so the schema already trivially covers everything. The description reinforces that no input is needed by describing a simple show operation. The baseline of 4 applies because there is no parameter complexity to explain.

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

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

The description uses a specific verb ('show') and resource ('current MCP platform and adapter versions'), clearly distinguishing it from sibling tools like authenticate and report_bug. Even without the title, an agent can tell exactly what this tool does.

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?

Although no explicit when/when-not guidance is provided, the fact that it reports current versions makes its usage context obvious. The sibling tools are unrelated (authentication, bug reporting), so there is no ambiguity about when to select this 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful detail about what state is reported, including connection statuses and account linkage, which goes beyond the annotations and helps the agent understand the informational nature of the 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?

A single well-structured sentence that leads with the core purpose and then lists the four key output components. There is no redundant wording or filler, and every phrase adds 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 carries the full burden of describing what the agent will receive. It enumerates all major return categories: installed MCPs, connection status, accounts, and catalog tool counts, which is sufficient for a zero-parameter informational tool.

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

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

The tool has zero parameters and the schema is complete with an empty object, so there are no parameter semantics to clarify. The description appropriately focuses on the output rather than inputs, matching the baseline for parameterless tools.

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

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

The description uses a specific verb ('Returns') and a concrete resource ('current toolkit state'), then enumerates exactly what is included: installed MCPs, connection status, connected accounts, and catalog tool counts. This clearly distinguishes it from sibling tools like authenticate, connect, or show_version.

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

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

The description implies this tool is for inspecting toolkit state, but it does not explicitly state when to prefer it over siblings or when not to use it. The intended usage is reasonably inferable from the content, but there is no direct guidance.

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