get_endpoint_threat_alerts

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

With no annotations to rely on, the description carries the full burden of behavioral disclosure. It reveals that the tool internally opens a Direct Connect connection (implying network dependency) and retrieves only the last 24 hours of alerts, setting expectations about latency and data recency. It does not explicitly state whether the operation is read-only, but the verb '조회' implies inquiry, and the description adds more behavioral context than a minimal update tool would.

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 concise and front-loaded. The first clause states the main purpose (querying endpoint threat alerts), followed by implementation details (Direct Connect, 24-hour window) and a business-requirement note. Every sentence earns its place with no fluff. It is short, informative, and well-structured.

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?

Given the tool has a single parameter, no output schema, and no annotations, the description covers essential context: the endpoint scope, the time window, and the internal connection behavior. It does not describe the return format, but the purpose and name make it clear that a list of alerts is returned. The business requirement adds practical context for when this tool is needed. It is nearly complete for the simplicity of the tool.

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%: the endpointId parameter has a full description in the schema, including the instruction to use computerID from get_all_assets. The tool description itself adds no additional parameter semantics beyond what the schema already provides. According to the rubric, when schema coverage is high, the baseline score is 3, which is appropriate here.

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 the tool queries Threat Response alerts (performance/anomaly detection) for a specific endpoint, using the Korean verb '조회합니다' (queries). It distinguishes itself from siblings by explicitly focusing on endpoint threat alerts, which is unique among the sibling list that includes asset, compliance, CVE, and patch tools. The added detail about the last 24 hours and business requirement further specifies its scope.

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 provides clear context on when to use the tool: for endpoint threat alerts, specifically zero-day or anomaly detection history within the last 24 hours. However, it does not explicitly name alternative tools or state when not to use it, though the sibling set makes this fairly obvious. The business requirement note ('제로데이/이상탐지 이력') gives a purpose, but lacks an explicit exclusion.

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