list_note_componentsList the components present in a note, such as transcript, memo, summary, recording, or meeting notes. Use it to quickly see available elements without fetching the full transcript text.
노트에 어떤 컴포넌트(transcript/memo/summary/recording/meeting_notes 등)가 있는지 요약해서 보여줍니다. 전사 본문이 아니라 목록만 필요할 때 사용하세요.
| Name | Required | Description | Default |
|---|---|---|---|
| noteId | Yes | Alt 노트 ID |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It reveals that the tool returns a summary/list of components rather than full content, which is useful. However, it does not explicitly state whether the operation is read-only, what the exact return format is, or how it behaves for notes with no components.
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 in Korean, front-loading the component type list and immediately scoping the intended use case. Every sentence contributes value, and there is no redundant or filler content.
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 single-parameter list tool with no output schema, the description is largely complete: it identifies the resource, the output scope (component summary), and the intended use case. The only notable gap is the lack of detail about the exact return format, but the low complexity keeps this from being a significant issue.
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?
The input schema has 100% description coverage for noteId, described as 'Alt 노트 ID'. The tool description adds only the general context of operating on a note and does not provide additional parameter-level meaning. According to the rubric, high schema coverage anchors this at baseline 3.
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 that the tool summarizes which components (transcript/memo/summary/recording/meeting_notes) a note has, making the resource and action specific. It also explicitly says it is not the transcript body, which helps distinguish it from get_note_transcript. However, it does not differentiate from get_note_info, which could plausibly return similar component metadata.
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 a clear when-to-use signal: use it when only the list of components is needed, not the full transcript body. This implicitly points toward get_note_transcript as the alternative for full transcript content. It does not explicitly address other sibling tools like get_note_info, but the usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.