ChatAd 손님 (chatad.kr)

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

어노테이션이 없어 설명이 행동 특성을 직접 담당해야 하는데, 쿼터를 소모하지 않는다는 점과 로그인 없이 호출 가능함을 시사하는 점을 명시해 유용하다. 되돌릴 수 없는 변경이 없고 입력 파라미터도 없다는 점이 구조에서 자명하지만, 반환 형식에 대한 서술은 부족하다.

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?

세 개의 짧은 문장으로 군더더기 없이 구성되어 있고, 무엇을 돌려주는지가 맨 앞에 배치되어 있다. 모든 문장이 호출 판단에 기여한다.

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?

파라미터 0개, 출력 스키마 없음, 단순 조회 도구라는 맥락에서 설명이 반환 내용의 범주와 호출 시점, 비용 특성까지 모두 다룬다. 에이전트가 이 도구를 올바로 호출하는 데 필요한 정보가 빠져 있지 않다.

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?

파라미터가 0개이므로 규정상 기준선 4가 적용된다. 설명이 반환 내용의 항목을 나열해 파라미터 부재를 자연스럽게 상쇄한다.

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?

한 문장에서 구체적인 동사('돌려준다')와 대상(서비스 소개, 로그인 없이/가입 후 사용 가능 기능, 가입 방법)을 명시해, 에이전트가 이 도구가 무엇을 반환하는지 즉시 알 수 있다. '처음 들어왔으면'이라는 호출 시점 신호가 자매 도구와의 역할 차이를 자연스럽게 구분해 준다.

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?

'처음 들어왔으면 이것부터 부른다'로 호출 순서를 명확히 지시하고, '하루 한도에 들지 않는다'로 호출 비용 조건까지 밝힌다. 다만 이 도구를 쓰지 말아야 하는 경우나 다른 자매 도구(get_guides, get_plans 등)로 대체해야 하는 조건은 언급하지 않아 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?

With no annotations, the description carries the full burden and does so well: it discloses the auth model (no login required) and concrete rate limits per session/day/bot tier, which is exactly the operational context an agent needs before spending calls. It stops short of describing latency, caching, or failure behavior for unreachable sites.

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: what it returns, when to call it, and the quota warning last. Every sentence earns its place and the return-value list is front-loaded.

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 one-parameter tool with no output schema, the description enumerates return fields and covers the operational constraints (auth, quotas). Nothing an agent needs to call it correctly is missing.

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% and the single `url` parameter is already documented in the schema (including the https:// hint), so baseline 3 applies. The description adds no additional meaning about the URL parameter itself.

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 enumerates the exact return payload (title, description, main content, ad goal candidates, context hints, minimum daily budget), which clearly separates it from siblings like draft_campaign or check_ad_readiness.

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?

Explicitly gives the triggering condition: '캠페인 초안을 만들기 전에 부른다', routing the agent to call this before draft_campaign. No explicit when-not or named alternative cases, but the sequencing guidance is clear.

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 provided, the description carries the full burden and does disclose concrete operational constraints: 50 calls per MCP session unauthenticated, 3/day without a session number, 5/day for identified bots. That is genuinely useful rate-limit context rarely surfaced elsewhere. Gaps remain: it does not say whether a login/session changes behaviour beyond quota, nor what a failed or blocked check result looks like.

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 what is checked, followed by the quota note. No filler. The emoji-as-bullet is slightly noisy but does not obscure meaning.

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 read tool with no output schema, the description covers the checks performed and the rate limits, which is the essential part. It does not indicate the shape of the result (per-check pass/fail, summary verdict, diagnostics) or behaviour on unreachable sites, so an agent cannot anticipate the return value.

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?

Only one parameter, and the schema already documents it at 100% coverage including the tip that the https:// prefix may be omitted. The description adds no further semantics about the url argument, so the schema does all the work and the baseline of 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 concrete verb and resource (reads the site's landing page) and enumerates exactly what is checked: GTM, GA4, Meta pixel, and site response. An agent knows precisely what this returns conceptually. It does not, however, contrast itself with the sibling analyze_site, which sounds adjacent in 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?

There is no when-to-use or when-not-to-use guidance and no reference to any sibling tool, even though analyze_site and the campaign/signup tools occupy neighbouring territory. The agent must infer the selection context (pre-campaign readiness check) on its own.

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 behavioral burden and does disclose the two outcome states plus the polling interval. It still omits error/expiry cases and permission/auth details, but the core behavior is transparent.

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, front-loaded with the action and followed by outcome and retry instruction. No redundant text.

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 is simple, and the description explains return states without an output schema. However, it leaves the device_code provenance and failure modes unstated, which matters for an agent invoking it correctly after start_signup.

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 sole required parameter device_code is not described; the description only refers to 'device 방식' without saying where device_code comes from or its format. It does not compensate for the schema gap.

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 check operation on device-flow user approval and states both outcomes (access_token vs pending). It is clear enough to identify the tool, though it does not explicitly differentiate itself from start_signup/complete_signup by name.

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 a retry rule: if status is pending, call again after interval seconds. That is useful polling guidance, but it never states when to use this versus start_signup or complete_signup, nor any prerequisites such as having a device_code from an earlier step.

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 exist, so the description carries the full burden, and it does well: it discloses the return value (access_token), the required auth header form (Authorization: Bearer), and the exact downstream endpoint including the '?guest 없이' distinction. It omits failure behavior, token lifetime, and whether client_name affects the resulting account, keeping it short of a 5.

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, front-loaded with the step position and outcome, then the follow-up call. The parenthetical '(?guest 없이)' is terse but functional; nothing is 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?

With no annotations and no output schema, the description must cover the return and side effects, and it does explain the token and next call. But for a credential-issuing tool it says nothing about code expiry, retry/failure semantics, or the meaning of client_name, so an agent cannot handle error paths from the description alone.

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 only 33% and the description compensates only partially: it clarifies that 'code' is the 6-digit code the user reads aloud, going slightly beyond the schema's '메일로 받은 6자리 숫자'. The 'email' and especially 'client_name' parameters get no explanation in either the schema or the description, leaving a third of the inputs undocumented.

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 (signup/login completion) and the concrete outcome (access_token) for the email_code flow, positioning itself as the final step. This distinguishes it from siblings start_signup and check_signup, though those siblings are not named 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?

Clears the key precondition: it is the last step of the email_code method, invoked with the 6-digit code the user has read out — implicitly after start_signup. It also tells the agent exactly what to do afterwards (call the member MCP with the token), though it never states what to do on a wrong/expired code or how it differs from check_signup.

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?

There are no annotations, but the description still carries the full behavioral burden well. It explicitly states this is a non-mutating operation (nothing is created in the advertiser account) and that the budget is capped at the amount the user named. It also discloses the auth and rate-limit profile (50 per MCP session without login; 3 per day with no session number; 5 per day for named bots). These are exactly the constraints an agent needs before calling, and none of them appear in the schema.

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 purpose is front-loaded in the first sentence with the deliverables enumerated, and the warning markers make the hard constraints easy to find. The final rate-limit sentence is dense, packing three tiers into one clause, but it is still short and every sentence earns its place.

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 3-parameter tool at 100% schema coverage, with no output schema, the description does cover the substance: it lists the draft's components and it states the non-mutation and the rate-limit constraints. What is left unstated are the shape of the returned draft, how long a run takes, and how the url is used (its content is fetched but not written), which are minor residual 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?

Schema description coverage is 100%, so the schema already documents url, media (with its default of all three), and daily_budget_krw. The description only reinforces the budget parameter with the note that exactly the amount the user stated should be used. That is a useful guardrail, but it adds little syntax or format detail beyond the schema baseline.

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 gives a concrete verb (creates drafts) plus the resource (an OpenAI·Google·Meta ad campaign draft) and enumerates the deliverables it contains: budget allocation, core messaging, keyword/context hints, and ad copy. It does not distinguish itself from the sibling analyze_site, which it also implies by describing the url parameter as 'a site to analyze'.

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 usage signals are implied rather than explicit: 'only makes drafts' and 'creates nothing in the advertiser account' tell the agent what it should NOT expect from the tool, and the rate-limit sentence explains the calling constraints. It never says when to pick this tool over analyze_site or check_ad_readiness, nor whether a site must be analyzed first, so the agent still has to infer the workflow order.

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 does disclose one valuable behavioral trait — the call does not count against the daily limit — but says nothing about return format, ordering, or caching, leaving the rest of the behavior opaque.

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 no waste: the resource and its contents come first, followed by the quota-relevant note. Nothing is repeated from structured fields.

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-parameter, read-only list tool without an output schema, the description covers what is returned and one key constraint. A brief note on the shape or number of guide entries would make it fully 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to document and the description correctly implies a straightforward no-argument listing call.

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+resource: it returns a list of guides covering prerequisites and procedures for starting ads, with concrete examples (OpenAI, Google, Meta). It is distinguishable from siblings like get_plans or check_ad_readiness, though it doesn't explicitly name them.

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?

Usage is only implied by the 'prerequisites for starting ads' framing; there is no explicit statement of when to call this versus check_ad_readiness, draft_campaign, or get_plans. The agent must infer the routing decision itself.

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 and does disclose non-obvious behavior: the prices_confirmed flag semantics and that calls don't count against the daily quota. Missing are auth requirements and an explicit read-only statement, though 'returns' implies read.

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?

Four short sentences, each carrying distinct information: purpose, the risk flag, the required response behavior, and the quota exemption. The warning is front-loaded with a marker and nothing is padded.

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, so the description must convey the return shape; it names the two payload categories and the one flag that governs correctness. It stops short of describing plan fields (name, price, currency, billing period), which an agent formatting an answer would still want.

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?

Zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly spends no words on arguments.

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: returns pricing plans and payment methods. No sibling is named, but the sibling set (about_chatad, get_guides, draft_campaign) is far enough away that confusion is unlikely; the tool still doesn't positively distinguish itself.

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 clear handling instructions for the unconfirmed-price case (don't invent amounts, say 「확정 전」), which is real usage guidance for the response. It never says when to reach for this tool instead of about_chatad or get_guides, so the when-to-call decision is only implied.

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 exist, so the description carries the full load — and it does disclose the important behavior: what gets sent to the user per method, that the user must open a URL and approve, that approval is polled via check_signup, and that terms consent and identity verification are performed by the user, not the agent. It stops short of stating return payload shape or any auth/rate constraints, so not a 5.

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?

Front-loaded with purpose and the hard precondition, then cleanly branched by method with no filler sentences. It is longer than strictly minimal, but every clause carries operational meaning; only the closing consent sentence partially overlaps with the precondition.

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 mutation entry-point with no annotations and no output schema, the description covers the trigger condition, both branches, what the user sees, and where to go next. What an agent receives back (e.g., a status or handle) is only implied by the branch narratives rather than stated.

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 schema leaves the method enum undocumented, but the description supplies the meaning of both enum values and their distinct flows, which is exactly the gap-filling needed. email and client_name semantics live in the schema (67% coverage); client_name in particular is never echoed in the description, so the description does not fully compensate for the missing third.

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 ('ChatAd 가입을 시작한다') and immediately splits it into its two concrete modes (email_code, device), each with distinct downstream behavior. Naming complete_signup and check_signup as the follow-on tools makes it unambiguously distinct from those siblings.

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 an explicit, emphasized precondition ('🔴 사용자가 가입하겠다고 답한 뒤에만 부른다') and then routes per-method: email_code goes to complete_signup, device goes to check_signup. The agent knows both when to call it and which sibling to hand off to in each branch.

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