tracker_components_group_permissions_getRetrieve group permissions for a Tracker component to see whether the group can create, read, write, or is denied access.
What one group may do on a component (create, read, write, deny).
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | Numeric id of the group. | |
| component_id | Yes | Numeric id of the component. |
Changes observed during successful MCP inspections.
v0.67.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered structurally. The description adds a useful behavioral detail not in the schema/annotations: the enumeration of permission levels (create, read, write, deny) that can come back. It stops short of saying anything about the response shape.
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, front-loaded on the core meaning. There is no filler, though the extreme brevity borders on under-specification rather than tightness.
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 two-parameter read tool with no output schema and full annotation coverage, this is minimally adequate. The permission-level list hints at the returned values, but there is no guidance on the sibling tool or on the response structure, leaving gaps an agent would have to guess at.
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 both group_id and component_id are already documented in the schema. The description's 'one group' / 'a component' merely restates the parameters and adds no format or constraint detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific retrievable fact (a group's rights on a component) and enumerates the possible right values. It does not, however, distinguish itself from the sibling tracker_components_user_permissions_get, which retrieves the analogous per-user data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to call this versus the very close sibling tracker_components_user_permissions_get, nor any prerequisites (e.g. needing read rights on the component). Usage must be inferred from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.