Skip to main content
Glama

rx_find_employees

Read-only

Find employees by last name or partial name to get IDs, positions, departments, and emails. Use before task creation to identify the right assignee; active records by default.

Instructions

Найти сотрудников по фамилии или части имени: Id, должность, подразделение, почта. Используйте перед rx_create_simple_task, чтобы получить Id исполнителя, или чтобы узнать, кто есть кто. По умолчанию только действующие сотрудники; include_inactive=true добавляет закрытые записи. Только чтение.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoсколько строк показать, по умолчанию 20, максимум 100
queryYesфамилия или часть имени, например Петров или Анна; регистр не важен
include_inactiveNotrue = включая закрытые записи сотрудников (уволенные); по умолчанию только действующие

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.2
    • addedInput schema / properties / include_inactive / description
      Added value: +"true = включая закрытые записи сотрудников (уволенные); по умолчанию только действующие"
    • addedInput schema / properties / limit / description
      Added value: +"сколько строк показать, по умолчанию 20, максимум 100"
    • changedInput schema / properties / query / description
      Previous value: -"фамилия или часть имени"New value: +"фамилия или часть имени, например Петров или Анна; регистр не важен"
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Аннотации уже сообщают readOnlyHint=true, openWorldHint=false и idempotentHint=false, поэтому описание добавляет контекст сверх этого: фильтрацию по умолчанию только действующих сотрудников и возвращаемый набор полей. Фраза «Только чтение» дублирует аннотацию, но полезное указание на include_inactive расширяет понимание поведения. Не раскрыты ограничения по авторизации или лимитам, но для простого поиска это не критично.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Описание состоит из четырёх коротких предложений, начинается с сути и возвращаемых полей, затем переходит к использованию и поведению по умолчанию. Последняя фраза «Только чтение» повторяет аннотацию readOnlyHint и не добавляет новой информации, что слегка снижает эффективность каждого предложения.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Для простого поискового инструмента без output-схемы описание даёт всё необходимое: назначение, возвращаемые поля, сценарии использования и управление активными/неактивными записями. Аннотации дополняют профиль безопасности, а схема покрывает параметры, поэтому пробелов для корректного вызова нет.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Покрытие описаний в схеме 100%, поэтому базовый уровень — 3. Описание упоминает include_inactive=true, но эта семантика уже полностью раскрыта в схеме; для query и limit дополнительных пояснений не добавлено. Схема несёт основную нагрузку по параметрам.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Специфический глагол «Найти» и ресурс «сотрудников» с указанием возвращаемых полей (Id, должность, подразделение, почта). Описание отличает инструмент от соседей по фокусу на сотрудниках и явно связывает его с rx_create_simple_task, что помогает агенту понять назначение.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Явно указано, когда использовать: перед rx_create_simple_task для получения Id исполнителя или чтобы узнать, кто есть кто. Также раскрыто поведение по умолчанию (только действующие сотрудники) и как включить закрытые записи через include_inactive=true. Альтернативы названы через конкретный соседний инструмент.

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