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

No annotations are provided, so the description carries the transparency burden. It discloses that this is read-only and that descriptions, attendees, and external directives are stripped from results. This adds meaningful behavioral context, though it doesn't elaborate on the 31-day range outcome (e.g., what happens if the range exceeds it) or the return format. Moderate but acceptable given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise Korean sentence that packs the read-only nature, 31-day scope, and data stripping behavior with minimal waste. It earns points for being front-loaded and efficient, though it is arguably under-specified rather than over-long.

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 moderately complex with 3 parameters, no output schema, and no annotations. The description covers the read-only and data-stripping aspects but leaves the parameter semantics, return value shape, and differentiation from sibling calendar tools unaddressed. For a tool with no output schema and 0% schema coverage, this is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all 3 parameters. It does not explain the format or meaning of fromDateTime/untilDateTime beyond what the schema patterns imply, nor does it clarify the optional userId parameter (whose calendar? defaulting behavior). The 31-day limit is mentioned but not tied to the date parameters explicitly. This is a significant gap for a 0%-coverage schema.

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+scope: '조회합니다' (retrieves) default calendar events within a max 31-day range. It's clear in purpose. However, it doesn't explicitly distinguish itself from the sibling 'works_calendar_events_list' tool, which could be its general counterpart, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the read-only nature and the 31-day constraint, giving some usage context (read-only query). However, there is no explicit guidance on when to use this vs the sibling 'works_calendar_events_list' or 'works_calendar_personals_list', nor any mention of prerequisites. Usage context is implied but not explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that original text (descriptions, attendees) is not returned, which is useful. However, it doesn't disclose whether this is read-only, what happens if userId is invalid/absent, response format, or auth/permission requirements. Since userId is not required (0 required params), it's unclear what happens without it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence plus a clarifying exclusion clause. Both sentences earn their place—the first states the purpose, the second clarifies limitations. No fluff, though it could be slightly more informative within its brevity.

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, no output schema, only 1 param (0 required), and 0% schema coverage, the description should do significantly more. It clarifies what's NOT returned but doesn't state what IS returned, whether userId is optional, error behavior, or how this relates to sibling calendar tools. For a read-type query tool, critical behavioral gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and there is only one parameter (userId) with a minLength=1 constraint but no description. The tool description mentions '구성원' (member) implying userId refers to a member, but it doesn't explain what values are valid (email, internal id, etc.) or whether the parameter is optional despite being schematically not required. The description adds little meaning beyond the schema.

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 it queries a member's default calendar properties and clarifies it does not return original text like event descriptions or attendees. The verb '조회' (query/inquire) plus '기본 캘린더 속성' (default calendar properties) specifies the resource clearly. It doesn't explicitly differentiate from sibling tools, though the title implies a default-calendar scope distinct from the personal/events list 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?

No explicit guidance on when to use this tool vs alternatives. It doesn't mention whether this is called before creating events, paired with events-list tools, or what prerequisite context is needed. The description only clarifies what it does NOT return, but gives no when-to-use or when-not-to-use instructions relative to the sibling calendar and directory tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions a 31-day limit, but does not state pagination behavior, session/permission requirements, whether results are sorted, what happens when the range exceeds 31 days (error vs truncation), or the return format. For a read tool with zero annotation coverage, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, clean sentence in Korean that front-loads the core action and scoping. It is appropriately succinct without wasted words, though it could add a reference to sibling alternatives without becoming verbose.

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, no output schema, 0% parameter coverage, and 4 undocumented parameters, the description is far from complete. It doesn't clarify the 31-day boundary behavior, the relationship to default/personal calendar listing siblings, or the purpose of userId. For a calendar-list tool with multiple related siblings, this is inadequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all 4 parameters. However, it only references calendarId implicitly (via 'calendarId가 명시된'). fromDateTime, untilDateTime, and userId semantics are entirely unexplained—including the ISO8601 format, the relationship between from/until, and whether userId is required for cross-user access.

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?

Description states the verb (조회/list), resource (calendar events), and a key scoping constraint (calendarId가 명시된 캘린더, explicit calendar). The '최대 31일 범위' adds a meaningful boundary. However, it doesn't distinguish itself from the sibling tool works_calendar_default_events_list, which likely serves a similar purpose for default calendars.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for calendars with an explicit calendarId (contrasting with 'default' calendar tools among siblings), but provides no explicit when/when-not guidance or named alternatives. The 31-day max range is a useful constraint but no filtering semantics or exclusions are described.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description discloses cursor-based pagination but omits critical behaviors: whether the 'personal attributes' returned are read-only, what each page returns, whether results include the current user's calendar plus those shared with them, and whether this is a safe read operation. For a list endpoint with no annotations, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that uses efficient Korean phrasing. It front-loads the purpose and includes the pagination mechanism. It's economical, though it could add a second sentence for behavioral/usage context without becoming verbose.

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 provide completeness, but it falls short. The term 'personal attributes' (개인 속성) is ambiguous, the tool has 3 parameters at 0% schema coverage, and siblings like works_calendar_default_properties need differentiation. For a 3-parameter list tool with zero structured metadata support, this description is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the three parameters (count, cursor, userId). It mentions 'cursor' concept generally but does not explain what userId controls (likely filtering to a specific user's calendars), how count interplays with pagination, or the meaning of the cursor parameter beyond vague 'cursor-based' mention. The description adds only marginal value over the schema.

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 the tool lists personal attributes of accessible calendars using cursor-based pagination. However, 'personal properties' is vague - it doesn't specify WHAT personal attributes are returned (e.g., sharing settings, ownership, color, notifications). It distinguishes from event-focused siblings (events_list) but not clearly from default_properties sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. The title says 'personal calendar list' and mentions cursor-based pagination, which implies a listing use case, but there's no explicit statement of when to choose this over works_calendar_default_properties or why 'personals' differ from 'defaults'.

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. It discloses that output is minimal and masking occurs, which is useful behavioral context. However, it doesn't disclose pagination behavior, result ordering defaults, or what happens with invalid queries/missing matches.

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?

Single concise sentence that packs useful information about scope, masking, and exclusions. No wasted words, though it could arguably be a bit longer to cover parameter semantics.

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?

A 6-parameter search tool with 0% schema coverage, no annotations, and no output schema. The description is too thin: it doesn't explain query semantics, pagination, filtering, ordering behavior, or the output shape. For a complex search tool, significantly more behavioral documentation is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all 6 parameters. It fails to do so — none of the parameters (query, count, cursor, userId, orderBy, queryFilters) are explained beyond the schema. The description adds no meaning about the query format, filter syntax, or cursor semantics.

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?

Description clearly states the tool searches contacts and returns only minimal fields with masked email/phone, excluding memo/address/custom properties. The verb+resource is clear and it distinguishes from directory tools, though it doesn't 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for searching contacts when minimal/masked data suffices, and signals that richer fields (memo, address, custom attributes) are excluded. However, it doesn't explicitly state when to prefer this over alternatives like works_directory_users_list or provide when-not-to-use guidance.

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, so the description carries the disclosure burden. The main behavioral disclosure is that userId=me is blocked for Service Accounts, which is valuable. However, it doesn't state whether this is a read-only operation, potential failure modes (e.g., unauthorized users, unknown IDs), or response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tight sentence plus a short constraint clause. It's efficient with no filler. Slightly more detail would be acceptable, but the current wording is appropriately compact.

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, no output schema, and a single opaque parameter, the description must carry more weight. It fails to mention what fields the minimal profile returns, prereducuate requirements (auth level), or error behavior. For a single-parameter lookup tool this is on the thinner side, though the 'already known userId' framing helps scope it.

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 has a single self-explanatory parameter (userId) with 0% schema description coverage. The description reinforces that the ID must be 'already known' and that 'me' is invalid for Service Accounts, which adds slight meaning beyond the bare schema. But the schema itself is minimal, so the description does not heavily enrich parameter semantics.

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 queries a user's minimal profile using a known userId. It's reasonably clear, though differentiating from sibling tools like works_directory_users_list or works_contact_search_minimal is not addressed, so it doesn't fully 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?

The description notes a precondition ('already know the userId') and an exclusion (blocks userId=me for Service Account), which is useful guidance. However, it doesn't clarify when to use this minimal-profile tool vs a full-profile or user-list alternative among siblings.

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 zero annotations provided, the description carries full burden for behavioral disclosure. It does disclose that sensitive fields (email, phone, birth date) are NOT returned, which is useful. However, it doesn't convey rate limits, pagination behavior specifics (page size defaults, cursor exhaustion), or what the 'minimal fields' actually are. For a multi-user data access tool, this is thin behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that conveys the core purpose and the notable security constraint. It's front-loaded with the main action. However, it's arguably under-specified rather than efficiently complete — every word earns its place but there's simply not enough content given the tool's complexity.

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 tool with 6 parameters (including an undocumented searchFilterType with a 'VIP' const), 0% schema coverage, no annotations, and no output schema, this description is substantially incomplete. While it's a data retrieval operation (less risky than mutation), the agent will struggle to know what 'minimal fields' contains, what VIP filtering means, how cursor pagination flows, and what the output shape is.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for documenting 6 parameters. The description mentions cursor-based pagination (covering 'cursor') and sensitive field exclusion, but explains nothing about searchFilterType (VIP filter semantics), domainId, orderBy, sortOrder, or count. The description adds minimal value beyond what parameter names alone convey.

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 it lists members with cursor-based pagination and explicitly omits sensitive fields. However, it doesn't clearly distinguish what this 'minimal field list' means compared to sibling tools beyond the mention of sensitive field exclusion. The verb '조회' (query/retrieve) plus '구성원 목록' (member list) and '커서 기반' (cursor-based) gives reasonable purpose clarity, but lacks differentiation from the sibling list/contact 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?

There's no guidance on when to use this tool versus alternatives like works_contact_search_minimal or works_directory_user_profile_get. The description implies it's for batch member listing where sensitive fields aren't needed, but says nothing about when the cursor parameter should be used, what searchFilterType='VIP' means, or when to prefer a different tool.

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 of behavioral disclosure. It states no secrets are used and checks configuration aspects, implying a safe read-only operation, but does not describe output format, response shape, or any edge-case 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?

A single Korean sentence efficiently lists exactly what configuration aspects are verified and explicitly notes no secrets are involved. No wasted words or 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?

For a zero-parameter health check with a clear scope of what it reports, the description is reasonably complete. It does not mention output format, but with no output schema and a well-scoped purpose, the description covers the essential expectations adequately.

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 has zero parameters, which the input schema already makes clear. Per the rubric, 0 params = baseline 4, and the description adds context about what information (server version, auth mode, scope policy) is being surfaced, which helps the agent know what to expect.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks server version, MCP transport statelessness, auth mode, and scope policy. This distinguishes it from sibling tools which are all resource-specific (profile, calendar, contacts) — a health/status check is clearly differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is a diagnostic/status tool to verify server configuration without secrets, which gives some context for when to use it. However, it does not explicitly state when-not to use it or name alternatives, relying on the distinct health-related purpose.

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