ntable — AI Meeting Facilitation

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

With no annotations, the description carries the full burden. It usefully discloses an ownership precondition ('이 에이전트가 개설한 회의' — the meeting must have been created by this agent) and a downstream effect (items appear as carryover candidates in the meeting report summary). It does not mention failure modes, whether items can be removed, or any constraints beyond the schema's length limits.

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?

Two short sentences, front-loaded with what is stored and where, followed by the condition for use. No filler and no repetition of the title.

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?

Purpose, trigger, precondition, and side effect are all covered, which is decent for a two-parameter write tool with no output schema. But with zero schema description coverage and no annotations, the parameter meanings and any write-related caveats are left hanging, so it is only minimally complete.

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% for two required parameters, and the description adds no meaning for either. The opaque 'room_code' (4-10 chars) in particular is left entirely unexplained, and 'text' is only implicitly the parked item. The description should have compensated here and does not.

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 names a specific verb (보관한다, 'stores') and a specific resource (the parking lot of a meeting created by this agent), so the action is unambiguous. It does not explicitly contrast itself with siblings like get_carryover or get_meeting_report, though the parking-lot concept is distinctive enough to separate it.

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?

It states the triggering condition clearly: use it when an off-agenda discussion should be left as a carryover candidate for the next meeting. No explicit exclusions or named alternatives are given, so it lands short of a 5, but the when-to-use context is concrete.

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

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

With no annotations, the description carries the full burden: it discloses that topic triggers AI question-pack generation, that context_doc inherits prior context, and that a participation link/QR is returned for sharing. It omits permissions, failure modes, and mutable-vs-reversible semantics, but the conditional side effects and return artifacts are meaningfully covered for a creation 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?

Three tight sentences, front-loaded with the core action before the conditional variants. Every sentence carries information; only the final sharing sentence is marginally advisory rather than necessary.

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?

No output schema exists and no annotations are provided, so the description correctly compensates by naming the returned link/QR. It covers the parameter-driven behaviors and the return artifact, leaving only edge cases like auth or errors unaddressed, which is reasonable for this scope.

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%, so the schema already documents all five parameters including the ~17s latency note and the list_meeting_kits reference. The description reinforces topic/context_doc behavior but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource ('ntable 회의를 개설한다') plus the two conditional behaviors that make this tool distinct (AI 질문팩 via topic, context inheritance via context_doc). It is unmistakably the creation tool versus the read-oriented siblings like get_meeting_report or list_meeting_kits.

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 explains what happens when you supply topic or context_doc, which implies usage, but never states when to reach for this tool versus list_meeting_kits or run_idea_board, nor any preconditions. Usage is inferable from the conditional feature description rather than explicitly guided.

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

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

With no annotations, the description carries the full disclosure burden; it does reveal the shape of what is returned (current state plus vote-ranked results), which is useful. However it says nothing about read-only safety, access requirements for the room, or behavior when the board has not converged.

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?

Two sentences with zero waste: the purpose is front-loaded, followed immediately by the triggering scenario. Nothing is repeated or filler.

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 simple one-parameter getter with no output schema, the description covers what comes back at a high level. It still omits room_code semantics and access/prerequisite details, leaving gaps for an agent invoking it cold.

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 coverage is 0% and the single parameter room_code is never mentioned in the description. The name is largely self-explanatory, but no format, length, or sourcing guidance is offered to compensate for the empty schema description.

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?

States a specific verb+resource: returns the idea board's current state and vote-ranked results. It is distinguishable from the sibling run_idea_board (which executes the board) and get_meeting_report, though it does not name those siblings explicitly.

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?

Gives a concrete usage context: handing off the priority list of a converged meeting to follow-up work. It does not state when not to use it or name an alternative such as get_meeting_report, so routing is left partially to inference.

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

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

With no annotations and no output schema, the description carries the full disclosure burden, and it does cover the non-obvious behavior: results are limited to the most recent ended meeting where this agent was facilitator, and only undecided agendas plus unfinished parking-lot items qualify. It omits edge behavior such as what is returned when no ended meeting exists or how results are ordered.

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?

Two sentences, front-loaded with the return content and its source scope, followed immediately by the intended downstream usage. No filler, no restatement of the title.

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 zero-parameter getter with no annotations and no output schema, the description adequately identifies what comes back (two item categories) and what to do with it. Minor gaps remain around empty-result behavior and whether the result is a flat list or grouped structure.

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 tool takes zero parameters, so per the baseline this scores 4; there is no parameter semantics for the description to add or omit. The stated date/meeting scoping is implicit behavior rather than a configurable input.

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 states a specific verb and resource (returns undecided agenda items and incomplete parking-lot items as carryover candidates) and precisely scopes the source: the most recent ended meeting this agent facilitated. That scope definition lets an agent distinguish it from siblings like get_meeting_report or get_board_results without opening a schema.

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?

It gives clear operative guidance — feed the result into create_meeting's agendas to build the follow-up meeting — which is exactly the workflow the tool exists for. It does not state when NOT to use it or contrast it explicitly against alternatives such as get_meeting_report, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral trait — only anonymous aggregates are returned and no personally identifying information is included — which is genuinely useful and non-obvious. It does not cover permission/auth requirements, error behavior, or whether reports are available only for ended meetings, so for an unannotated read tool this is adequate but incomplete.

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?

Three short sentences, each carrying distinct payload: what is returned, the privacy constraint, and the usage trigger. Front-loaded with the purpose. Dense and waste-free, though the parenthetical content enumeration makes the first sentence slightly heavy.

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?

With no output schema, the description usefully enumerates the report's return sections (agenda, vote tally, decision/owner/deadline, AI summary) and the anonymity guarantee, which covers the main gaps. A simple one-parameter read tool with no annotations is described well enough to call correctly, though permission prerequisites remain unstated.

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 coverage is 100% for the single room_code parameter (with min/max length and an example), so the schema already does the work. The description adds no format or semantics beyond that, which is the correct baseline when the schema is self-sufficient.

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?

States a specific verb (가져온다/fetch) plus the exact resource and its contents: agenda report (agenda → vote tally → decision/owner/deadline) and AI minutes summary. An agent knows precisely what comes back, though it does not distinguish itself from lookalike siblings such as get_carryover or get_board_results.

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?

Gives a concrete trigger condition — use when propagating the decisions of a finished meeting into follow-up work (끝난 회의의 결정사항을 후속 업무로 전파할 때). No explicit exclusions or named alternatives, so the agent must still infer why not get_carryover, which is a plausible substitute for the same follow-up scenario.

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

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

No annotations are provided, so the description carries the full burden. It declares a read-like 'returns' action but says nothing about filtering, pagination, return volume, or permissions for the qks. For a list tool with zero annotation coverage, this is a significant gap.

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?

A single efficient sentence front-loads the resource and action with no waste. It is appropriately sized, though the brevity trades off against behavioral detail.

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 no-arg, no-annotation list tool the description covers the basic purpose, but with no output schema and no annotations it should at least hint at what the returned list contains or how it relates to create_meeting. Adequate but with clear gaps.

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 tool takes zero parameters, so there is nothing to document and no syntax to add. Baseline 4 applies since the empty schema already makes invocation unambiguous.

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 states a verb (반환한다 / returns) and resource (회의 킷(pack) 목록), giving an identifiable purpose. However it doesn't distinguish from siblings beyond the resource name — it doesn't explain what a 'meeting kit' is or how this relates to create_meeting.

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 phrase '개설에 사용할 수 있는' (that can be used for creation) implies the usage condition: call this before creating a meeting to pick a kit. But it doesn't explicitly name an alternative or state when NOT to use it. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the ownership constraint (agent-created meetings only) and the anonymous nature of the board, but as a mutation tool it says nothing about irreversibility, permission needs beyond ownership, or error/locking behavior when a stage transition is invalid.

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?

Two tight sentences with the purpose front-loaded and the lifecycle detail following. Slight redundancy between the parenthetical workflow in sentence 1 and the stage list in sentence 2, but nothing is wasteful.

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?

With no output schema and no annotations, the description must cover both behavior and results. It adequately conveys the stage lifecycle and ownership scope, but omits the preset option and gives no indication of what the call returns or how invalid transitions are handled.

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 coverage is 67% and both enums are already documented in the schema. The description adds semantic value by mapping the stage order collect→vote→result, but the 'preset' parameter (ideation/kpt/fourls) is never mentioned, and the distinction between 'start' and 'collect' remains ambiguous from the description alone.

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?

States a specific verb and resource ('익명 아이디어 보드'를 시작하거나 단계를 전환) and names the full workflow (브레인라이팅→도트 투표→결과). It implicitly separates itself from the read-oriented sibling get_board_results, though it never names a sibling directly.

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?

Gives a clear precondition: the board operates only on a meeting '이 에이전트가 개설한' (created by this agent), which tells the agent when this tool is applicable. It does not name alternatives or explicitly say when not to use it (e.g., vs get_board_results for reading state).

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