Music360 MCP

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context about tenant scoping and the requirement to use public_uid instead of internal numeric ID. However, it does not mention potential pitfalls like not-found behavior, auth requirements, or response formats, which would be expected for a fully transparent description.

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 sentence, directly front-loaded with the verb and resource, and contains zero filler. It is concise and to the point.

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 get tool with a fully described input schema and an output schema present, the description covers the essential context: the specific entity type, tenant scope, and key ID requirement. While it doesn't elaborate on all edge cases, the structured schema compensates, making it sufficiently 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%, and the schema already carries detailed descriptions for all four parameters. The description's emphasis on 'somente public_uid' is redundant with the schema's id description. No additional parameter semantics are provided 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 clearly states the verb 'Consulta' (queries) and the resource 'registro de artista' (artist record), and adds a specific constraint 'usando somente public_uid' (using only public_uid). This distinguishes it from sibling get_ tools for other entity types.

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 usage when the caller has a public_uid and needs a single artist from the current tenant. It does not explicitly name alternatives or exclusions, but the constraint 'somente public_uid' and tenant scope provide clear context for when to use 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?

With no annotations provided, the description carries the full burden. It does disclose an important constraint: only public_uid may be used, not the internal numeric ID. However, it does not mention authorization requirements for sensitive details, error behavior, or other side effects, which are relevant given the sensitive parameters in the 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?

The description is a single, clear sentence that is front-loaded with the verb 'Consulta'. It contains no filler and effectively communicates the core purpose without unnecessary 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 description captures the essential use case and scope. The output schema and parameter descriptions cover return values and optional parameters, so the description is adequately complemented by structured data. It could mention the sensitive options, but the schema already explains them.

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 all parameters are already well-documented. The description adds no new semantic detail about parameters; it merely reinforces the id requirement ('somente public_uid'), which is already in the schema.

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

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

The description clearly states the action: 'Consulta um registro de contato do tenant atual' (queries a single contact record of the current tenant) with the specific identifier 'usando somente public_uid'. This distinguishes it from sibling 'get' tools (different entities) and 'list_contato' (singular vs. list).

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 context for use: to fetch a single contact record by public_uid within the current tenant. It implies this tool is for singular lookups, but it does not explicitly mention alternatives or exclusion criteria (e.g., 'use list_contato for multiple records').

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does convey that the operation is a read-only lookup ('Consulta') scoped to the current tenant, and it emphasizes using the public_uid rather than an internal ID. However, it does not address sensitive data behaviors, response profiles, or potential authorization requirements, which are relevant given the schema's sensitive parameters.

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 directly states the action, resource, and key identifier. It contains no fluff and every phrase contributes meaning. This is a model of concise structure.

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 provides the core purpose but lacks broader context. It does not explain when to use this tool versus list/search, nor does it outline the behavior of response_profile or sensitive data access, even though these are present in the schema. For a simple get-by-ID tool with a rich schema, the description is minimally viable but leaves gaps in usage guidance and sensitive-data handling.

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

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

The input schema has 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds no new meaning beyond the schema, except reinforcing that 'id' is the public_uid. Since the schema already explains each parameter clearly, 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 queries a contract record ('registro de contrato') for the current tenant, using the public_uid. This specific verb and resource distinguish it from sibling get tools for other entities, and the mention of 'somente public_uid' clarifies the lookup key. It is unambiguous and immediately understandable.

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 guidance is provided on when to use this tool versus alternatives like list_contrato or search. The description only explains what the tool does, not the appropriate context or scenarios. For example, it does not mention that this is for fetching a single record by ID, while list is for enumeration and search for more complex 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, placing the burden on the description. The verb 'consulta' indicates a read operation, and 'tenant atual' provides scoping context. However, it does not disclose details such as permission requirements for sensitive profiles or behavior when the record is not found, relying instead on schema descriptions.

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, succinct sentence that front-loads the action and resource. There is no wasted wording or redundant information, making it 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 straightforward get-by-id tool with an output schema, the description covers the core purpose and scoping. It lacks mention of optional sensitive-data parameters, but these are fully documented in the input schema, so the description remains sufficiently 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 description coverage is 100%, so the baseline is 3. The description adds no new parameter semantics beyond what is already in the schema; it merely restates the constraint about using public_uid, which the 'id' parameter description already covers.

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 ('Consulta' - queries), identifies the resource ('registro de fonograma'), and scopes it ('do tenant atual'). It clearly distinguishes from sibling tools like list_fonograma and search by emphasizing the use of only public_uid for a single record lookup.

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 usage context: use this when you have a public_uid and need a single record from the current tenant. However, it does not explicitly mention alternatives or when-not-to-use scenarios, such as needing to list multiple records or search by other 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 the description bears the full burden of behavioral disclosure. It only describes the basic query action and does not mention behaviors like sensitive data handling, admin authorization requirements, error conditions, or rate limits. The schema parameter descriptions mention 'sensitive exige admin', but the description itself does not disclose these traits.

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 sentence that is front-loaded with the core purpose and contains no extraneous information. It is appropriately concise for a simple get tool.

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

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

The tool has an output schema and complete parameter descriptions, lessening the need for the description to explain return values or parameter details. However, the description lacks context around sensitive data access and admin scoping, which are relevant given the 'sensitive' response profile. It also does not relate to sibling tools, leaving the agent to infer placement. Overall, it is minimally adequate but not rich.

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 describes all parameters (100% coverage), including the id field as 'public_uid do registro' and the sensitive-related parameters. The description's mention of 'usando somente public_uid' simply reinforces the schema's id description without adding new meaning. The description adds no significant semantic value beyond the schema, 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?

The description clearly states the tool's purpose: 'Consulta um registro de obra do tenant atual usando somente public_uid.' It uses a specific verb (consulta), identifies the resource (registro de obra), scopes it to the current tenant, and highlights the key parameter (public_uid). This distinguishes it from sibling tools like music360_list_obra (listing) and other get_* tools targeting different entities.

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 usage for fetching a single record by public_uid, but it does not explicitly name alternatives or state when not to use this tool (e.g., when needing a list or having a numeric ID). The phrase 'usando somente public_uid' gives a hint, but there is no explicit comparison with alternatives like music360_list_obra.

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?

Não há anotações, então a descrição deveria ser mais transparente. Ela apenas afirma que é uma consulta, sem detalhar efeitos colaterais, requisitos de permissão, tratamento de erros ou comportamento com dados sensíveis. Falta contexto sobre o que acontece quando o public_uid não existe ou quando perfis sensíveis são solicitados.

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?

Frase única, direta e sem ruído, transmitindo o propósito essencial de forma eficiente. Estrutura ideal para uma ferramenta simples.

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 descrição cobre o caso básico, mas não aborda as opções sensíveis (response_profile=sensitive, include_sensitive_details) nem o fluxo de acesso administrativo, que ficam subentendidos no schema. A presença de output schema reduz a necessidade de detalhar retornos, mas a parte de autorização sensível poderia ser antecipada na descrição.

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?

O schema já cobre 100% dos parâmetros com descrições detalhadas, então a barra de valor é baixa. A descrição reforça o uso exclusivo do public_uid, mas não acrescenta significado além do que o schema já fornece.

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 identifica claramente a ação (consultar), o recurso (notícia/press release) e o identificador (public_uid). Isso a distingue do sibling music360_list_press_release, que é para listagem, tornando o propósito inequívoco.

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 não oferece orientação explícita sobre quando usar este tool em vez de alternativas como list_press_release, nem menciona cenários em que não deve ser usado. A menção de 'usando somente public_uid' dá uma pista, mas sem contexto de 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?

No annotations are provided, so the description carries the burden. 'Consulta' indicates a read-only operation, which is helpful, but the description does not disclose authorization requirements for sensitive profiles, error behavior, or any other side effects beyond the basic read intent.

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, well-structured sentence that starts with the verb and resource, including the key distinguishing detail (public_uid) without any unnecessary words.

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

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

For a simple single-record lookup, the description combined with the complete input schema and presence of an output schema is sufficient. It does not explicitly cover sensitive-access workflows, but those are fully described in the parameter properties.

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 already documents all parameters with 100% coverage. The description adds a slight constraint with 'usando somente public_uid' and tenant scoping, but these are largely echoed in the schema descriptions. There is no substantial added meaning.

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 is specific: it names the verb 'Consulta', the resource 'registro de produto fonográfico', the tenant scoping, and the retrieval method 'usando somente public_uid'. This clearly distinguishes it from the list sibling (music360_list_produto_fonografico) and from other entity-specific get_* 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?

The description clearly implies single-record retrieval by public_uid, which contrasts with list alternatives. However, it does not explicitly mention when not to use the tool or name alternative tools, so it stops short of full guidance.

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

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

With no annotations, the description carries the transparency burden. It discloses two important behavioral constraints: tenant scoping (do tenant atual) and the exclusive use of public_uid (not internal numeric IDs). These go beyond a generic 'get show' and help the agent avoid common mistakes.

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?

Single sentence, front-loaded with the main action, and zero filler. Every word adds value—verb, resource, scope, and access method are all packed efficiently.

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, the presence of an output schema, and full parameter descriptions, the description is almost complete. It lacks explicit guidance on when to use response_profile or sensitive details, but those are documented in the schema, so the gap is minor.

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% parameter descriptions, so the baseline is 3. The description reinforces that 'id' must be a public_uid, but this adds no new meaning beyond the schema's existing description for that parameter.

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

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

The description uses a specific verb (Consulta) and resource (registro de show), and scopes it to the current tenant. It clearly distinguishes from sibling list tools and other get_* tools by specifying the unique access method (somente public_uid).

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

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

It provides clear context for usage: retrieving a single show record using the public_uid. It implicitly excludes list operations and other get tools, but does not explicitly name alternatives or state when-not-to-use conditions.

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 discloses that the lookup uses only public_uid and is scoped to the current tenant, but it does not explicitly state read-only behavior, auth requirements, or potential error semantics. The verb 'consulta' implies read-only, but more disclosure would be safer.

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 that front-loads the verb and resource. No wasted words, and it directly addresses the core operation.

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, combined with a complete input schema and existing output schema, is sufficient for a straightforward get-by-id tool. It lacks some usage guidance, but the essential context of scope and identifier is present.

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 all parameters described. The description adds no new meaning beyond reinforcing the 'public_uid' requirement for the id parameter. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the verb (consulta), the resource (registro de tarefa), the scope (tenant atual), and the required key (public_uid). It effectively distinguishes this get operation from list/search siblings and other entity-specific get 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?

The description provides clear context: use this when needing a single task record and possessing its public_uid. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous enough for an agent to infer when to select 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?

With no annotations, the description carries the full burden for behavioral disclosure. It only mentions the query act and tenant/uid scoping, but doesn't disclose that sensitive details require admin authorization, the meaning of response profiles, or any potential side effects. The schema descriptions cover some of this, but the description itself lacks 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 a single, front-loaded sentence that immediately communicates the tool's purpose and key constraint. It is efficient with no redundant words, fully earning 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?

The description is adequate for a simple read operation, especially with a complete schema and output schema. However, it omits high-level context about sensitive access controls and when to prefer this over search/list tools. Given the tool's moderate complexity (sensitive params), the description could be more complete, though the schema compensates.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only reiterates the public_uid requirement already present in the schema, adding no new semantic information about the four parameters. It doesn't compensate for anything the schema already documents.

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

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

The description clearly states the verb 'consulta' and the resource 'registro de videograma', scoped to the current tenant and specifically by public_uid. This fully distinguishes it from sibling get_* tools for other entity types and from list_videograma, which would be used for multiple records.

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 context: use this to fetch a single videogram record using only public_uid. It implies the alternative (list_videograma for multiple records) via the sibling naming, though it doesn't explicitly name it. The 'somente public_uid' also gives a key usage constraint, but no explicit exclusions or alternative mentions.

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 only notes the return type and the absence of internal IDs, but does not disclose whether the operation is read-only, what authentication is required, or any other behavioral characteristics. For a healthcheck tool this is minimal information.

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

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

The description is a single, concise sentence that delivers the core message without any filler. It is appropriately front-loaded with the verb and resource.

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 (no parameters, likely simple healthcheck), the description is mostly adequate. It mentions tenant context and output emphasis, but could benefit from noting that this is a read-only monitoring tool. However, the presence of an output schema reduces the need to explain return values.

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 empty, so the baseline is 4. The description adds no parameter details, but none are needed; the schema already communicates the lack of parameters.

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

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

The description clearly states the tool's purpose: 'Retorna status operacional resumido do conector MCP' (Returns summarized operational status of the MCP connector). It specifies the verb (returns), the resource (MCP connector), and scope (authenticated tenant), and it is easily distinguished from sibling get/list/search 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?

No explicit when-to-use or alternative references are provided, but the healthcheck purpose is implied by the name and description. It gives no exclusions or prerequisites, so usage context is only inferred.

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 of behavioral disclosure. It only says 'lists artist records' and omits important traits like pagination, filtering, ordering, response profiles, or sensitive data handling. This is a significant gap for a listing 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?

The description is a single, focused sentence with no redundancy. It is appropriately concise, though it could have included more context without becoming verbose. The front-loaded verb and resource make it immediately 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?

With 8 parameters, several of which control pagination, ordering, and sensitive data access, the one-line description is far from complete. It does not explain the tool's capabilities or how the parameters relate to its behavior. Even with an output schema, the description fails to provide sufficient context for effective use.

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 63%, above the 50% threshold, so baseline is 3. The description adds no parameter information beyond the schema, but the schema itself documents several parameters (order_by, response_profile, sensitive_access_purpose). The description does not compensate for the undocumented page, search, and per_page parameters.

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

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

The description clearly states the tool lists artist records for the current tenant, using a specific verb ('Lista') and resource ('registros de artista'). It distinguishes from sibling get_artist and other list_* tools by identifying the entity type.

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 no guidance on when to use this tool versus alternatives, such as get_artist for single records or other list tools. There is no mention of exclusions or preferred scenarios.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions scopes and role, which hints at authorization, but fails to disclose that sensitive outputs may require admin privileges (as evidenced by the response_profile and include_sensitive_details parameters) or that a purpose is mandatory for sensitive access. The description also doesn't explicitly state whether this is a read-only operation or return format.

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, clear, front-loaded sentence. Every word contributes to meaning. It is appropriately sized for the tool's simplicity and contains 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?

The tool has an output schema and the description gives the core purpose, but the description is minimal for a security-sensitive introspection tool. It does not mention the sensitive response profiles, admin requirements, or the fact that a purpose field is required for sensitive access. While the schema covers the parameters, the description should provide more behavioral context for an agent to understand when admin approval is needed or how to handle sensitive responses. Overall, adequate for a simple listing operation but lacking depth given no 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?

Schema description coverage is 100% and all three parameters are already documented with their enums and defaults. The description adds no additional semantic value about the parameters. Baseline 3 is appropriate because the schema fully describes the parameter semantics.

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 ('Lista' - lists) and clearly identifies the resource ('ferramentas MCP habilitadas' - enabled MCP tools) and scope ('usuário autenticado conforme escopos e papel' - per authenticated user's scopes/role). This clearly distinguishes it from sibling data-list tools like music360_list_artist or music360_list_obra, which all list specific entity types.

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 no explicit guidance on when to use this tool or any alternatives. It does not mention exploring capabilities at session start, nor does it state that it is for introspection only. The purpose is implied but not stated as a direct use case, and there are no exclusions or alternative tool references.

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 disclose behavior. It only states the listing purpose and the expected use of the 'value' field; it does not mention response shape, filtering behavior, authorization requirements, or side effects, leaving the agent to rely on the output 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?

The description is two short sentences in Portuguese, front-loading the core purpose and then providing a concrete usage instruction. Zero 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 has no required parameters, an output schema exists, and the description connects directly to a create counterpart, the information is adequate for selection and invocation. It could benefit from noting whether classifications are language-dependent or paginated, but the output schema likely covers return 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?

Schema description coverage is 100% with each parameter (response_profile, sensitive_access_purpose, include_sensitive_details) having its own description and enum values. The tool description adds no extra parameter context, so it meets the baseline for schema-provided semantics.

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

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

The description clearly states the tool lists valid classifications for creating phonograms ('Lista classificações válidas para criar fonogramas') and specifies the output field usage. This distinguishes it from sibling tools like list_fonograma or list_generos_fonograma.

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

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

The description explicitly instructs the agent to use the returned 'value' field in music360_create_fonograma.classificacao, indicating the tool should be invoked before creating a phonogram. It does not mention alternatives or exclusion scenarios, but the context is sufficient.

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

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

With no annotations, the description carries the full burden but only states the basic listing scope. It discloses nothing about pagination, sorting, or sensitive data handling. The lack of any warning or detail about behavior beyond the mere action leaves agents uninformed.

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 concise sentence with no wasted words. However, it is under-specified for the tool's complexity, so while concise, it may be too sparse.

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 8 parameters, no annotations, and only an output schema indicator, the one-sentence description is insufficient. It does not cover pagination, filtering, ordering options, or the sensitive access profile, leaving the agent without enough context for correct invocation.

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

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

Schema description coverage is 63%, with 5 of 8 parameters described in the schema. The tool description adds no parameter semantics of its own, and common parameters like page, search, and per_page remain undocumented. Moderate coverage warrants a mid-range 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?

The description 'Lista registros de contato do tenant atual' clearly states a specific action (list) and resource (contato records) with scope (current tenant). It distinguishes from siblings by naming the resource, though it does not explicitly contrast with get_contato or other list 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?

No guidance is provided on when to use this tool versus alternatives like music360_get_contato or search. There are no exclusions, prerequisites, or context about list-specific use cases.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the tenant scope. It does not mention read-only behavior, pagination defaults, sensitive data handling, or permission requirements. The schema includes response_profile and sensitive_details parameters, but the description does not explain their operational implications.

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, direct sentence in Portuguese that front-loads the verb and object, with zero filler. It is appropriately sized for a simple list operation, even though completeness is lacking elsewhere.

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 8 optional parameters, sensitive data profiles, and no annotations, a one-sentence description is insufficient. It does not explain pagination defaults, search behavior, or how the response_profile affects the output. While an output schema exists, it cannot compensate for missing usage context and operational behavior.

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 63%, and many parameters have inline descriptions (e.g., order_by, response_profile). The description adds no parameter semantics beyond the schema; parameters like page, search, and per_page rely on conventional meaning. Since coverage is moderate and the description does not hinder understanding, 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 'Lista registros de contrato do tenant atual' clearly states the verb (lists), resource (contract records), and scope (current tenant), unambiguously distinguishing it from sibling tools like music360_get_contrato (single record) and music360_list_contrato_partes (contract parts). No ambiguity exists.

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 no guidance on when to use this tool versus alternatives such as search or get_contrato. It does not state prerequisites, exclusions, or scenarios where a different listing tool would be more appropriate. The existence of sibling tools implies a decision, but the description does not address 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?

No annotations are provided, so the description carries the burden. It does not disclose behavioral traits such as read-only nature, permissions, or handling of sensitive data. The phrase 'usando somente public_uid' is about input, not 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?

The description is a single, front-loaded sentence that is concise and to the point, 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 the simple listing nature and presence of a complete output schema, the description sufficiently covers the main purpose. It could mention sensitive profiles, but those are already documented in the 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 description coverage is 100%, so baseline is 3. The description's reference to 'public_uid' merely echoes the schema's description for contrato_id without adding extra semantics.

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

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

The description clearly states the tool lists the parties (contracted/contracting/intervening) linked to a contract using public_uid. It is specific about the resource and verb, and distinguishes from sibling tools like list_contrato and get_contrato.

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 usage when needing contract parties but does not explicitly provide alternatives or when-not-to-use cases. It mentions 'somente public_uid' but lacks direct comparison with sibling list/get 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?

With no annotations, the description must carry the full burden of behavioral disclosure. It only states the listing scope ('tenant atual') and omits important behavioral details such as pagination behavior, default ordering, sensitive response handling, or read-only guarantees. The verb 'Lista' implies a read operation but does not explicitly disclose side effects or defaults.

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 filler. It efficiently conveys the action, object, and scope.

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?

An output schema exists and covers return values, but for a list tool with 8 parameters and sensitive-data options, the description is minimal. It provides core purpose and tenant scope but lacks operational context like pagination defaults, sensitive access, and relationships to sibling tools. It is adequate but has 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?

The schema covers 63% of parameters, but the description adds no parameter-level meaning. Undocumented parameters like page, search, and per_page are not explained, and the description does not compensate for the coverage gap.

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

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

The description uses the specific verb 'Lista' and identifies the resource 'registros de fonograma' with the explicit scope 'tenant atual'. This clearly differentiates it from get_fonograma (single record) and other list_* siblings by entity.

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 use case is implied: use this tool to list phonogram records. However, there is no explicit guidance on when to prefer this over related tools like search or get_fonograma, nor any exclusion criteria. The context is clear but alternatives are not mentioned.

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

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

With no annotations, the description carries the burden of disclosing behavioral traits. It only states that it uses public_uid, which is a parameter detail rather than an explanation of behavior such as permissions, sensitivity, or return format. The presence of sensitive parameters in the schema is not acknowledged, leaving the agent unaware of potential admin restrictions 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?

The description is a single, front-loaded sentence that immediately communicates the operation and its scope. No filler or redundant content; it earns its place efficiently.

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 is incomplete for a tool with 4 parameters including sensitive-access options. It does not mention the response_profile modes, sensitive_access_purpose, or include_sensitive_details, nor does it clarify the behavior around admin authorization. The output schema covers return values, but the context for using these optional parameters is missing, reducing the tool's usability.

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 already describes all parameters with 100% coverage, including enum and descriptions. The description adds slight semantic value by clarifying that 'titulares' encompasses 'intérpretes/músicos/produtores,' which aids in understanding the intended domain but does not add new parameter-level detail. Baseline 3 is appropriate.

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

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

The description clearly states the tool lists 'titulares' (interpreters, musicians, producers) linked to a fonograma, using a specific verb ('Lista') and resource ('titulares vinculados a um fonograma'). It also distinguishes from siblings like music360_list_fonograma and music360_list_obra_titulares by specifying the relation to a fonograma and the use of 'public_uid'.

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 implied through the name and description—it lists titulares of a fonograma—but there is no explicit guidance on when to choose this over alternatives like music360_list_obra_titulares, or any exclusions. The mention of 'usando somente public_uid' gives a partial hint about the required identifier but lacks broader selection 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?

With no annotations, the description carries the full burden. It discloses the read-only listing behavior and purpose, but doesn't elaborate on sensitive data handling, response size, or potential admin requirements. The schema hints at sensitive parameters, but the description stays silent, leaving a moderate 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 two short, front-loaded sentences: the first states the core purpose, and the second gives a cross-tool usage hint. Every word earns its place with zero 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 simple reference list with no required parameters and an output schema, the description is nearly complete. It explains the purpose and how to use the result with another tool. However, it omits any mention of response_profile or sensitive access parameters, though these are covered by the 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 description coverage is 100%, so the baseline is 3. The description adds no information about the parameters themselves, merely referencing the output 'value' field, which is not a parameter. Thus it doesn't exceed the schema's already thorough 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 'Lista gêneros válidos para criar fonogramas' with a specific verb and resource. It distinguishes itself from sibling list tools by focusing on phonogram genres and their use in creating fonogramas.

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 explicitly tells the agent to 'Use o campo value em music360_create_fonograma.genero', providing a concrete usage instruction for when to use the tool. While it doesn't mention explicit alternatives, the guidance is clear and actionable.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, yet it only says 'lists records'. It fails to mention pagination, search/filter behavior, sensitive-data handling, or permission requirements.

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 clear sentence with no filler, and it is appropriately front-loaded. It is concise but comes at the expense of necessary detail for a tool with 8 parameters.

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 is incomplete relative to the tool's complexity. It does not explain the tenant-scoping context, response profiles, sensitive access, or how this list relates to the broader API. An output schema exists but does not cover these contextual requirements.

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 description adds no parameter semantics beyond the schema. While the schema covers 63% of parameters, the description does not compensate for the remaining gaps (e.g., page, per_page, search semantics) as required when coverage is below 80%.

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

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

The description clearly states the tool lists 'obra' records for the current tenant (verb+resource+scope). It is unambiguous and aligns with the tool name, but it does not differentiate from sibling tools like music360_list_obra_titulares or music360_get_obra.

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 no guidance on when to use this tool versus alternatives (e.g., when to use list_obra vs get_obra, or how to handle sensitive profiles). There is no mention of prerequisites or exclusions.

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

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It discloses the important constraint that only public_uid is accepted (not internal IDs), which is non-obvious. However, it does not mention that the operation is read-only or that sensitive response profiles require admin access, though these details are present in the schema. Thus, it provides moderate transparency but not comprehensive coverage.

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, concise sentence that is front-loaded with the primary purpose. It contains no filler and every word adds value. It is appropriately sized for the tool's simplicity.

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 and the description, combined with the comprehensive schema and existing output schema, covers all essential information for correct usage. The description could be enhanced with a note about response profiles or explicit differentiation from similar list tools, but these are not critical gaps. It is nearly complete for the agent's needs.

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, with all four parameters well-documented. The description adds no additional meaning beyond emphasizing the public_uid-only constraint, which is already stated in the schema's obra_id description. Since the schema does the heavy lifting, a 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's function: listing titulares (composers/authors/editors) associated with an obra. It uses a specific verb ('Lista') and a specific resource ('titulares... vinculados a uma obra'), which distinguishes it from sibling tools like list_obra (which lists obras) and list_fonograma_titulares (which lists titulares for fonogramas).

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 context for when to use the tool: when you need titulares of a specific obra. It also highlights a key usage constraint ('usando somente public_uid'), which is a practical guideline. However, it does not explicitly mention alternative tools or scenarios where this tool should not be used, 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the tenant scope and does not explain pagination behavior, response profile options, sensitive data handling, or authorization requirements. The sensitive parameters in the schema (e.g., response_profile, sensitive_access_purpose) are not mentioned in the description, leaving significant behavioral traits undisclosed.

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 efficient sentence that front-loads the verb and resource. It is concise with no wasted words, though it is arguably too brief to cover all necessary context. Still, it earns a high score for being compact and well-structured.

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 6 parameters, an output schema, and sensitive response options, the one-line description is incomplete. It omits guidance on pagination, search, response profiles, and sensitive access. While an output schema exists and return values need not be described, the description still fails to cover essential usage context for this complex 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 description coverage is 50%, meaning page, search, and per_page lack descriptions. The description adds no parameter information whatsoever, failing to compensate for the undocumented parameters. The common pagination and search parameters are left to inference, which is insufficient for a tool with 6 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 uses the specific verb 'Lista' (lists) and clearly identifies the resource as 'notícias/press releases', scoped to 'do tenant atual' (current tenant). This distinguishes it from sibling tools like music360_get_press_release (singular) and other music360_list_* tools, making the purpose unmistakable.

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

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

The description implies usage for listing press releases of the current tenant, but provides no explicit guidance on when to use this tool versus alternatives such as music360_search or music360_get_press_release. There are no exclusions or contextual hints beyond the basic scope, so the guidance is only 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the default filtering behavior (only released items) and the effect of release_scope=all, which is valuable. However, it does not mention pagination behavior, response profile defaults, or sensitive data handling, which are relevant for a list tool with many parameters.

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 that front-load the main purpose, then provide usage context and a critical default behavior. Every sentence earns its place, with no redundant or vague wording.

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

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

Given the tool's complexity (10 parameters, output schema present, no nested objects), the description provides sufficient context for correct invocation: it explains the core use case, tenant scope, and the most important parameter (release_scope). While it does not mention response profiles or sensitive data, the schema covers those details, so the description is adequately complete for selection and basic 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 70%, so the baseline is 3. The description adds meaning to key parameters by explaining that 'lançamento' refers to data_lancamento and clarifying the default behavior of release_scope. This goes beyond the schema's own descriptions and helps the agent understand the primary filtering semantics.

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 ('Lista') and resource ('registros de produto fonográfico') with a clear scope ('tenant atual'). It distinguishes itself from siblings by specifying the domain (álbuns, singles, EPs) and usage context, making it distinct from other list tools and the corresponding get_produto_fonografico 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 states when to use the tool ('Use esta tool para álbuns, singles, EPs e pedidos sobre lançamento musical mais recente') and provides guidance on the default release_scope behavior. It does not explicitly mention when not to use it or name alternative tools as exclusions, but the intended context is clear.

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 of behavioral disclosure. It only states the listing action and the use of public_uid; it does not disclose whether the operation is read-only, any authentication requirements beyond the UID, rate limits, or effects. This is a significant transparency gap for a tool with no annotation support.

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, focused sentence in Portuguese, front-loaded with the action and resource, with no redundant or filler content. It is appropriately sized for the tool's simple purpose.

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

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

Given that an output schema exists and all parameters are documented in the input schema, the description is sufficient for a straightforward list operation. It could have added a note about the sensitive parameters, but the schema already handles that. The description adequately covers the core purpose and key 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?

The schema covers 100% of the parameters with descriptions, so the baseline is 3. The description adds minimal clarification ('usando somente public_uid') which aligns with the schema's 'public_uid do produto fonográfico' but does not elaborate on the other three parameters, all of which are already well-documented in the schema.

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

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

The description clearly states the tool's function: 'Lista as faixas (tracklist) de um produto fonográfico' – a specific verb (list) and resource (tracklist of a phonographic product). It also notes the key input (public_uid), distinguishing it from related list tools like music360_list_produto_fonografico.

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 implied: the tool lists tracks for a phonographic product using public_uid. However, there is no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisite context beyond the parameter description.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only mentions tenant scoping but omits critical behaviors like pagination, default ordering, response profiles, sensitive data handling, and authentication requirements. The schema implies these behaviors but the description does not explain them.

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

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

The description is a single, concise sentence with no fluff, but it is under-specified. While front-loaded and brief, it sacrifices necessary detail, making it not 'appropriately sized' for a tool with this complexity.

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 has 8 parameters, no annotations, and a complex schema (response profiles, sensitive handling), a one-sentence description is grossly incomplete. It does not explain return behavior, defaults, sensitive access requirements, or relationship to other list tools. The output schema exists but is not described in the text.

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

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

The description adds no parameter information beyond the schema. Schema description coverage is 63%, meaning several parameters (page, search, per_page) lack schema descriptions, and the description does not compensate for this gap. The self-explanatory names partially mitigate the issue, but the description itself provides zero value for parameter understanding.

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 action ('Lista registros de show') and scope ('do tenant atual'), identifying it as a list operation for shows within the current tenant. However, it does not explicitly distinguish it from the related get_show tool, though the verb 'list' conveys multiplicity.

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 guidance is provided on when to use this tool versus alternatives, such as get_show for a single show, or how to combine it with other list tools. There is no mention of pagination, filtering, or other usage context.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Lista' (lists) but does not state whether the operation is read-only, whether it supports pagination, or the implications of parameters like response_profile or include_sensitive_details. No behavioral traits beyond the basic action are disclosed.

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, direct sentence with no extraneous content, placing the key information (lists task records, tenant scope) upfront. It is appropriately sized for the minimal information it conveys.

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 8 parameters and no annotations, the description provides only the basic action and entity scope. It omits critical context about pagination, default ordering, sensitive data handling, and differences from related list/get tools, making it insufficient for an agent to fully understand the tool's behavior.

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 63% of parameters with descriptions, leaving page, search, and per_page unexplained. The description itself adds no parameter-level information, so it neither leverages existing descriptions nor compensates for the gaps.

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 'Lista registros de tarefa do tenant atual' (Lists task records from the current tenant), using the specific verb 'Lista' and resource 'registros de tarefa.' This distinguishes it from sibling tools like music360_get_tarefa, which retrieves a single record, and other list tools for different entity types.

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 no guidance on when to use this tool versus alternatives such as music360_get_tarefa for individual records or music360_search for broader queries. It only mentions the tenant scope, leaving out any explicit context about intended use cases or exclusions.

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 implies a read-only listing operation, but does not mention that sensitive response profiles require admin access or that include_sensitive_details exists. These details are in the schema, but the description adds no behavioral context beyond the integration hint.

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, front-loaded with the main purpose, and includes a relevant usage pointer with no unnecessary words.

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

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

For a simple list tool with optional parameters and an output schema, the description plus schema covers the necessary context. The integration hint about create_tarefa adds value, though authentication or sensitive-access context is left to the 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 description coverage is 100%, so the baseline is 3. The description adds a useful cross-tool hint about the 'value' field in the output, but does not elaborate on the input parameters, which are already well-documented in the schema.

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

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

The description states the tool lists valid categories for creating tasks, using a specific verb and resource ('Lista categorias válidas para criar tarefas'). This clearly distinguishes it from sibling tools like music360_list_tarefa, music360_list_tarefas_fases, and music360_list_tarefas_status.

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

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

The description provides a clear usage pointer: use the returned 'value' field in music360_create_tarefa.categoria. This implicitly says when to use the tool (before creating a task), but does not explicitly name alternatives or 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?

Since no annotations are provided, the description carries the burden of disclosing behavior. It states the tool lists valid phases and explicitly points to the 'value' field in the output, providing insight into the response structure and integration with the create tool. This is sufficient for a simple read-only enumeration 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?

The description is two sentences long, front-loads the main verb ('Lista'), and provides immediate, actionable context. Every word earns its place with no redundancy or irrelevant 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?

For a simple validation-list tool with an output schema, the description provides enough context for an agent to select and use it correctly. It explains the purpose, the output field to consume, and how to integrate with a related tool. Additional details like pagination are not necessary for this straightforward use case.

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 all three parameters with complete descriptions (100% coverage), so the description does not need to repeat parameter details. The description adds no additional meaning about parameters beyond the schema, which is acceptable given the schema's thoroughness.

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

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

The description clearly states the tool's function: listing valid phases for creating tasks. It specifies the resource ('fases válidas') and the target use case, distinguishing it from sibling list tools like list_tarefas_categorias and list_tarefas_status.

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

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

The description provides direct usage guidance: 'Use o campo value em music360_create_tarefa.fase' tells exactly how to apply the results, making the intended context clear. It does not explicitly mention alternatives or when not to use the tool, but the reference to a specific create tool serves as a practical 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 are provided, so the description carries the full burden. 'Lista' implies a read-only operation, and the note about using the 'value' field reveals response structure. However, it does not disclose auth requirements, whether the list is exhaustive, or pagination behavior. Minimal but adequate for a simple enumeration 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 short sentences with no filler. The main purpose is front-loaded, and the usage instruction is concise and practical. 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 simple list tool, this is nearly complete: it states what it lists, why it is needed (for create_tarefa), and the schema covers parameters. It lacks discussion of the response_profile or sensitive details, but those are documented in the schema, and the 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 description coverage is 100%, so the schema fully documents all three parameters. The description adds no parameter-level detail beyond the schema, but the baseline is 3 because the schema does the heavy lifting. The cross-reference to another tool does not apply to this tool's own 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 uses a specific verb ('Lista') and resource ('status válidos para criar tarefas'), clearly distinguishing it from sibling tools like list_tarefas_categorias or list_tarefas_fases. It also tells exactly why this list exists: to feed the status field in music360_create_tarefa.

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 explicitly states when to use this tool: before creating a task, to get the valid status values for the create_tarefa.status field. It does not contrast with sibling list tools, but the unique purpose makes confusion unlikely. A score of 4 reflects the lack of explicit exclusions.

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. 'Lista' implies a read-only operation, which is transparent enough, but it does not disclose details such as whether sensitive parameters require admin permissions or any other behavioral constraints. It adds minimal context beyond the literal function.

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 concise sentences, each earning its place. The first states the purpose, the second gives a direct actionable link to the consuming tool. No fluff or 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 simple nature of a reference list tool and the presence of an output schema (which covers return values), the description provides sufficient context. It explains the purpose and how the result should be used, and the schema handles parameter details. It is 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 description coverage is 100% with all three parameters documented. The description mentions the 'value' field but does not explain the tool's own parameters, so it adds no extra semantic value beyond the schema. Baseline 3 is appropriate given full 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 it lists valid types for creating videograms, using the specific verb 'Lista' (lists) and resource 'tipos válidos para criar videogramas'. It also distinguishes itself from sibling tools like music360_list_videograma by focusing on types rather than the videograms themselves, and it explicitly references the target field in music360_create_videograma.

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 instruction 'Use o campo value em music360_create_videograma.videogramas_tipo_id' clearly indicates when to use this tool: as a reference for creating videograms. It implies it is not a general videogram listing tool, though it does not explicitly exclude alternatives. The context is clear without needing to name siblings.

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

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

With no annotations provided, the description carries full behavioral burden but only adds 'do tenant atual' (current tenant scope). It does not disclose default ordering, pagination behavior, response profile selections, or sensitive access requirements, which are relevant given the rich 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?

The description is a single, focused sentence with no fluff. It is front-loaded with the action and resource, making it easy to parse. Extreme terseness is a tradeoff, but for pure conciseness it earns a top score.

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 an output schema, the description misses critical context: there is no hint about pagination defaults, sort behavior, or sensitive data handling. For an 8-parameter tool, this description is insufficient to guide effective use.

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 has 63% coverage with some parameter descriptions, but the tool description adds no parameter information. It doesn't compensate for the undocumented parameters like page, search, and per_page, and doesn't clarify how response_profile or sensitive_details work.

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 'Lista registros de videograma do tenant atual' clearly states the verb (Lista), the resource (registros de videograma), and scope (tenant atual). It distinguishes from sibling tools like music360_get_videograma (single record) and music360_list_tipos_videograma (types, not records).

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 no guidance on when to use this tool versus alternatives, no prerequisites, nor mentions of filtering or pagination. Usage is only implied by the tool name and listing nature.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only defines the search scope. It does not mention whether results are grouped by type, whether the search is fuzzy or exact, how limit applies, or what happens when there are no matches. This is a significant lack of transparency for a search 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?

The description is a single short sentence in Portuguese, efficiently stating the tool's purpose without any extraneous words. It is appropriately sized and front-loaded, earning a perfect score for conciseness.

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 handles a broad multi-entity search with a limit parameter and no annotations, yet the description provides only the scope. While an output schema exists (reducing the need to document returns), there is no guidance on when to use it, what behavioral quirks exist, or how results are structured. For a tool of this complexity, the description is under-specified.

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 50% of parameters: query has a one-word description ('Texto de busca.'), while limit has none. The description itself adds no parameter detail, failing to explain how the query is matched or how the limit parameter behaves. Since the schema coverage is middling and the description does not compensate, parameter semantics are weak.

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 'unified search' with a specific list of resource types (artists, works, phonograms, products, contacts, contracts, news, tasks). This distinguishes it from the sibling get/list tools that target single entity types, making the purpose unambiguous.

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

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

The description implies the tool is for searching across multiple entity types as a unified entry point, but it does not explicitly state when to prefer it over the get/list alternatives or provide exclusions. No guidance is given on query syntax or how to use the limit parameter effectively.

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