IndexAgent MCP

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that the tool returns complete institutional data in llms.txt form, but it does not add auth requirements, rate limits, or return-shape details beyond that.

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 with no wasted words. It states the action and return scope immediately.

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 low-complexity, single-parameter lookup with no output schema, the description sufficiently states what is returned: complete institutional data from llms.txt. It could be slightly fuller about what 'institutional data' includes, but the core need is covered.

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%, and the single 'company' parameter is fully documented in the schema with an enum of allowed slugs. The description only says 'de uma empresa' and does not add syntax, format, or validation meaning beyond the schema.

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

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

The description states a specific verb ('Retorna') and resource ('dados institucionais completos de uma empresa'), so the agent can tell this is a per-company institutional data lookup. It does not, however, explicitly distinguish itself from sibling tools like get_contact, get_faq, get_policies, or list_companies.

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?

Usage is only implied: retrieve a single company's institutional data when the company slug is known. There is no explicit when-to-use guidance, no exclusions, and no routing to alternatives such as list_companies or get_contact.

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 openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that — it doesn't say what contact fields come back (email, phone, address) or whether the result is stable/may be empty for some slugs.

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 front-loaded sentence with no filler or redundancy. It is efficiently structured, though it is also arguably under-specified rather than optimally 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 one-parameter read-only lookup with a fully documented schema and annotations, this is minimally adequate. With no output schema, the description could have clarified what 'contato' actually returns, which is the main remaining 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 100% with a single enum-constrained 'company' parameter, so the schema already documents it fully. The description's 'da empresa' merely echoes the parameter without adding format or selection guidance, matching the baseline 3 for schema-heavy definitions.

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

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

States a specific verb+resource ('Retorna o contato oficial da empresa'), which is distinct from siblings like get_faq or get_policies. However, it does not name or contrast with any sibling, so the differentiation is only inferable from the noun 'contato'.

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?

There is no guidance on when to call this tool versus get_company, get_faq, or get_policies. No prerequisites, exclusions, or alternative-routing information is provided; the agent must infer that this returns contact details rather than general company data.

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 openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of return shape, whether the FAQ list is long, or any filtering behavior. A description that merely restates the resource without extra behavioral context earns a low score here.

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?

One short, front-loaded sentence with no waste. It is efficient, though its brevity is partly why other dimensions are thin.

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, single-enum-parameter tool with no output schema, the description is minimally sufficient: annotations cover safety and the schema covers the parameter. It still omits what the FAQ response contains (structure, volume) and how it relates to sibling resources.

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 single company parameter has an enum with an explicit slug description, so the schema carries the meaning fully. The description adds no parameter detail of its own, which is the baseline 3 case.

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 a specific verb ("Retorna") and resource ("perguntas frequentes da empresa"), and the name confirms it. However it offers no differentiation from the sibling get_policies, which is a closely related resource an agent could easily confuse it with.

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?

There is no guidance on when to use this tool versus get_policies or get_company, and no prerequisites or exclusions are stated. The agent must infer usage purely from the name.

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 openWorldHint=false, so the safety and idempotency profile is fully covered by structured data. The description's only added context is which policy categories are returned; it says nothing about per-company availability, error behavior when a policy type is absent, or what the response contains.

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 short clause with the verb front-loaded and zero padding; nothing is redundant. It is arguably under-elaborated for an agent that needs to know the default and scope, but as structure and economy go it is close to ideal.

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, two-parameter retrieval tool with complete schema descriptions, safe annotations and no output schema, the description is nearly sufficient. The remaining gap is that it doesn't signal that results are scoped to one company or what happens when a requested policy type doesn't exist.

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% and both parameters are documented enums, so the schema carries the full burden. The description restates the four policy types but omits the 'todas' default value and the company slug option, adding essentially nothing beyond the schema — the 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 gives a specific verb ('Retorna') and resource ('políticas') and enumerates the policy domains (troca, entrega, pagamento, garantia), so an agent immediately knows what it retrieves. It does not explicitly distinguish itself from siblings like get_faq, but the sibling set covers unrelated resources, so differentiation is largely 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?

Usage is only implied: the enumerated policy types suggest the tool is for customer-facing policy questions, but there is no explicit 'use this when...' statement or mention of an alternative (e.g., get_faq for general questions). Nothing is misleading, but nothing guides selection either.

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 openWorldHint=false, so the safety profile is fully covered without the description. The description adds nothing further — no error behavior for an unknown slug, no note on inactive/unpublished products — so it contributes almost no behavioral context beyond the structured fields.

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

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

A single efficient sentence with the resource and key front-loaded and zero filler. It is well-sized, though it is so terse that it conveys no supporting 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?

The tool is simple (2 required params, 100% schema coverage, annotations present, no output schema), so little prose is strictly required. However, the description omits what happens on a miss and does not clarify its relationship to search_products/list_products, leaving it merely 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%, with both parameters documented (the company enum values are even listed inline), so the schema carries the semantics. The description only restates the slug lookup and adds no format or constraint detail beyond the schema, making 3 the correct 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?

States a specific verb and resource ('Retorna um produto específico') plus the lookup key ('pelo slug'), which distinguishes it from the list_products/search_products siblings by implying single-item retrieval. It never names a sibling explicitly, so it stops short of a 5.

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?

There is no when-to-use guidance and no mention of alternatives such as search_products or list_products. The phrase 'pelo slug' only weakly implies the precondition that the caller already knows the slug.

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 openWorldHint=false, so the safety profile is covered. The description adds that the return is a hierarchical tree with per-category product counts, which is genuinely useful shape information, but says nothing about depth, ordering, or empty categories.

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 compact sentence that front-loads the resource and appends the most distinctive detail (product counts). No filler, though it is terse enough to leave gaps.

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

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

For a one-parameter read-only tool with full schema coverage and annotations covering safety, the description supplies the key extra fact (tree structure with counts) that the schema cannot express. No output schema exists, and the description does at least sketch the return shape, so nothing critical is missing.

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

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

Schema description coverage is 100% with the enum slugs documented in the schema, so the single 'company' parameter is fully specified there. The description adds nothing beyond that, which is the correct baseline for high 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?

States a specific verb+resource ('Retorna a árvore de categorias') plus the payload detail 'com contagem de produtos', which clearly distinguishes it from siblings like list_products or get_product. It stops short of naming an alternative, but the purpose is unambiguous.

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

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

No indication of when to prefer this over list_products or search_products, nor any note that the result is scoped to the required 'company' parameter. Usage is only weakly implied by the tool name.

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 openWorldHint=false, so safety is covered. The description adds one useful behavioral fact — only published companies are returned — but says nothing about ordering, pagination or result size for what is implicitly a catalog listing.

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 front-loaded sentence with zero filler. Nothing could be trimmed without losing the scope qualifier 'publicadas'.

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 no-arg read tool this is nearly sufficient, but with no output schema the description could have indicated what comes back (a list of company records, and whether it is paginated or complete). That return-shape gap is the only meaningful omission.

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 takes zero parameters, so there is nothing for the description to clarify; baseline 4 applies. The schema's additionalProperties=false also leaves no ambiguity for the agent.

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 a specific verb (lista) and resource (empresas), scoped to those 'publicadas no diretório IndexAgent'. It is distinguishable from get_company (singular retrieval), but the description never names that sibling to make the contrast explicit.

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?

No when-to-use guidance and no mention of the alternative get_company for fetching a single company. The agent must infer the routing decision from the names alone.

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 openWorldHint=false, so the safety profile is covered. The description adds only the pagination behavior, which the schema also documents, and says nothing about what is returned or how many products a company can have.

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?

One front-loaded sentence with no filler; the scope and pagination constraint are stated up front.

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?

A simple read-only list tool with full param coverage and safety annotations, so little is strictly missing. However, with no output schema, the description could have said what a product entry contains or signaled empty-result behavior, which it does not.

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% and each parameter is documented in-schema (company slug enum, limit max 100, offset). The description adds no meaning beyond that, so the 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?

States a specific verb+resource+scope: 'Lista produtos de uma empresa com paginação'. This distinguishes it from the singular get_product and from search_products, though it never names those siblings explicitly.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as search_products or get_product. Usage is only implied by the tool name and verb.

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 openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that—no note on result limits, pagination, or why the 'teste_gratis' tag matters—so it delivers no behavioral value beyond the structured fields.

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

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

A single front-loaded sentence with zero filler and no repetition—the filter list is the essential content. It is appropriately sized, though its brevity is part of the reason other dimensions are thin.

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 would be the natural place to say what a result looks like or how the default limit of 20 behaves under pagination, and it says neither. With full schema coverage on inputs and read-only annotations, a 3 is the minimum viable level 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 description coverage is 100%, so every parameter is already documented in the schema. The description only restates the filter categories (texto, categoria, tags, preço, estoque) mapping loosely onto query/category/tags/min_price/max_price/in_stock_only, adding no syntax or semantic detail beyond 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?

States a specific verb (busca) and resource (produtos) plus the dimensions it can filter on, which separates it from get_product (single fetch) and list_products (unfiltered listing). However, it never names those siblings explicitly, so the agent must infer the boundary itself.

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

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

The phrase 'filtros combinados' implies this is the tool for refined lookups versus enumeration, and the required 'company' scope is visible in the schema, but there is no explicit when-to-use/when-not guidance or pointer to list_products/get_product as alternatives.

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