employees__get_personal_session_info

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds significant behavioral context beyond annotations by disclosing an MCP-server-specific throttling limit (10 requests per 60 seconds) and recommending caching the result in the conversation, which directly affects how an agent should invoke the tool.

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 three sentences: purpose, ID sourcing, and throttling/caching advice. Each sentence earns its place, the purpose is front-loaded, and there is no redundant filler or repetition of schema information.

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 read-only tool with a simple nested request and no output schema, the description covers purpose, parameter sourcing, and rate-limit guidance. It does not explicitly describe the return value (e.g., whether it returns a boolean), but the question phrasing implies a yes/no outcome, making it adequately complete though not exhaustive.

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%, so the description must compensate. It maps each parameter to a specific sibling tool that provides the value (employeeId → employees__get_employee_info; organizationId → organizations__get_organizations; terminalGroupId → terminal_groups__get_terminal_groups), giving the agent actionable parameter sourcing. It does not describe parameter meaning in depth, but this mapping is highly valuable given the minimal schema.

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 opens with a direct question 'Открыта ли личная сессия сотрудника' (Is the employee's personal session open), clearly identifying the resource (employee personal session) and the action (checking its status). This distinguishes it from the many getter tools in the sibling list by its unique focus on personal session state, though it is phrased as a question rather than an explicit verb like 'get' or 'check'.

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 gives explicit guidance on where to obtain each required ID (employeeId → employees__get_employee_info; organizationId → organizations__get_organizations; terminalGroupId → terminal_groups__get_terminal_groups), which is a useful prerequisite. However, it does not explicitly state when to use this tool over alternatives or provide exclusions/when-not-to-use conditions, leaving the usage context implied.

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