Retrieve detailed information for a specific application group using its hashed group ID. Provides asset and application details for a given organisation.
Get detailed information for one application group by its hashed group ID.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | Hashed application group ID. | |
| organisationId | Yes | The RoboShadow organisation's UUID. Discover it with roboshadow_list_organisations. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. 'Get detailed information' signals a read-only lookup, but the description says nothing about auth requirements, invalid-ID behavior, rate limits, or whether any state is modified. With zero annotation coverage, this is too thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler: the action is front-loaded ('Get detailed information') and the key identifying input ('hashed group ID') appears immediately. 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?
The tool itself is simple and the schema fully documents both parameters, so the description is minimally usable. However, with no output schema and no annotation safety profile, it does not describe the return shape and it omits how to obtain a group_id (e.g., via roboshadow_list_application_groups), leaving 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?
Schema description coverage is 100%: both group_id and organisationId are already documented in the schema, and the organisationId description even names roboshadow_list_organisations for discovery. The tool description merely restates 'hashed group ID' and adds no format, constraint, or relationship details beyond the schema, so the high-coverage baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Get'), resource ('application group'), and scope ('one ... by its hashed group ID'), so an agent immediately knows this is a single-item lookup. It implicitly differentiates from roboshadow_list_application_groups by saying 'one', but it does not explicitly name that sibling or contrast its behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool instead of roboshadow_list_application_groups or the other get_* siblings, and no prerequisite workflow such as 'obtain the hashed ID from list_application_groups first.' The phrase 'by its hashed group ID' only implies a prerequisite without giving actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.