kakao-moment-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Most tools are distinct, but the performance report family overlaps: get_account_performance, get_campaign_performance, get_adgroup_performance, get_creative_performance can all be subsumed by get_performance_report, which also auto-enumerates entities. Additionally, session_status and get_token_info both expose token_user_id, creating some ambiguity.
Naming Consistency4/5
The naming is largely consistent with verb_noun (list_*, get_*, use_account). Notable deviations include get_performance_report (which inverts the entity-first pattern) and login/logout/use_account as standalone verbs, but these are natural exceptions and do not cause confusion.
Tool Count4/5
At 24 tools, this is slightly above the typical well-scoped range, but the coverage is broad across authentication, account management, campaign/adgroup/creative reads, and performance reports. The redundancy of get_performance_report with the level-specific performance tools slightly inflates the count but overall each tool has a legitimate use.
Completeness4/5
The tool set covers the full read/query lifecycle for campaigns, adgroups, creatives, and accounts, plus performance reporting at multiple levels. Missing are create/update/delete operations and get-single for audiences/cohorts/trackers, but the server appears designed as an insights/reporting tool, so these are acceptable minor gaps.
Average 3.5/5 across 24 of 24 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description adds the HTTP method and endpoint. However, it discloses no additional behavior such as pagination, default limits, or how optional filters affect results, so the description adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the resource and endpoint. It wastes no words, though it is slightly underspecified; still, for a simple list tool, the brevity is largely appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema, read-only annotation, and 100% schema coverage, the description is minimally viable for a straightforward listing operation. However, it lacks usage context or exclusions, making it incomplete for a new agent unfamiliar with the API's conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are documented in the input schema. The description itself mentions none of the parameters, but the schema fully compensates, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists creatives, with the endpoint GET /creatives confirming the resource. While it doesn't explicitly name sibling tools, the name 'list_creatives' and noun '소재 목록' clearly differentiate it from get_creative and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as get_creative for a single item or performance tools. The description offers no context about filtering or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already signals a safe read operation. The description adds only the endpoint and resource name, with no additional behavioral details such as authentication requirements or session fallback. This is minimal but does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that includes the resource and endpoint. It is efficient with no unnecessary words, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, read-only operation, output schema available), the sparse description is mostly sufficient. However, it omits any indication of what the user info contains or when to use it, but the output schema compensates. A score of 4 reflects near-adequacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% and includes a clear explanation of the optional business_token parameter (defaults to login session). The tool description itself adds no parameter information, aligning with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (business token user info) and includes the HTTP endpoint (GET /v1/business/userinfo), but lacks an explicit verb (e.g., 'retrieves'), making it less direct than ideal. It does distinguish from sibling 'get_token_info' by focusing on user info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives like get_token_info or login. The description does not mention session-based usage or fallback behavior; that information only appears in the parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds 'GET /adGroups' which is consistent with read-only behavior, but it provides no further behavioral details such as pagination, authentication requirements, or what data the list returns. No contradiction exists, but the description adds minimal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase that efficiently states the resource and HTTP method. It avoids redundant words and is appropriately sized for a simple list tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite full schema coverage and an output schema, the description is very sparse. It does not explain the scope of the list (e.g., whether it returns ad groups for a specific campaign or account), what the output contains, or how optional filters affect results. The description alone is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so all three parameters (campaign_id, ad_account_id, business_token) are already well-documented. The description itself adds no parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a list operation for ad groups ('광고그룹 목록') and includes the REST endpoint 'GET /adGroups'. This distinguishes it from sibling tools like get_adgroup, which fetches a single ad group. However, it does not explicitly differentiate from other list tools like list_campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention filtering, scoping, or that get_adgroup should be used for a single ad group. The context is implied by the name, but the description itself provides no explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds only the endpoint, which is a technical detail, but does not disclose any additional behavioral traits such as pagination, default limits, or required authentication beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no wasted words. It gets straight to the point, though it is quite sparse and could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no required parameters and includes an output schema, which reduces the need to describe return values. However, the description is minimal and does not explain what cohorts are used for or how this tool fits among many sibling list tools, making it incomplete for an agent to distinguish usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both ad_account_id and business_token are described). The tool description itself mentions no parameters, so it adds no value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists '광고반응타겟(cohort)' (ad response targets/cohorts) and provides the endpoint. This clearly identifies the resource and action, though it does not explicitly distinguish from similar list tools like list_audiences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_audiences. The description only states what it lists, with no context on filtering, scoping, or when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already signals a safe read operation. The description adds only the HTTP method GET, which restates the read-only nature without providing additional behavioral context such as pagination, scoping, or token requirements. It does not contradict the annotation but contributes no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase plus endpoint, extremely concise and free of unnecessary words. It is front-loaded and perfectly sized for a minimal list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple list operation, the read-only annotation, and a complete output schema, the description is minimally adequate. However, it omits context about the scope of the list (e.g., all audiences vs. account-specific) and any special behavior. The output schema compensates for return format but the description remains thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (ad_account_id and business_token) having clear descriptions of session fallback and override behavior. The description itself does not add any parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '오디언스 목록' (audience list) and the REST endpoint GET /targetings/audiences, making it clear this tool lists audiences. It is specific about the resource but does not explicitly distinguish itself from sibling list tools (e.g., list_campaigns) beyond naming the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. There is no mention of use cases, prerequisites, or exclusions relative to sibling list tools like list_ad_accounts or list_cohorts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, and the description only repeats the read-only nature ('list') plus the HTTP method. It adds no additional behavioral context such as session dependencies, pagination, or whether it returns all campaigns or requires an ad account. The HTTP path is useful but not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single phrase with the HTTP endpoint in parentheses. Every word earns its place, and the structure is clean. It sacrifices detail but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters and an output schema, the description is too sparse to be fully complete. It does not mention the scope (e.g., ad account) or filtering options, even though the schema covers them. The presence of an output schema reduces the need to explain return values, but the description still lacks a high-level explanation of behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already well-documented in the schema. The description itself adds no parameter-level detail, which aligns with the baseline of 3 when the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('캠페인 목록' = list campaigns) and the resource (campaigns), backed by the HTTP endpoint GET /campaigns. This distinguishes it from siblings like get_campaign, which retrieves a single campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of listing all campaigns for an account, filtering, or when to prefer get_campaign. The name implies usage but the description offers no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers the safety profile, and the description does not contradict it. However, it adds no behavioral context beyond the annotation—no pagination, return format, or authentication nuances. The endpoint is useful but not a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, making it concise and front-loaded. It is extremely minimal but effective for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, the presence of an output schema, and complete parameter descriptions, the description plus structured data is sufficient. The description is minimal but not misleading, and it identifies the resource being listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage), so the description does not need to add parameter-level details. It correctly leaves semantics to the schema, which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists KakaoTalk channel profiles, with a specific verb ('list') and resource ('channel profiles') and the underlying GET endpoint. It distinguishes itself from sibling tools by resource type, though it doesn't elaborate further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description is purely declarative, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds the behavioral note that an ID is not required (presumably using the session account). This is useful context beyond the annotation, but it is minimal and does not provide deeper behavioral details like response format or side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and the endpoint provides a useful reference. It is appropriately sized, though it could include a brief usage note without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 optional parameters, an output schema, and similar sibling tools, the description is sparse. The structured schema and output schema carry much of the burden, but the description fails to clarify how this tool differs from get_performance_report or when to choose account-level performance over campaign/adgroup levels. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is already met. The description's 'ID 불필요' is redundant with the schema's ad_account_id description, which already states the session fallback. No additional parameter meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an ad account performance report and includes the endpoint (GET /adAccounts/report). It uses a specific verb+resource combination. However, it does not explicitly differentiate itself from sibling report tools like get_performance_report or get_campaign_performance, which limits full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives. The note 'ID 불필요' (ID not needed) hints that the tool can operate with the session account, but it does not explain selection criteria among the many sibling performance report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that if adGroupId is not specified, ad groups are automatically enumerated, which is a useful behavioral trait beyond the readOnlyHint annotation. However, this is presented in a confusing, self-contradictory way ('adGroupId 필수' followed by '미지정 시...'), diminishing its clarity. No other behavioral details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence containing the core purpose and endpoint, which is appropriately concise. It is front-loaded with the tool's function. However, the contradictory phrasing reduces its impact, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and an output schema, the description is very sparse. It does not clarify how parameters interact (like adgroup_ids vs campaign_id), nor does it resolve the adGroupId ambiguity. While the schema covers parameter details, the description fails to provide a coherent overview, leaving the agent with a misleading 'required' signal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for all 10 parameters, so the baseline is 3. The description, however, uses 'adGroupId' which is not a parameter name (the schema has 'adgroup_ids' as optional), and says it is required while the schema marks it optional. This introduces confusion and adds no meaningful semantics beyond the schema, arguably making it worse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '광고그룹별 성과 리포트' (ad group performance report) with the endpoint GET /adGroups/report, using a specific verb and resource. It distinguishes itself from sibling performance tools (e.g., account/campaign/creative performance) by explicitly targeting ad groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions or conditions, leaving the agent to infer from the tool name alone. The only behavioral note is about adGroupId enumeration, which is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a read-only operation. The description adds a useful behavioral trait: '하위 레벨은 계정 내 전체 엔티티를 자동 열거' (lower levels automatically enumerate all entities), which implies potentially large result sets. However, it does not disclose other behaviors such as pagination, response size limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. The first and third sentences convey useful scope and behavior, but the second sentence ('인사이트 도출용 1급 툴') is somewhat subjective and adds little operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, output schema present), the description omits key contextual details: when to choose this integrated report over level-specific siblings, and how the 'level' parameter interacts with the auto-enumeration behavior. It is adequate but leaves gaps for a tool with this many parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 9 parameters (100% coverage), so the description does not need to explain each one. It does not add parameter-specific meaning beyond the general '레벨 지정' hint, which maps to the 'level' parameter. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a level-specified integrated performance report ('레벨 지정 통합 성과 리포트'), with a distinct mention of auto-enumerating all lower-level entities. It is specific about the resource and action, though it does not explicitly distinguish itself from sibling get_*_performance tools beyond the 'integrated' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the sibling performance tools (e.g., get_account_performance, get_campaign_performance). The phrase '인사이트 도출용 1급 툴' vaguely implies a high-level analytical use case, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation. The description adds the HTTP GET method and that it returns details for a single creative, which is consistent but not deeply informative. No additional behavioral context such as error behavior or auth requirements is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant text. It includes both the resource and the endpoint, and every word is functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-resource getter with an output schema and read-only annotation, the minimal description is adequate but lacks usage context and differentiation from sibling tools. It does not mention session/token selection nuances beyond the schema, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no extra parameter meaning beyond what is already in the schema, yielding the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '단일 소재 상세' clearly indicates a single creative's detail view, and the REST endpoint 'GET /creatives/{id}' reinforces that it retrieves one creative. However, it doesn't explicitly contrast with sibling tools like list_creatives or get_creative_performance, so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool instead of alternatives. The description only states the endpoint and does not mention scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds '실시간' (real-time) and the GET endpoint, which implies a read operation, but doesn't disclose any additional behavioral traits such as rate limits, caching, or permission requirements. It neither contradicts nor significantly enriches the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and endpoint without unnecessary words. Every phrase earns its place, and it avoids verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters and an output schema, the description is adequate. It clearly states what the tool does, and the schema and annotations fill in the rest. However, it doesn't explain return format or when to use it, which slightly lowers completeness, but the output schema covers return expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (ad_account_id, business_token) having a clear description. The tool description itself adds no parameter-specific details beyond what the schema already provides, so it meets the baseline of 3 given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the real-time balance of an ad account, and includes the HTTP endpoint. It specifies the resource (광고계정) and operation (잔액 조회), distinguishing it from sibling tools like performance or campaign retrieval. However, it lacks an explicit verb like 'retrieve' and doesn't differentiate from all possible siblings, though the balance concept is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention whether it's for ad account-level queries, session requirements, or when a user might need to override tokens. Sibling tools like get_account or get_account_performance exist, but no selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already declares the read-only nature, so the description's addition of the HTTP method (GET) is consistent but not extra behavioral insight. The description does not disclose any additional traits such as session fallback behavior or potential errors, but given the annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Korean, front-loading the resource and endpoint. No extraneous words or repetition; it earns every character it uses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get tool with an output schema and only two optional parameters, the description adequately states the core purpose. It does not explain session fallback or ID resolution, but those are covered in the schema. The output schema exists, so return value details are not needed in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (ad_account_id and business_token), so the schema fully explains their meaning and defaults. The description adds no further parameter semantics, which is acceptable since the baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '광고계정 상세' (ad account details) and explicitly provides the GET /adAccounts/{adAccountId} endpoint, making it clear this tool retrieves a single ad account's details. It is distinct from list_ad_accounts (which lists accounts) and other sibling tools, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention list_ad_accounts or any prerequisites (e.g., session required, when to specify ad_account_id vs rely on use_account). The description is purely declarative without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the GET method and resource path, reinforcing a safe read operation. However, it does not disclose error behavior, auth requirements, or any other traits beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence containing only the essential purpose and endpoint. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-resource getter with full schema coverage and an output schema present, the description is adequate. It lacks usage alternatives, but the low complexity and rich structured metadata compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter meanings are fully documented in the schema. The description adds no additional parameter semantics beyond the path hint in the endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '단일 광고그룹 상세 (GET /adGroups/{id})' clearly states the tool fetches details for a single ad group and includes the HTTP endpoint. It distinguishes itself from list_adgroups by emphasizing '단일' (single), but does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus list_adgroups or get_adgroup_performance. It only states what it does, leaving the selection decision entirely to the agent without any comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety; the description adds that it returns the token's owner and accessible ad accounts and specifies the GET endpoint. It does not detail error cases, rate limits, or auth requirements, but with the annotation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that front-loads the key outputs and endpoint with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, an output schema, and a read-only annotation, the description sufficiently covers the essential behavior. However, it lacks usage selection guidance, which is already captured in the usage dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'business_token' with a clear description of default behavior and purpose. The tool description adds no parameter details, but schema coverage is 100%, so no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves business token ownership ('token_user_id') and accessible ad accounts, backed by the specific endpoint. This distinguishes it from sibling tools like get_user_info and list_ad_accounts by focusing on token-level info, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply describes the function without any exclusions, prerequisites, or context for selection, leaving the agent to infer usage from the action alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds meaningful behavioral context beyond the annotation by disclosing the HTTP GET method and the auto-enumeration behavior when campaign IDs are omitted. It is consistent with the annotation and adds useful operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is front-loaded with the tool's purpose and endpoint. The contradictory '필수 — 미지정 시' structure makes it logically incoherent, and the reference to a non-existent parameter harms clarity despite the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 9-parameter tool with a rich schema and output schema, but the description is minimal and does not explain how to distinguish it from get_performance_report. It also fails to resolve the campaignId/campaign_ids discrepancy, leaving the agent under-informed for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with detailed descriptions, so the baseline is 3. However, the description introduces 'campaignId' which does not exist in the schema (the actual field is campaign_ids) and claims it is required while the schema marks it optional. It adds no new semantic value and actually misleads by contradicting the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '캠페인별 성과 리포트' (campaign performance report) and the endpoint GET /campaigns/report, making the verb and resource explicit. This clearly distinguishes the tool from sibling performance tools such as get_account_performance, get_adgroup_performance, and get_creative_performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context by saying campaignId is required and that unspecified IDs cause automatic enumeration of all account campaigns. However, this is contradictory (required vs. omitted) and the description does not reference alternatives like get_performance_report or explain when this tool should be preferred over the generic report tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already indicating a safe read, the description adds useful behavioral context: if creative_ids is not supplied, the tool automatically enumerates creatives (optionally scoped by adgroup_id). This goes beyond the annotation. It does not cover pagination or response shape, but the output schema exists to cover return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the main purpose and endpoint. However, the phrase 'creativeId 필수' is slightly confusing and could have been phrased more clearly to avoid implying a parameter that does not exist in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and rich schema descriptions, the description provides only minimal context on auto-enumeration. It doesn't clarify the relationship between creative_ids and adgroup_id, or how to choose among the multiple sibling performance report tools. The output schema covers return values, but the overall description is just enough to be functional, not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a meaningful description, so the baseline is 3. The tool description adds a note about creative_id being required or auto-enumerated, but it uses a different singular name ('creativeId') than the actual 'creative_ids' parameter, and it doesn't add meaning about other parameters like dimension or metrics_group.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a per-creative performance report with the exact endpoint (GET /creatives/report), distinguishing it from sibling performance tools (e.g., get_campaign_performance, get_adgroup_performance). However, it refers to 'creativeId 필수' while the actual schema parameter is 'creative_ids' and no parameter is required, creating slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creative-level performance reporting and explains the auto-enumeration behavior when creative_ids are omitted. However, it does not explicitly state when to use this tool versus alternatives like get_performance_report or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds the GET HTTP method, which is consistent. However, it does not disclose any additional behavioral traits such as scoping by ad account or session usage, though the schema covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys the tool's purpose and endpoint. No wasted words; it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with readOnly annotation, 100% schema coverage, and an output schema, the description is reasonably complete. It states the resource and endpoint. It could be improved by explicitly mentioning that it returns all trackers or how the ad_account_id parameter scopes the result, but the schema covers parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—both parameters have descriptions in the input schema. The description itself does not add any parameter details, so it relies on the schema. Baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists pixels and SDKs (trackers) and provides the HTTP endpoint (GET /adAccounts/trackers). This specific resource name distinguishes it from sibling list tools like list_campaigns or list_creatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only provides the resource name and endpoint, leaving the agent to infer usage from the tool name. There are no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It states that the tool clears session login/account info, but it does not disclose side effects (e.g., invalidation of tokens), irreversibility, or any impact on ongoing operations. The description adds minimal context beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's function. Every word contributes meaning without unnecessary verbosity, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description is mostly complete. It captures the core action of logging out. However, it slightly under-specifies potential edge behaviors like whether the logout is idempotent or returns any confirmation, but these are not critical for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which corresponds to a baseline score of 4 per the rubric. The description doesn't need to explain parameter semantics because there are none. The empty schema fully covers this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '지운다' (clears) and identifies the resource as '세션의 로그인/계정 정보' (the session's login/account information). This clearly distinguishes it from sibling tools like 'login' and 'session_status', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or mention alternatives. However, given the sibling context (login, session_status), the intended usage is fairly obvious: use it to end a session. This is implied rather than directly stated, so it only partially meets the guidance criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation. The description adds the HTTP GET method, which aligns with the annotation but doesn't disclose additional behavioral traits such as authorization requirements, rate limits, or side effects. With annotations covering safety, the description provides minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core purpose and endpoint. No unnecessary words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and 100% schema coverage for inputs, the description is sufficient for a simple single-resource retrieval tool. It provides necessary context without redundancy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters, including defaults and fallback behavior (e.g., session token usage). The description itself does not add parameter-level information, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '단일 캠페인 상세' (single campaign details) along with the HTTP endpoint GET /campaigns/{id}, making it unambiguous that this tool retrieves a single campaign. This distinguishes it from sibling list_campaigns and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like list_campaigns. The usage is implied by the name and the 'single' qualifier, but there is no mention of when not to use it or any alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the primary behavior (setting a session-level default) but does not mention potential side effects, error conditions, whether authentication is required, or how the session state is managed. The description is not misleading, but it is minimally informative beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise Korean sentence: '이후 조회의 기본 대상 광고계정을 세션에 설정.' It is front-loaded with the action and resource, and every word contributes meaning. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter tool with an output schema, the description is adequately complete. It explains the session context and the effect on subsequent lookups. It does not elaborate on session lifecycle details, but given the tool's simplicity and the presence of sibling session management tools, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter ad_account_id has a description '이후 조회에 사용할 광고계정 ID' that fully explains its meaning. The tool description adds no new detail about the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting the default advertising account for subsequent lookups in the session. The verb '설정' (set) and resource '기본 대상 광고계정' (default target ad account) are specific, and the context '세션' (session) distinguishes it from account listing or retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage context: it should be called before performing lookups that need an account context. It clearly states the effect on subsequent queries, providing clear context. However, it does not explicitly mention exclusions or alternatives, though none are clearly needed given its unique role among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It discloses key behavioral traits: token verification via tokeninfo and storage in the server session, and the effect on subsequent calls. It does not mention failure modes or session expiration, but the core side effects are transparent enough for a login tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with a dash to separate the main action from its consequence. Every phrase adds value: what it does, how it does it, and the follow-up effect. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description does not need to explain return values. It thoroughly explains the process and the resulting session state, which is sufficient for the agent to use the tool correctly in a typical flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description 'issued business token' is clear. The tool description adds a bit of context by saying 'Login with business token,' but it does not provide additional semantic meaning beyond the schema. The baseline of 3 applies since the schema already documents the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Login with business token' and the resource (business token). It specifies the process: verify through tokeninfo and store in server session. This distinguishes it from siblings like logout and use_account, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that after login, subsequent tools are called without a token argument, implying login should be done before other calls. It does not explicitly mention when not to use it or alternatives, but the sequencing guidance is strong enough for the agent to decide when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that it calls GET /adAccounts/pages and iterates through all pages ('전 페이지 순회'). This adds meaningful behavioral context about pagination and intended scope, which is not present in the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with bold emphasis on '전체' (ALL) and includes the endpoint and pagination behavior. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema, the description covers the essential aspects: what is listed, the access scope, the endpoint, and the pagination behavior. The output schema handles return value details, so no further elaboration is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%: the only parameter, business_token, is fully described in the schema (defaults to login session if omitted, for override). The tool description adds no additional parameter information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('list') and the resource ('ad accounts'), and emphasizes '전체' (ALL) to indicate the full scope. This distinguishes it from sibling tools like get_ad_account, which retrieves a single account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool lists all token-accessible ad accounts, implying use when a complete list is needed. However, it does not explicitly mention alternatives or exclusions, such as 'use get_ad_account for a single account', so it lacks a direct when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds meaningful behavioral details: it explains the two possible authentication paths (OAuth login-on-connect vs. session storage) and states that token values are not exposed. This goes beyond what annotations provide and gives the agent a clear picture of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose. The first sentence states the essential output; the second explains the authentication source logic. Every word earns its place, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, read-only annotation, output schema present), the description fully covers purpose, behavior, and edge conditions (token exposure, OAuth vs. session). It is a complete explanation for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description doesn't need to explain parameter semantics, and it doesn't; it focuses on behavior and return context, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports current authentication status (login status, token_user_id, selected account), which is specific and distinguishable from sibling tools like get_user_info or list_ad_accounts. It also explicitly notes that token values are not exposed, adding clarity about what the tool does not return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear behavioral context on when it checks OAuth token context vs. session storage, which helps the agent understand its operation in different authentication modes. It doesn't explicitly name alternatives or exclusion conditions, but the context is sufficient for basic usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kakao-moment-mcp MCP server](https://glama.ai/mcp/servers/PlatAid/kakao-moment-mcp/badges/card.svg)](https://glama.ai/mcp/servers/PlatAid/kakao-moment-mcp)

Score Badge

Copy to your README.md:

[![kakao-moment-mcp MCP server](https://glama.ai/mcp/servers/PlatAid/kakao-moment-mcp/badges/score.svg)](https://glama.ai/mcp/servers/PlatAid/kakao-moment-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PlatAid/kakao-moment-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server