get_role_config_groupsRetrieve a service's role config groups and their settings, showing only non-default values by default to inspect service role configuration.
Role config groups de um serviço e suas configurações (por padrão só valores alterados).
| Name | Required | Description | Default |
|---|---|---|---|
| cluster | Yes | ||
| service | Yes | ||
| only_non_default | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden, yet it only restates the default filtering behavior already encoded in the schema (only_non_default=true). It says nothing about required permissions, whether results are scoped per-service, or any read-only/side-effect guarantees an agent would want before invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no filler, and the default-behavior caveat is placed usefully at the end. It is short almost to a fault, but nothing is wasted.
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, so return values need not be explained, but for a tool requiring a cluster plus service identifier and offering a filtering flag, the definition omits the cluster parameter entirely and provides no call-context guidance. It is under-specified relative to the tool's parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters. The description indirectly implies 'service' and explains that 'only_non_default' defaults to filtering to changed values, but the required 'cluster' parameter is never alluded to, so a third of the parameters remain undocumented in both schema and prose.
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 names a specific resource ('role config groups de um serviço') and indicates that their configurations are returned, so an agent can tell it apart from generic config tools like get_service_config. However, the verb is implicit (a bare noun phrase, no 'list'/'get'), leaving the operation type to be inferred from the name alone.
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 states that only changed values are returned by default, which is mildly useful context, but gives no when-to-use guidance, no prerequisites (e.g., that the service must exist in the cluster), and never contrasts itself with siblings such as get_service_config or list_roles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.