ise_mnt_session_by_id

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 does add one useful behavioral detail — 'Returns raw XML' — which tells the agent the response format. However, it does not disclose whether the session must be active, error behavior when the session is not found, whether the sid must be an active session ID vs a historical one, or any authentication/authorization requirements for this MNT endpoint.

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 tight single sentence plus a return-format note. It's front-loaded with the purpose and includes the raw API endpoint path which is helpful. It avoids verbosity. Not a 5 because it could have packed in more behavioral guidance in the same space, but it's efficient with no waste.

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 no annotations and no output schema, the description should carry more weight. The 'Returns raw XML' note is the only behavioral context beyond the schema. It doesn't explain what an active session ID means, what happens for invalid IDs, what outputType options exist, or how this relates to session lifecycle. Given the complexity of the MNT API and zero annotation coverage, this is notably underdeveloped.

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 already documents 'sid' and 'outputType' as path parameters and 'deployment' with full explanation. The description adds 'Returns raw XML' which hints at what outputType might control but doesn't specify valid outputType values or format expectations. Since the schema handles parameter documentation well, the baseline of 3 is appropriate; the description adds minimal extra value.

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 'Get Active Session by Session ID' with the HTTP method (GET) and URL path. It identifies the resource (active session) and lookup method (by session ID), distinguishing it functionally from siblings like ise_mnt_session_by_mac, ise_mnt_session_by_username, and ise_mnt_session_by_ip. It's just slightly below a 5 because it doesn't explicitly note what makes it different from ise_mnt_active_session_list or how the session ID differs from other session lookup keys.

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 states what the tool does (get a session by id) but gives no explicit guidance on when to use it versus alternatives like ise_mnt_session_by_mac, ise_mnt_session_by_ip, or ise_mnt_active_session_list. The '[Sessions]' label provides mild context. There is no 'when-not-to-use' or alternative recommendations, though the sibling naming partially conveys the distinct lookup keys.

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