Skip to main content
Glama

music360_list_contato

Lista registros de contato do tenant atual.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
searchNo
order_byNoCampo para ordenacao (ex.: data_lancamento/lancamento, nome, atualizacao, criacao). Para produto fonografico, "lancamento" e "mais recente" significam data_lancamento. Quando omitido, usa ordenacao padrao da entidade.
per_pageNo
order_dirNoDirecao da ordenacao: ASC crescente, DESC decrescente (padrao).
response_profileNoPerfil de resposta. Listagens usam summary por padrão; sensitive exige admin.
sensitive_access_purposeNoFinalidade operacional obrigatória quando response_profile=sensitive ou include_sensitive_details=true.
include_sensitive_detailsNoRetorna detalhes sensíveis mínimos quando autorizado por escopo admin. Padrão: false.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesResultado paginado.
successYesIndica se a operacao foi bem-sucedida.
entity_typeYesTipo da entidade consultada.

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, targeting a specific entity or reference data. The get/list distinction is standard and unambiguous. Reference list tools are also clearly separated by domain.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with the prefix 'music360_'. Verbs are consistently 'get', 'list', 'search', or 'healthcheck', and the naming is uniform throughout. No mixed conventions or vague verbs.

Tool Count2/5

At 33 tools, the set is quite large, exceeding the threshold where tool count becomes unwieldy. While the domain has many entity types, the lack of mutation tools means many similar read-only list/get tools inflate the count without adding corresponding functionality.

Completeness1/5

The tool set is severely incomplete for a management system: there are no create, update, or delete tools for any entity. The reference list tools explicitly reference create tools like 'music360_create_fonograma' that do not exist, leaving clear dead ends and an inability to perform core operations.

Resources