Retrieve node IDs currently visible on screen after filter application, using deterministic sorting and pagination. Returns all nodes when no filter is active.
사람 화면에서 지금 보이는(필터 통과) 노드 id ([5-C]).
필터가 없으면 전부 보이므로 전체 노드를 준다. 결정적 정렬 + 페이지네이션.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals deterministic sorting and pagination, which is useful, but doesn't explicitly state that it's a read-only operation or disclose any side effects, costs, or rate limits. The behavior is lightly covered but incomplete for a fully undisclosed context.
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 two concise sentences, front-loaded with purpose and functional details. It avoids fluff and is appropriately sized for a simple tool, earning a high score in this dimension.
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 has an output schema (not shown), so return-value details are covered. The description covers pagination and deterministic ordering, but misses critical context like the distinction from list_nodes and when to prefer this tool. It's adequate but not comprehensive.
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 explain the parameters. It mentions pagination but doesn't connect it to 'limit' or 'offset', nor does it explain their meaning, bounds, or effects. The agent must infer what the parameters do from the schema alone, which is insufficient.
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 returns node IDs visible on screen after filtering, which is a specific verb+resource. It distinguishes itself from generic list operations by mentioning the filter and human screen context, but does not explicitly differentiate from sibling 'list_nodes', so it's not a 5.
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?
No guidance is given on when to use this tool versus alternatives like list_nodes, get_node, or search. It doesn't mention conditions for selection or exclusions. The context is only implied by the name and description, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.