ClusterHack

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

The description goes well beyond the readOnlyHint annotation by disclosing that the tool makes no API call, cannot fail, and is deliberately gated so that connected AI clients are refused access. It even explains the security rationale for this gating. This is exactly the kind of behavioral context an agent needs to avoid misusing the tool.

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

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

The description is front-loaded with the core purpose, then adds behavioral and security context in a logical order. Every sentence earns its place, including the rationale for why this tool exists and why it does not make an API call. It is longer than average, but the length is justified for such an unusual informational tool.

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 informational tool, the description is complete: it states what the user will see, what actions they can take, access restrictions, the fact that no API call is made, and where related capabilities live. Since there is no output schema, the description adequately covers the expected outcome.

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

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

The input schema is empty with 100% schema description coverage, so there are no parameter semantics to document. The description appropriately stays silent on parameters and instead clarifies the tool's no-op nature, which is the only relevant semantic here.

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 immediately states the tool's verb and resource: it tells the signed-in user how to see and revoke AI access to their own account. It also explicitly distinguishes itself from any hypothetical 'lists or cuts off connected clients' tool, which the agent is told does not exist. This makes the tool's role unmistakable.

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 gives explicit when-to-use guidance: read this instead of searching for a tool that manages connected clients, because no such tool exists. It also notes that account deletion deliberately has no tool and that data export is handled by 'account_export_data', routing the agent away from wrong alternatives.

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?

Beyond the readOnlyHint annotation, the description adds meaningful behavioral context: the tool performs no credential handling, never sees passwords, uses a browser-based OAuth flow, and works with no account at all. These details prevent dangerous or confusing invocation attempts and are not present in the structured 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 front-loaded with the core message and then provides necessary explanatory context about why a login/registration tool is absent. It is longer than minimal, but every sentence earns its place by preventing misinterpretation and clarifying the authentication model.

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, read-only informational tool, the description is fully complete: it states what the tool does, when to use it, why it exists, what it does not do, and how the underlying authentication works. An agent has everything needed to invoke it correctly.

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

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

The input schema has zero parameters, which is already complete. The description reinforces that the tool requires no account and takes no arguments, adding no conflicting information. With no parameters to document, this is the appropriate baseline score.

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 clear purpose: it explains how to connect an account to this MCP server. It explicitly distinguishes itself from a login/registration tool by stating that no such MCP tool exists, making its role unmistakable even among many sibling 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?

It gives direct usage guidance: read this instead of guessing at a login/registration tool, because there isn't one. It also explains the authentication model (OAuth 2.1 browser flow) and clarifies that the tool works without any prior account, so an agent knows exactly when to invoke it.

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?

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful return-field context, including the hidden flag and language association, but does not disclose error behavior or other operational traits. This is adequate but not rich.

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 sentence, front-loaded with the key action and resource, with no filler. The trailing phrase 'which title/slug and language it belongs to' is slightly awkward but still economical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool, the description is sufficiently complete: it specifies the input by id and enumerates the expected output fields. It stops short of describing not-found behavior or explicit sibling differentiation, but those are not critical for this low-complexity tool.

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

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

Schema coverage is 100% and the only parameter, article_id, is already described in the schema as 'The article's id.' The description's 'by id' adds no meaningful semantics beyond that, so the baseline of 3 applies.

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

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

States a specific verb ('Retrieve'), a precise resource ('one CMS article by id'), and enumerates the returned fields (body, publish date, hidden flag, title/slug, language). This clearly distinguishes it from siblings like article_list, article_titles, and article_languages.

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 clearly implies when to use the tool: when a single article is needed by its id. It does not explicitly name alternatives or exclusions, but the 'by id' scope is an unambiguous usage condition.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by showing a sample return entry and explaining that the output supports article_create, which goes beyond the structured 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 compact and front-loaded. The first sentence states the purpose, the inline example conveys the return shape, and the second sentence explains the practical use case without unnecessary filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with no required params and no output schema, the description covers the essential return shape and the downstream use case. The only minor gap is that the example omits an explicit language_id field, though the description names language_id in prose.

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

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

The input schema already provides 100% coverage for the two parameters, page and page_size, with clear descriptions. The tool description does not add parameter-specific semantics beyond what the schema already states, so the baseline 3 is appropriate.

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 uses a specific verb and resource: 'List the languages articles can be written in', which clearly identifies what the tool does. It does not explicitly distinguish itself from sibling tools like article_titles, but the resource 'languages' is unambiguous enough.

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 gives a clear use case: 'Use this to find the language_id article_create needs.' This tells the agent when to call the tool, though it does not mention alternatives or when not to use it.

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?

Beyond the readOnlyHint annotation, the description reveals a key behavioral nuance: hidden drafts are only included for staff callers, while public callers see only published articles. This role-dependent visibility is not captured in annotations and adds meaningful context for expected results.

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 three sentences long, front-loads the core action and URL structure, then details filters and access rules. Every sentence carries information without redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with four optional parameters and no output schema, the description covers the essential purpose, filtering semantics, and a critical visibility rule. It does not mention response structure or pagination, but those are either implicit in a list endpoint or already encoded in the schema defaults and bounds.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how slug and language combine to 'find one specific page's translations', framing the parameters as a pair rather than just individual filters. It also reinforces the language code and slug examples from the schema, giving an agent a clearer mental model of their combined usage.

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's purpose: browsing CMS articles under a specific URL pattern, with filtering by language and slug. The verb 'browse' plus the URL structure and filter details make it unambiguous, and it is implicitly distinguished from siblings like article_get by focusing on listing translations rather than fetching a single article.

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

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

The description provides clear context for when to use this tool: to browse or filter articles, especially to find translations of a specific page via language/slug. It does not explicitly name alternatives or exclusions, but the use case is well-defined enough for an agent to decide between this and sibling tools like article_get or article_titles.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context beyond that by showing the item shape and explaining the relationship between titles and articles. It does not discuss pagination or response envelopes, but the schema covers the pagination parameters and the description covers the data 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 compact and front-loaded with the core action. The example JSON is valuable and the closing sentence provides practical usage context without unnecessary filler. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only listing tool with fully documented optional pagination parameters, the description is complete. It explains what the tool returns, gives an example item, and states why an agent would call it. No critical detail is missing.

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

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

Schema description coverage is 100%, with page and page_size fully documented in the input schema. The description does not add any extra meaning beyond what the schema already provides, 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.

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

The description opens with a specific verb and resource: "List the CMS 'title' records" and clarifies what each record contains with an example. It also differentiates the tool from siblings like article_list by explaining that an article points at a title record, making the resource unique.

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 gives clear use cases: "use this to find the `title_id` `article_create` needs, or to see what pages exist at all." It does not explicitly mention when to prefer sibling tools like article_list, but the stated purposes are sufficiently clear context for an agent.

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?

Annotations already mark the tool read-only and non-destructive, so the description's extra value is meaningful: it discloses the 10,000-character limit and the important `found: false` behavior when no about-us page exists. This helps an agent handle missing data correctly and goes well beyond the structured 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 two tight sentences, front-loaded with the resource definition and followed by scope and edge-case behavior. Every clause earns its place, with no repetition of the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, single-parameter read tool with strong annotations, the description is nearly complete. It covers the return value, length constraint, and missing-data behavior, though without an output schema it could slightly more explicitly state the success return type, but the wording makes it sufficiently clear.

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 already documents the single `company_id` parameter with 100% coverage. The description adds no new parameter-specific meaning, so the baseline of 3 applies.

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

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

The description clearly identifies the resource (company about-us blurb) and differentiates it from the short company description, which is a likely sibling field. The title reinforces the getter verb, making the tool's purpose immediately obvious and distinguishable from company_get and other company 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?

The description says the about-us blurb is 'separate from its short description,' implying when an agent wants the longer company narrative rather than the concise description it should use this tool. It gives clear context but does not explicitly name an alternative tool or state when not to use it.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by disclosing that omitting company_id returns all roster rows visible to the caller, including their own employment rows and rows from companies they administer, and that the underlying API is already scoped this way.

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

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

Two sentences with no filler, front-loading the core resource (employee roster) before detailing the scoping behavior. Every phrase earns its place, and the parenthetical explanation clarifies the 'all visible rows' case efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description appropriately mentions row contents (position, start date) and fully explains scoping behavior. Pagination is covered by the input schema, and the read-only safety is covered by annotations. A minor gap is not distinguishing from sibling company_roster, but the tool is otherwise complete for practical invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics for company_id by explaining the difference between omitting it and providing it, which goes beyond the schema's simple 'Only rows for this company.' It does not add page/page_size detail, but the schema already documents those adequately.

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 returns a company's employee roster with position and start date, and explains the scoping behavior with and without company_id. However, it does not explicitly differentiate itself from the sibling tool company_roster, so cross-tool distinction is left to inference.

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

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

The description provides clear context for when to omit or provide company_id, explaining what the caller will see in each case. It does not name alternatives or explicitly state when not to use this tool, but the scoping guidance is strong enough for an agent to decide when to call it.

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?

The annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: admin vs. non-admin visibility scoping and that the returned request_id feeds into a decision tool. This goes beyond what annotations alone would tell an agent.

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 three short sentences, each adding distinct value: what the tool lists, role-based behavior, and where the returned request_id is used. There is no redundancy or filler. The most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list operation with no required parameters and full schema coverage, the description is nearly complete. It explains the core behavior and the role of the request_id, which is the main integration point. Since there is no output schema, slightly more detail about return fields could help, but the description is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the parameters page, page_size, and company_id are already fully documented in the schema. The description does not add new parameter-level meaning, but it does imply that company_id narrows results to a specific company. This matches the baseline for high schema coverage.

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 identifies the tool as listing pending employment requests, with a specific resource (company employment requests) and a clear role-based scope: admins see all pending requests, others see only their own. It distinguishes itself from sibling tools like company_employees or company_roster by focusing on pending requests, though it does not 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.

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

The description provides clear context on when to use the tool: to view pending employment requests, with different behavior depending on admin vs. non-admin status. It also points to a downstream use case (obtaining request_id for company_decide_employment_request), which helps an agent understand its role in a workflow. It does not explicitly mention when not to use it or name alternatives, but the usage context is strong.

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

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

Annotations already mark this as read-only, but the description adds meaningful behavioral context: the records are created by company_fire_employee, and without company_id the tool returns every ex-employment row the caller can see, including their own and administered companies. This goes beyond what the schema or annotations convey.

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

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

Two sentences with no filler: the first defines the tool's output, and the second clarifies default scoping behavior. The most important information is front-loaded and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only listing tool with three optional parameters fully described in the schema, the description is complete. It covers what the rows represent, how they are created, and the default scope behavior, so an agent has enough to select and invoke it correctly.

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

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

Schema coverage is 100% with clear per-parameter descriptions, so the baseline is 3. The description adds extra value by explaining the semantic distinction of omitting company_id versus providing it, which is not fully captured by the schema's 'Only rows for this company.'

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 object (former employees), the fields (position, start and end date), and the origin (created via company_fire_employee). The word 'former' distinguishes it from the sibling company_employees, and the firing context makes the purpose unmistakable.

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 gives clear context for when to use the tool and explicitly explains the behavior when company_id is omitted versus provided. It does not name an alternative tool like company_employees, but 'former employees' and the firing provenance make the appropriate use case clear.

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

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

Annotations already mark this as read-only and non-destructive; the description adds that it is a public read and highlights the consequence of confirming the right company before irreversible people-related actions. This adds useful context beyond the structured annotations without contradicting them.

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

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

Two sentences with no filler: the core purpose and returned fields are front-loaded, followed by precise workflow guidance. Every clause contributes to selection or correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter public read, the description is complete: it specifies what fields to expect, marks the call as public, and gives the workflow context. With no output schema, the field list compensates for that; no essential operational information is missing.

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

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

Schema description coverage is 100%: company_id is fully documented as 'Numeric id of the company.' The description only restates retrieval by id and adds no parameter format or constraints, so baseline 3 is appropriate.

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 action and resource: retrieving a single company page by id, and enumerates the returned fields (name, description, organisation type, website, logo). It is easily distinguished from sibling tools like company_list and search by the singular 'by id' nature and explicit workflow position.

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 gives clear usage context: use after company_list or search to obtain the full record, and to verify the correct company before consequential employment or sponsorship actions. It does not explicitly state when not to use it or compare it against alternatives beyond this workflow, so it stops short of a 5.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by declaring the endpoint public (no auth barrier) and indicating that responses include company ids plus the listed fields. 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.

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

Two concise sentences: the first front-loads the resource and returned fields, the second gives the key usage instruction. Every word earns its place, with no redundant or vague filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only list endpoint with no output schema, the description sufficiently explains what is returned and why to call it (finding company ids). It does not cover edge cases such as empty results or ordering, but those are minor given the straightforward pagination schema and annotations.

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

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

Schema description coverage is 100%, with page and page_size fully documented in the input schema. The description does not add parameter-level details, but the baseline of 3 applies because the schema already carries the parameter meaning.

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 identifies the resource ('ClusterHack company pages') with a concrete verb ('Browse'), enumerates returned fields (name, description, org type, website, logo), and clearly states its role as the id-lookup precursor to other company tools. This distinguishes it from siblings like company_get without needing to open any schemas.

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?

Provides clear context: it is public data and should be used to find a company's id before calling any other company tool. This tells the agent when to use it, though it does not explicitly name alternative tools or state exclusion cases.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context beyond annotations: it returns exactly the public page render, includes no join requests or ex-employees, and explicitly states 'no write verbs'. It clarifies both what is and is not included, and does not contradict 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?

Two focused paragraphs: the first sentence front-loads the core purpose and scope, the second gives targeted sibling guidance and exclusions. Every sentence earns its place; no filler 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 single-parameter read tool with no output schema, the description fully explains the return semantic (public employees+moderators), boundaries (no ex-employees, no requests), and the correct usage context. Nothing critical is missing for an agent to call it correctly and interpret results.

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

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

Schema coverage is 100% and the only parameter (company_id) is documented with 'Numeric id of the company.' The description does not add new parameter-level meaning beyond what schema already provides, so a baseline of 3 is appropriate.

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

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

States a specific verb/resource ('The company page's public roster in one call') and precisely defines scope: employees and moderators as rendered to any visitor. This differentiates it from sibling tools like company_employees and company_ex_employees without needing to inspect their schemas.

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

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

Explicitly directs the agent to use this instead of company_employees/company_admins when reading someone else's roster, and explains why: those are self-or-admin scoped, so outsiders get empty lists and cannot distinguish 'nobody works here' from 'you may not see who does'. This exclusion criterion is actionable and clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: the listing is public, unfiltered, lightweight, and contains only name, description, and website fields, giving the agent a clearer picture of what to expect.

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 concise and front-loaded, with every clause earning its place. The core purpose comes first, and the clarifying parenthetical about being a lightweight listing, not a job-posting system, prevents misinterpretation without bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only listing with two optional pagination parameters, the description covers purpose, access (public), filters (none), and item composition (name, description, website). There is no output schema, so a bit more detail about the response envelope would be nice, but it is not a critical gap for such a lightweight tool.

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

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

Schema description coverage is 100%, so page and page_size are already fully documented. The description adds the useful context that there are no filters, which explains why only pagination parameters exist, but it does not add significant parameter-level detail 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 clearly states the tool lists companies not yet on ClusterHack, using a specific verb and resource. It also explicitly distinguishes itself from a job-posting system, resolving confusion raised by the tool name 'vacancies' and differentiating it from company_list.

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 gives clear context: use this for the public, unfiltered board of off-platform companies. It also states what it is not ('not a job-posting system'), which helps an agent avoid misuse, though it does not explicitly name alternatives like company_list.

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?

Annotations already establish read-only, non-destructive behavior, lowering the burden on the description. The description adds meaningful scope context—global catalogue, used across event certificate configs—which helps the agent understand the returned data's role. It does not detail pagination or response format, but those are less critical given the full parameter schema.

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

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

The description is short and front-loaded with the key fact that this is a global catalogue. The final fragment 'Not tied to one event' restates 'global' slightly, but the parenthetical about the background field is valuable and keeps it 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?

For a simple list operation with zero required parameters and fully described pagination schema, the description gives enough context about what the collection represents. A small gap is the absence of any mention of the response shape or ordering, but no output schema exists and the resource type is clear.

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

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

Schema description coverage is 100% and the two parameters (page, page_size) have complete descriptions. The tool description adds no parameter-specific semantics, so the schema carries the full burden; baseline 3 is appropriate.

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 identifies a specific resource ('certificate background templates') and defines the operation as listing the global catalogue. It also clarifies the domain purpose ('background field of an event's certificate config') and explicitly differentiates from event-scoped resources by saying 'Not tied to one event.'

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

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

It conveys that this is the global, event-independent catalogue, which implies using it when you need certificate backgrounds not attached to a particular event. It stops short of naming alternative sibling tools or giving explicit when-not-to-use conditions, so it is clear context rather than explicit routing.

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?

Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context by noting the endpoint is public because the branding is visible on the event page, and by explaining that it returns resolved rendering values and plan-customisation status. This goes beyond what annotations alone convey.

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 compact and front-loaded: it states what is read, then clarifies public access and the recommended call order. Every sentence contributes meaningful information with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only tool with no output schema, the description provides sufficient operational context: it enumerates the returned categories, explains public access, and gives usage guidance relative to the setter tool. The agent has everything needed to select and invoke it correctly.

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

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

Schema coverage is 100% and the only parameter, event_slug, is already described as 'Slug of the event.' The description does not add extra parameter-level detail, but the schema fully documents the single required input, justifying the baseline score.

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 uses a specific verb ('Read') and clearly identifies the resource: an event's white-label branding, including colours, theme, subdomain, resolved rendering values, and plan customisation. It also distinguishes itself from related tools by referencing event_set_branding, making the scope unmistakable.

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 explicitly says to use this tool before event_set_branding to check current values and plan eligibility. This provides a concrete usage context and names the related write operation, giving agents clear guidance on when this tool fits.

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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful context that this is a global catalogue rather than a user- or company-scoped list. It does not disclose ordering, response shape, or other behavioral details, but for a simple read-only list the annotations plus context are adequate.

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 sentence that immediately communicates scope and use. It contains no filler, tautology, or repetition of the title/schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple paginated read-only list, the description plus schema covers the essential information: what the tool returns conceptually, how it relates to event workflows, and how to paginate. There is no output schema, but the return shape is reasonably inferable; a note on ordering or exact fields would be a minor enhancement.

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

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

Schema description coverage is 100%, with both `page` and `page_size` fully documented including defaults and bounds. The description contributes no additional parameter-level detail, and none is needed given the schema's completeness. Baseline 3 applies.

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

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

The description identifies the resource (cities) and frames it as 'the global catalogue of cities', making its listing purpose clear. It also distinguishes it from sibling listing tools by tying it to the `city` field on `event_create`/`event_update` and event display. It does not explicitly state the verb 'list', but the title and 'catalogue' make the intent unambiguous.

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 gives explicit use contexts: selecting a city for event creation/update and showing where events happen. It does not name alternatives or explicitly state when not to use this tool, so it stops short of full routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value beyond those by specifying that this is a public read and that the data is the Q&A content displayed on the event's public page, helping an agent understand what kind of information will be returned without repeating annotation data.

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

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

Two sentences with no filler. The first sentence defines the resource, the second explains when to use it and why. All information is front-loaded and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with three well-documented parameters, the description explains the resource, its public nature, and practical use cases. There is no output schema, but the description's mention of 'question/answer pairs' adequately conveys the return content. Pagination behavior is left to the schema, which is acceptable.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description does not add detail about event_slug, page, or page_size beyond what the schema already documents, and it does not need to because those parameters are fully described.

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 title and description clearly identify a specific resource: an event's FAQ, defined as the question/answer pairs on its public page. This is distinct from broader event or info-block tools in the sibling list, and the public-page qualifier prevents confusion with internal FAQ content.

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 gives explicit use cases: answer a participant's question from the event's own words before guessing, and check existing coverage before adding new FAQ entries. It does not mention specific alternatives or exclusions, but the context is clear enough to guide an agent's decision.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's job is lighter. It adds meaningful behavioral context: visibility is not a full public roster and depends on whether the caller is a normal participant or an organiser. This is valuable detail beyond the schema and annotations, with no contradiction.

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 compact and well-structured: a clear purpose sentence first, then the important visibility nuance, then a single actionable pointer to a related tool. Every sentence earns its place and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with full schema coverage, the description covers purpose, visibility rules, caller-role behavior, and a follow-up tool reference. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

Schema coverage is 100%, so event_slug, page, and page_size are already fully documented. The description adds no additional parameter-level meaning beyond the schema. This is the baseline 3 for high schema coverage.

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 starts with a specific verb and resource: 'List participants at an event who are looking for a team.' It adds a clear visibility distinction (normal caller vs organiser) that clarifies the exact scope. It doesn't explicitly name sibling tools to differentiate from, 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?

It gives clear context about when the tool is useful and describes how results vary by caller role. It also points to team_matchmaking_teams as the follow-up tool for AI-ranked suggestions, which is a useful alternative routing cue. It doesn't state explicit when-not-to-use conditions, so not a 5.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context beyond annotations by clarifying the tool returns a public profile, listing the fields included, and noting what is excluded. It doesn't discuss auth or rate limits, but for a read-only public getter this is acceptable.

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

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

Two tightly packed sentences: the first defines purpose and output fields, the second provides usage context and exclusions. Every sentence earns its place with no filler 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 simple one-parameter read-only tool, the description covers all needed context: what it returns, where the slug comes from, and what it does not return (with alternatives). Since there is no output schema, the field list in the description adequately fills that gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining where the slug comes from ('from event_list or search'), which helps the agent obtain the correct parameter value. It does not repeat the schema's own slug example.

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

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

The description states a specific verb and resource: 'Get one event's full public profile by slug' and enumerates the returned fields (name, dates, address, topic, description, status, city). It also distinguishes itself from siblings by explicitly listing what it does not include and naming alternative 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?

The description gives explicit when-to-use guidance: 'Call this once you have a slug (from event_list or search) and need the details.' It also states exclusions and directs to alternatives: 'It does not include the schedule, FAQ or nominations — use event_schedule, event_faq and event_nominations for those.'

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?

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds semantic context about the content of the blocks but does not disclose operational behaviors like pagination behavior or response structure. This is acceptable given the annotation coverage, but the description itself contributes limited 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.

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

The description is a single, compact sentence that front-loads the core concept and uses parenthetical examples to clarify. It contains no fluff, though the phrasing is more definitional than action-oriented.

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 selecting the tool, the description is adequate: it identifies the resource and its scope. But with no output schema and no mention of return format or pagination semantics, an agent has limited understanding of what to expect beyond the parameter schema.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description does not add meaningful parameter-level detail; it mostly restates the event context. This aligns with the baseline score for high schema coverage.

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 defines the resource as an event's additional free-form information blocks — extra sections beyond the main description — and gives concrete examples like rules, prizes, and sponsor notes. It is specific enough to distinguish this from tools like event_get or event_faq, though it lacks an explicit verb and relies on the title for the 'Get' action.

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 when to use this tool: when needing extra sections beyond the main event description. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent given the large sibling set of event_* 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?

Annotations already mark the tool as read-only and non-destructive. The description adds meaningful behavior beyond that: the exact sort order, the fields in each entry (rank, team, score), and the unpublished-state access behavior with its error message. This is especially valuable since there is no output schema.

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

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

Two sentences, no filler. The core ranking and entry details are front-loaded, followed by the access/error condition. Every clause adds useful information.

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?

Despite lacking an output schema, the description tells an agent what will be returned (rank, team, score), how it is ordered, and when it is accessible. For a single-parameter read-only tool, nothing essential is missing.

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

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

The only parameter, event_slug, is fully covered by the schema with a basic description. The tool description adds 'one event' but no additional format or syntax details. 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.

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

Clearly identifies the resource (one event's leaderboard) and the specific behavior: submissions ranked by weighted judge score then vote count. This distinguishes it from sibling tools like event_get and submission_list.

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?

Provides clear access-context guidance: public after winners are published, admins/judges can preview pre-publication, and others receive a specific error. It doesn't explicitly name alternative tools, but the access timing and role guidance make appropriate usage clear.

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

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

Annotations already mark this as read-only; the description adds useful behavioral context beyond that, such as the output fields it returns and the noteworthy rule that hidden events only appear for their own organisers. The minor deduction is that the city/date filtering claim is unsupported by the schema, which is slightly misleading.

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

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

Four concise sentences front-load the purpose, then the output value and cross-tool need for the slug, then usage guidance, then an access edge case. Every sentence earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates the returned fields and includes an authentication/visibility caveat, so an agent has the essential invocation context. It is slightly incomplete because the city/date filter claim is unexplained and contradicted by the available parameters.

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

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

Schema coverage is 100%, so the schema already fully documents `page`, `status`, and `page_size`, including the important caveat that status filtering happens over the fetched page. The description adds no parameter-level meaning beyond restating 'filter by status, city or date', and the city/date part is not backed by any parameter.

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

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

The description states a specific verb and resource — 'Browse hackathons on the platform' — and clearly distinguishes this tool from `search` by noting it returns the slug that other event tools need. However, the claim that you can 'filter by status, city or date' is only partially supported by the schema: only `status` is an actual parameter, so the stated scope is somewhat inaccurate.

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

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

It explicitly says when to use this tool: when the user names an event you do not have a slug for and `search` is not precise enough, or to show upcoming/past events. This gives an agent clear routing guidance relative to `search` and implies that once you have a slug, you should use a different event 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral detail: the scope is the signed-in user for exactly one event, and the response summarizes multiple aspects of membership. The 'cheaper' note adds performance/cost context beyond what annotations provide.

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

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

The description is two purposeful sentences with no filler. The first sentence front-loads the core action and result contents; the second justifies when to use this tool. Every clause earns its place, and the structure makes it easy for an agent to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the necessary work of explaining what the tool returns: joined status, registration answers, free-agent status, and roles. It also includes the key selection context and cost trade-off. It could name the sibling alternatives explicitly, but for a single-parameter read-only tool it is substantially complete.

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

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

The only parameter, event_slug, is already fully documented in the schema with 'Slug of the event.' Schema description coverage is 100%, so the description's mention of 'one event' adds little beyond the schema. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 uses a specific verb ('Summarise') and a clear resource ('the signed-in user's relationship to one event'). It enumerates the exact facets covered: joined status, registration answers, free-agent listing, and roles. It also distinguishes itself from sibling tools by framing itself as a cheaper aggregate than combining several other 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?

The description gives an explicit use case: 'when you just need "is this user in, and how" for one event.' It also provides comparative guidance by saying it is cheaper than combining several other tools. It does not name those alternatives explicitly, but the context is clear enough for an agent to select appropriately.

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?

The readOnlyHint annotation already covers the safety profile. The description adds useful scoping context by stating 'Only ever returns their own data,' but it does not describe return format or pagination behavior, so the added behavioral transparency is moderate.

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

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

Two tightly written sentences with no filler. The core behavior is front-loaded, and the alternative tool is mentioned only where it adds real value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool, the description is complete enough: it states the resource, the ownership scope, and the alternative for other users' data. The schema covers all parameters, and the annotations cover side-effect safety.

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

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

Schema description coverage is 100%, so the input schema fully documents event_slug, page, and page_size. The description does not add parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'List the signed-in user's own answers to one event's registration questions.' It also distinguishes itself from the alternative event_registration_responses by emphasizing that this tool only returns the caller's own data.

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 explicitly tells the agent when to use this tool versus the alternative: use this for the signed-in user's own answers, and use event_registration_responses (organiser only) to read other people's. This is direct, unambiguous routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful domain context about what nominations are used for, but it does not disclose return shape, ordering, or notable behavior beyond the schema. This is adequate but not rich.

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 one compact sentence with an illustrative example and no filler. The noun-phrase construction is slightly awkward as a tool description, but it is concise and front-loads the resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with rich schema annotations, this is mostly adequate. However, with no output schema and no explicit statement that the tool returns a paginated list of nominations, an agent must infer the return semantics from the title and schema. That gap keeps it from being fully complete.

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

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

Schema description coverage is 100%, so event_slug, page, and page_size are already self-documenting. The description only implicitly maps to event_slug via 'event's' and adds no parameter-level details. The baseline of 3 applies.

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

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

The title supplies the verb ('Get') and the description identifies the specific resource ('award nominations/tracks') with a concrete example ('Best AI prototype'). This distinguishes it from sibling event_* tools like event_leaderboard or event_get. It is not a full action statement, so it misses 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 explicitly names usage contexts: creating teams, awarding winners, and building the leaderboard per track. This gives an agent clear when-to-use guidance. It does not name alternative tools or state when not to use it, so it stops short of a 5.

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

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

The description confirms this is a public, read-only catalogue and adds sequencing context ('call before event_create') beyond the readOnlyHint/destructiveHint annotations. It doesn't describe return format or content structure, but the annotations already cover safety, so the added 'starter nominations' and 'sensible defaults' context is sufficient for a low-risk lookup.

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

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

Two sentences, no filler: the first defines the resource and gives examples, and the second gives the precise call-time condition. All material information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only catalogue with a clear usage trigger, the description provides everything needed to decide to call it. No output schema exists, but the term 'catalogue' and the presets examples sufficiently convey what will be returned, and no auth or prerequisites are implied beyond 'public.'

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

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

The input schema has zero parameters, so there is nothing for the description to document. The description's mention of 'kind of hackathon rather than exact field values' reinforces that no field-level arguments are expected, matching the empty 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 identifies the resource as a 'public catalogue of event-creation presets' and gives concrete examples (AI build day, student hackathon, corporate innovation day) that make its scope unmistakable. It also anchors the tool's role next to event creation, so an agent can distinguish it from a general event lookup or type list.

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

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

It explicitly states when to call it: 'Call before event_create when the user describes a kind of hackathon rather than exact field values.' The inverse condition is implied by 'rather than exact field values,' and the alternative tool (`event_create`) is named, giving clear routing 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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds useful behavioral context: it is public data visible to anyone, returns questions in display order, and conveys which form fields exist and are required. It does not discuss pagination behavior or exact response shape, but annotations already cover the safety profile.

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

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

Two short sentences with no wasted words. The core action and scope are front-loaded, and the follow-up sentence adds workflow guidance that earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with annotations covering safety and schema covering parameters, the description is largely complete. It even states public access and the use-before-submit workflow; however, it does not describe the shape of paginated results or explicitly note default pagination, though these are documented in the schema.

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

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

Schema description coverage is 100%, so the parameters (event_slug, page, page_size) are already documented. The description adds context about form_field_ids and required fields, but does not add meaning to the individual parameters beyond what the schema provides, so baseline 3 is appropriate.

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 uses a specific verb ('List') and a specific resource ('custom questions an event asks at registration time'), including that results are in display order. It clearly distinguishes this from the many other event_* read tools by making the registration-form subject explicit.

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 gives concrete usage context: this is public data and should be called before event_submit_registration_answers to discover form_field_ids and required fields. It does not list exclusions or full when-not-to-use cases, but the intended place in the workflow is clear.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds behavioral context by clarifying the operation is scoped to one event and by characterizing the tool as cheaper/more precise than `whoami`, which helps the agent reason about cost and precision.

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

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

The description is two focused sentences with no filler. The core purpose is front-loaded, and the usage comparison is packed into the second sentence without 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 simple read-only tool with one parameter and no output schema, the description covers purpose, scope, and when to choose it over the main alternative. It doesn't enumerate possible return roles in detail, but 'organise, judge or only take part' gives enough context for an agent to call it correctly.

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 only parameter `event_slug` has a minimal schema description ('Slug of the event.'), and the tool description adds that it identifies 'one specific event.' This is adequate baseline coverage but does not meaningfully extend 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 clearly states a specific verb and resource: 'roles the signed-in user holds at one specific event.' It explicitly differentiates itself from the sibling `whoami` by being 'cheaper and more precise' for this narrower use case, so an agent can distinguish it from related 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?

The description gives explicit when-to-use guidance: use it when the event is already known and the goal is to check whether the user can 'organise, judge or only take part.' It also names `whoami` as the alternative, telling the agent when not to use this 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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses a non-obvious behavioral trait: broadcast and chat links are redacted for non-admins/non-participants. It also communicates ordering and status semantics (past/now/future), which helps the agent anticipate role-dependent output.

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

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

Two focused sentences front-load the core resource and then add the access-control caveat. Every clause serves a purpose: content, item fields, ordering, statuses, and role-dependent link visibility.

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 read-only list tool with one required parameter, the description covers what is returned, the item fields, ordering/statuses, and the role-based blanking behavior. The optional pagination parameters are already fully described in the schema, and no output schema exists to explain further.

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

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

The input schema has 100% description coverage: event_slug, page, and page_size are each documented. The description adds no parameter-specific meaning, so baseline 3 is appropriate; the schema carries the 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 resource ('the event's timeline') and the exact content returned: an ordered list of stages/activities with title, location, time window, and status. This clearly differentiates event_schedule from siblings like event_get and event_team_stages by naming the schedule artifact and participant-facing framing.

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 when to use the tool ('need the event's timeline/schedule') and clarifies the participant-facing scope, but it does not explicitly name alternatives or state when not to use it. Sibling tools like event_get and event_team_stages are not mentioned, so routing decisions are left to inference.

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

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

Beyond the readOnlyHint annotation, the description explicitly says 'Public read,' adding useful information about authentication requirements and side effects. It also clarifies what the returned data represents. Since annotations already cover safety, the description adds meaningful but not exhaustive behavioral context.

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 compact and well-structured: it front-loads the output contents, adds a practical usage note, and closes with access semantics. Every sentence adds value without unnecessary repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with no output schema, the description adequately explains both what the tool returns and when to use it. The enumeration of link types compensates for the absence of an output schema, and the annotations cover the safety profile.

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

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

The input schema fully documents the only parameter, event_slug, with a description saying 'Slug of the event.' The tool description adds no additional parameter semantics beyond confirming the tool is event-specific, so the baseline score of 3 applies.

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

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

The description clearly identifies the tool's purpose: returning public promotion links for an event, and enumerates the specific link types (shareable page, calendar file, Open Graph image, plain-text digest). This distinguishes it from sibling tools like event_get or event_schedule, which serve different event-related purposes.

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 gives a concrete use case: drafting an announcement, with guidance on where to place the share URL and the .ics file. It does not explicitly mention when not to use this tool or name alternative sibling tools, but the context is clear enough for an agent to select it appropriately.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces 'Public read'. It adds context about on-platform scope and the fact that off-platform sponsors are intentionally excluded, which is behaviorally useful beyond the 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?

Two sentences, no filler. The purpose and scope are front-loaded, and the sibling-tool pointer is compactly placed at the end.

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 low-complexity list tool with one well-documented parameter and annotations covering safety, the description sufficiently explains what will be returned and how to handle the off-platform edge case. No critical missing information for an agent to call it correctly.

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

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

Schema coverage is 100%, so the sole parameter event_slug is already fully documented in the schema. The description references 'one event' but adds no new semantic detail beyond what the schema provides.

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

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

The description names a specific resource (on-platform companies sponsoring an event) and the key data returned (sponsorship tier). It also explicitly distinguishes itself from event_sponsor_text, making the scope unmistakable.

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 explicitly instructs when to use event_sponsor_text alongside this tool: for sponsors not yet on ClusterHack. This gives clear, actionable routing guidance versus a named alternative.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: the endpoint is 'Public read' (no auth), and the data entries are free-text records (name, description, website, logo) with a sponsorship tier. It does not mention pagination or errors, but these are not critical for a simple read list.

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 dense sentence that front-loads the core purpose and packs inclusion criteria, field definitions, sibling contrast, and access level without redundancy. Every clause provides needed information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only list tool, the description gives everything needed to call it correctly: the schema covers the parameter, the output contents are enumerated, and the relationship to `event_sponsors` removes ambiguity. No output schema exists, but the data shape is sufficiently specified.

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 sole parameter `event_slug` is fully described in the schema with 100% coverage. The tool description reinforces that the tool targets 'one event' but adds no formatting or edge-case semantics beyond the schema, so the high-coverage baseline of 3 is appropriate.

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

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

The description names a specific action and resource: listing the sponsors of one event. It also states the key discriminator, sponsors that are NOT on ClusterHack, and identifies the off-platform counterpart to `event_sponsors`, making the distinction from the sibling tool explicit.

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

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

It gives clear context for when to use it (for sponsors not on ClusterHack) and names `event_sponsors` as the counterpart alternative. It does not explicitly say 'use `event_sponsors` for on-platform sponsors', but the counterpart framing leaves that relationship unambiguous.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Public read.' It adds useful behavioral context: the data is per-event and consists of named grouping buckets, with concrete examples. No contradiction exists between description and 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 sentence that packs in the resource definition, examples, the relationship to event_add_sponsor, and access scope. It is front-loaded with the essential identification of the resource and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one simple parameter, no output schema, and annotations covering safety, the description is sufficient for an agent to invoke the tool correctly. It conveys the conceptual return value (tier names/groups) and the practical use case, leaving no critical gap.

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 only parameter, event_slug, is fully described in the schema ('Slug of the event.'), giving 100% schema coverage. The description's mention of 'one event' aligns with the parameter but adds no further semantic detail beyond the schema, so the baseline score of 3 applies.

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

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

The title provides a clear verb+resource ('List an event's sponsor tiers'), and the description defines exactly what these tiers are: the buckets that event_add_sponsor slots companies into. This implicitly distinguishes the tool from sibling event_sponsors, which lists actual sponsors, and event_sponsor_text, which is a different aspect of sponsorship.

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 gives clear context for when to use the tool: to retrieve the tier buckets for a specific event, as referenced by event_add_sponsor. It also notes it is a public read. However, it does not explicitly contrast with alternative sibling tools or state when not to use it, so it stops short of full 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?

Annotations already mark it read-only, so the description does not need to cover side effects. It adds conceptual behavior beyond the schema by describing the semantic content (team-facing checkpoints, time windows) and the relationship to event_schedule, which helps an agent predict what the response represents.

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

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

Two sentences with no filler: the core definition, examples, a targeted sibling distinction, and the purpose are all front-loaded. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple read-only paginated list; the description gives enough domain context to understand what is returned and how it differs from the sibling. Without an output schema, a bit more detail about the shape or ordering of stages would be ideal, but nothing essential for invoking the tool is missing.

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

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

All parameters are documented in the schema, so the 100% coverage sets a baseline of 3. The description does not add parameter-specific semantics beyond implying event_slug through 'An event's', but it does not need to.

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 identifies a specific resource: an event's team-facing reporting checkpoints with time windows, and gives concrete examples. It also differentiates from event_schedule, a sibling, making the tool's scope unambiguous.

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

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

It explicitly routes away from event_schedule by explaining that event_schedule is the event's own agenda, and states the intended use case: tracking team progress through the event. This is clear when/alternative 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?

Annotations already establish readOnlyHint, and the description adds useful behavioral context: the catalogue is 'global,' 'small,' and 'rarely changes,' which helps an agent treat results as stable and cacheable. This goes beyond the bare schema and annotation data.

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 entire description is one compact sentence that defines the tool, states its purpose, and notes its stability. Every clause earns its place and there is no redundant filler or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list operation with only optional pagination parameters and full schema documentation, the description is complete. It gives the catalog's role, its relationship to create/update APIs, and its expected size/stability, which is sufficient for correct invocation.

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

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

The input schema fully documents `page` and `page_size` with descriptions and bounds, so schema coverage is 100%. The description adds slight contextual value by implying the list is small, but it does not add new parameter-level meaning beyond what the schema already states.

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

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

The description names a specific resource ('global catalogue of event types') and precisely ties it to the `type` field on `event_create`/`event_update`. This clearly differentiates it from sibling event-related list tools like `event_roles` or `event_presets`.

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 clearly states when this tool is relevant: when needing allowed values for the `type` field on `event_create`/`event_update`. It does not explicitly list exclusions or alternative tools, but the purpose is specific enough for an agent to infer the right context.

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?

Annotations already signal readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context: it is 'Public and PII-free,' does not redeem the token, and returns specific fields (name, slug, active/expired/uses remaining). This goes beyond the annotations and gives the agent a clear contract of what will happen.

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

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

The description is two brief paragraphs, with the core action front-loaded in the first sentence. The second paragraph adds return-value details and use cases without any fluff. Every sentence earns its place and the structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only preview tool with no output schema, the description is complete: it states the action, the inputs from the URL, the return fields, the non-destructive nature, and when to use it. No critical information is missing for an agent to decide whether and how to call 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?

Schema description coverage is 100% and the schema already explains the token parameter with an example URL. The description adds no additional parameter-level detail, so the baseline score of 3 applies. It correctly orients the user to the token concept, but the schema carries the full explanatory burden.

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 opens with a specific verb and resource: 'Look up what a shareable invite link opens, without redeeming it.' It clearly differentiates from a join action and states what is returned (event name, slug, validity), so an agent can immediately understand the tool's function and distinguish it from any join/redemption tool.

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 explicitly says 'Use this before `invite_join`' and gives two concrete use cases: showing the user what they are about to join, and explaining why a link stopped working. However, `invite_join` is not listed among the sibling tools, so the named alternative is not actually available for selection in the provided set, slightly weakening the routing 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?

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond annotations by stating that the data is public, needs no account, and is the same text an anonymous visitor sees. This clarifies access and provenance without contradicting the 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 bit longer than average, but every sentence earns its place: the first enumerates the returned content, and the second provides rationale and usage guidance. The key information is front-loaded and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description compensates by itemizing the returned fields, explaining the public access, and giving examples of when to call it. For a simple, parameterless, read-only tool, nothing important is missing.

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

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

There are zero parameters, so the baseline is 4. The description reinforces that no input is needed and that the data is publicly available, which is useful because the schema's empty properties object conveys only the absence of parameters.

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 names the resource ('the service's legal identity') and enumerates the exact contents: entity, registration, emails, postal address, terms date, and minimum age. It is specific enough to distinguish from most siblings, though it does not explicitly name another tool to compare against.

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 gives concrete use cases: building a footer, quoting the contact address, or answering age questions, and says to read this instead of hard-coding a copy. It does not explicitly mention when not to use it or name an alternative sibling tool, so it lacks the full 'when-not/alternatives' 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context beyond that: the list is read from the live URL configuration and always matches what the server actually serves, implying fresh dynamic data rather than cached static content.

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

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

Three short sentences, each earning its place: purpose, usage guidance, and a behavioral guarantee. The main point is front-loaded, with no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with two optional parameters and no output schema, the description covers purpose, when to use it, and a key behavioral property. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the parameter descriptions already document limit and query. The description does not add extra param-level semantics, but it doesn't need to, given complete schema coverage.

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 ('List') and resource ('raw REST endpoints behind this server'), and explicitly contrasts these with 'curated tools'. This clearly distinguishes it from the many sibling tools in the list.

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

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

It gives explicit guidance: use with api_request when no curated tool covers what you need. This tells an agent exactly when to select this tool over the curated alternatives.

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?

Annotations already declare readOnlyHint true and non-destructive behavior. The description adds valuable behavioral context beyond this: results are scoped to the current connection, include role/permission details, and the include_unavailable parameter can reveal what additional permissions would enable. 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.

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

Three sentences, each earning its place: the first states scope, the second states return content, and the third states when to use it. Information is front-loaded and there is no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description appropriately explains what is returned: each tool with its one-line purpose, intended role, and consumed permission. Combined with the schema's documented optional parameters and enum categories, an agent has enough to call and interpret the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of grouping by 'area' loosely aligns with the category parameter, and the permission-gain framing relates to include_unavailable, but it adds no parameter details beyond what the schema already documents.

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 operation ('list'/'returns') and resource ('capabilities'), and elaborates on content: grouped by area, with each tool's purpose, role, and permission. It does not explicitly differentiate from the sibling list_api_endpoints, but the scoping to 'current connection' and 'tools' makes the purpose unambiguous.

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 gives an explicit use case: use it when unsure whether a capability exists, framing it as cheaper than guessing tool names. It does not mention when not to use it or name alternative tools, but the context is clear enough for an agent to decide.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it searches across multiple kinds and returns matching objects with identifiers, but it does not disclose ranking, pagination, or matching strictness beyond what the schema already says about names, descriptions, and tags.

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

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

Three compact sentences: platform scope, use case with examples, and output promise. All information is front-loaded and every sentence earns its place; there is no filler 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 simple read-only discovery tool with full schema coverage and no output schema, this is complete. It defines scope, when to call it, what to pass, and what comes back (objects with slug/id). With annotations covering the safety profile, nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by illustrating query semantics with concrete natural-language examples ('the AI hackathon in Berlin', 'Sasha's team') and by clarifying that results expose the identifiers needed by other tools. This enriches the query parameter beyond its schema definition.

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

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

States a specific verb and resource: 'Search across the platform: events, teams, projects, people and articles.' The use case is explicit: it finds things when you do not yet know the identifier. This clearly distinguishes it from sibling getters like event_get or team_get, which require an identifier.

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

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

Explicitly says when to use this tool: 'One call when you do not yet know the identifier of the thing the user means.' It gives natural-language examples and explains that the returned slug or id is 'needed for every other tool,' signaling the agent to switch to sibling tools afterward.

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?

Annotations already declare the tool read-only and non-destructive; the description adds that output covers server identity, version, and connection info, which is useful for diagnostics. It does not specify the exact output shape, but for a zero-parameter read-only tool this is a minor 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?

Two sentences with no filler. The primary definition is front-loaded, and the use case is stated immediately after, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple no-parameter, read-only tool, the description names the main content areas and a concrete purpose. It could include example return fields or a sample output since there is no output schema, but the operation is simple enough that this is adequate.

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 no parameters and the schema is an empty object with 100% coverage, so parameter documentation is unnecessary. The baseline of 4 applies because there is nothing for the description to add.

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 identifies the tool as returning server metadata: what the MCP server is, its version, and connection details. This distinguishes it from siblings like list_api_endpoints and list_capabilities, though it does not explicitly name those 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?

It gives clear usage context: diagnostics and informing the user how to manage or revoke the connection. It stops short of an explicit 'use this instead of X when...' statement, so it is not a full 5.

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

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

Annotations already mark this as readOnly and non-destructive, so the description adds context beyond them: it is public, cross-event, ranked for display, and optionally filterable by event. No contradictions with annotations exist, and the read-only nature is reinforced by calling it a gallery.

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 compact, front-loads the core purpose, enumerates key fields, and ends with a routing hint to a sibling. Every sentence earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only browse tool, the description covers the resource scope, returned fields, optional filtering, and the key sibling distinction. Pagination details are available in the schema. It lacks an explicit statement about the list envelope or ordering criteria beyond 'ranked for display,' but this is a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents page, page_size, and event_slug. The description adds minimal extra meaning, only restating 'optionally narrow to one event' for event_slug. This meets the baseline but does not significantly enhance 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 uses a specific verb ('Browse') and names the exact resource ('public, cross-event showcase'), then enumerates what is shown (title, tagline, team name, vote count, cover image). It explicitly contrasts itself with event_leaderboard, making sibling differentiation clear.

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

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

It states the intended use case ('public gallery') and provides a concrete alternative: use event_leaderboard when judged rankings for one event are needed. This gives an agent clear routing guidance without ambiguity.

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?

Annotations already provide readOnlyHint=true and destructiveHint=false, but the description goes further by disclosing access-control behavior: anonymous or unrelated callers only see submitted submissions, while drafts are restricted to the team, admins, and judges. This adds meaningful context about authorization and visibility beyond the annotations, and it accurately reflects the tool's read-only nature without any contradiction.

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 compact and immediately front-loads the action and return contents. The second sentence provides exactly the two additional pieces of information an agent needs—visibility rules and alternative tools—without any filler or repetition of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter read tool, the description is fully complete: it lists the output fields, explains access restrictions, and names alternatives for when the id is unknown. Even though there is no output schema, the explicit field list covers return-value expectations, and the annotation covers safety. Nothing an agent needs to select and invoke this tool correctly is missing.

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

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

The schema already documents submission_id with type, minimum, required flag, and a description ('Numeric id of the submission'). The tool description adds no new parameter semantics beyond saying 'by id' and referencing 'numeric id' in the usage note. With 100% schema description coverage, the baseline of 3 is appropriate; the description does not need to compensate for missing schema details.

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 opens with a specific verb ('Retrieve'), a specific resource ('one project submission by id'), and enumerates the returned fields, making the tool's function unmistakable. It also distinguishes itself from list-style siblings by noting it requires a numeric id, so an agent can tell it apart from submission_list without opening the schema.

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

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

The description explicitly states when to use this tool vs. alternatives: 'Use submission_list or submission_get_mine when you do not already know the numeric id.' It also provides visibility/authorization context describing when callers can access submissions (submitted vs. draft), which directly guides an agent in whether this tool will return data in a given context.

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?

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds substantial non-obvious behavior: identity-based visibility rules and the fact that status filtering happens client-side after the underlying endpoint returns results. This is exactly the kind of context beyond annotations that an agent needs.

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

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

Two sentences with no filler. The first sentence front-loads the purpose; the second packs important visibility and filtering caveats into dense but readable prose. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with 5 optional parameters and no output schema, the description covers the essential call context: resource, filters, permission scoping, pagination behavior, and a known endpoint limitation. Nothing critical is missing for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning for status by explaining it filters the returned page client-side and should be combined with a larger page_size to apply beyond one page. This helps the agent use parameters more effectively than the schema alone.

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

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

States a specific verb and resource ('Browse project submissions') and lists concrete filters (event, team, status). This clearly distinguishes it from sibling tools like submission_get (single submission retrieval) and submission_list_media (media of a submission).

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?

Provides clear context on visibility depending on caller identity (anonymous vs signed-in vs event admin/judge) and warns that status filtering is client-side, advising a larger page_size for cross-page effects. It does not explicitly name alternatives like submission_get, but the context is sufficient for an agent to choose this tool appropriately for listing.

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?

Annotations already mark the operation as read-only and non-destructive, and the description adds meaningful behavioral context by explaining that visibility mirrors the parent submission's visibility ('public once submitted, otherwise limited'). This goes beyond the annotations and helps an agent anticipate access restrictions.

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

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

The description is two tight sentences with no filler. It front-loads the primary action and resource, then supplies the key visibility caveat, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list operation with full parameter schema and read-only annotations, the description provides enough context. It could mention the returned media type more explicitly, but the core behavior and access scoping are adequately covered.

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

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

The input schema fully documents all three parameters, including page, page_size, and submission_id, so the baseline is 3. The description does not add parameter-level details, but none are essential given the schema coverage.

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 uses a specific verb ('List') plus a specific resource ('screenshots/gallery images attached to a submission'), making the tool's function immediately clear. It is easily distinguished from sibling tools like submission_get or submission_page because it targets attached media rather than general submission content.

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 use when a user needs to retrieve media attached to a submission, but it does not explicitly say when to prefer this tool over nearby alternatives such as submission_get or submission_page. The visibility context is useful but not a substitute for direct usage 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?

Annotations only declare readOnlyHint and non-destructive behavior; the description adds critical context: judge names appear only with consent, placement is private before ceremony with a placement_private flag, and private_note is absent rather than blanked. This is meaningful behavioral disclosure beyond the 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 longer than average but each sentence contributes essential routing or behavioral detail. It is front-loaded with the core purpose and then adds access and privacy nuances in a logical order.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining return contents, and it does so thoroughly: feedback, name consent behavior, placement/rank/score, private placement flag, and omission of private_note. It is complete for an agent to call correctly.

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 single parameter submission_id is fully documented in the schema with 100% coverage. The description confirms the tool operates on a project but adds no new parameter-level detail, so it meets the baseline without exceeding it.

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

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

The description states a specific verb and resource: read a project's public page including the submission, judge feedback, and placement info. It explicitly distinguishes itself from submission_get and judging_scores_for_submission, so an agent can select it correctly among similar tools.

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

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

It gives an explicit use case ('what did the judges say about our project?') and contrasts alternatives: submission_get returns only project fields, judging_scores_for_submission is scoped away from teams. It also clarifies public vs draft visibility, which is essential for deciding when this tool is appropriate.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a useful detail—that the tag vocabulary is shared across content types—but discloses nothing about ordering, pagination behavior, 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?

A single sentence that front-loads the verb and object, then adds a helpful parenthetical about shared tag vocabulary. There is no filler, redundancy, or unnecessary repetition of schema details.

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 read-only list tool with two optional, well-documented pagination parameters and safety annotations, the definition is nearly complete. The only minor gap is that the response structure or ordering is not mentioned, but that is not critical for an agent invoking this simple listing operation.

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 fully documents both parameters with defaults, bounds, and descriptions (page default 1; page_size default 20 max 100). The description adds no parameter-specific meaning, 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.

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

The description names a concrete verb and resource ('List tags') and clarifies that these tags form a shared categorization vocabulary across articles, projects, and more. This makes it clear what the tool returns and helps distinguish it from sibling list tools like article_list, tech_list, or event_list.

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 tool is for fetching platform-wide tag vocabulary, but it does not explicitly state when to use it versus alternatives or any exclusions. An agent can infer usage from 'used to categorize content across the platform', but there is no direct routing 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?

Annotations already establish read-only and non-destructive behavior. The description adds meaningful context beyond that: the access-control caveat (visibility depends on membership, creation, or event administration) and the specific data categories returned. This gives an agent realistic expectations for permission failures and response content.

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 concise and front-loaded: the first line states the purpose and contents, the second line adds the essential access caveat. Every sentence earns its place with no redundant phrasing or repetition of schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with a straightforward purpose and no output schema, the description sufficiently covers what the tool returns and under what conditions it is callable. The access restriction is a critical piece of context that is explicitly disclosed. Nothing essential is missing.

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

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

The schema covers 100% of the single parameter (team_id) with a clear description ('Id of the team.'). The tool description does not add extra semantic detail about the parameter, which is acceptable given the schema's completeness. Baseline of 3 applies.

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

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

The description clearly identifies the action ('Get'), the resource ('one team'), and the scope ('full detail'), enumerating the contained fields (name, description, project info, readiness, accessibility flags, event, nomination). This distinguishes it from sibling tools like team_list or team_members, which target narrower or bulk views.

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 use when a caller needs a single team's comprehensive detail, and it gives a clear access condition: the user must belong to the team, have created it, or administer its event. However, it does not explicitly compare against alternative team_* tools or state when not to use it, leaving some routing to inference.

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

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

Annotations already carry readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond those: the visibility scope is account-dependent, it is never a public directory, and it supports filtering. This meaningfully clarifies what the result set will contain.

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

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

Three short sentences: core scope first, then filtering options, then the routing to team_get. Every sentence contributes distinct information with no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a simple list operation with four well-documented optional parameters, annotations clarifying read-only and non-destructive behavior, and a description covering scope, filtering, and alternative selection. Nothing critical is missing for an agent to call it correctly.

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?

All four parameters have schema descriptions, giving 100% coverage, so the baseline is 3. The description reinforces event_slug and search usage but does not substantially add meaning beyond the schema's own parameter documentation.

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

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

States a specific verb and resource ('List teams') and immediately scopes it to what the signed-in account can see, explicitly ruling out a full public directory. It also distinguishes itself from team_get by pointing to that sibling for single-team detail.

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

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

Gives concrete direction on when to filter with event_slug or search, and explicitly routes the agent to team_get for full detail once an id is known. This tells the agent how to select and use the tool, even without opening the schema.

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?

Annotations already mark readOnlyHint=true and destructiveHint=false, and the description adds useful context beyond that: locations are referenced via team_additional_info's location_id, are set up separately, and may not exist. This helps an agent understand the data model and avoid invalid assumptions about creating locations.

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

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

Two sentences with no filler. The main purpose is front-loaded, and the important caveat about no self-service creation is stated in a second sentence without bloating the description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool, the description covers the source, the fields returned, the possibility of no location being set, and the lack of a creation endpoint. A minor gap is that it does not explicitly state what happens when no location is set (e.g., empty result vs. null), especially since there is no output schema.

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

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

Schema coverage is 100% and team_id already has a clear description ('Id of the team.'). The tool description adds background about location_id but does not materially change the meaning of the single parameter, 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.

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

The description explicitly says 'Read the physical location details linked to a team's additional-info profile' and lists the specific fields (street, city, state, zip). It uses a specific verb and resource, clearly distinguishing this from generic team_get or team_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?

The description clearly frames this as a read-only lookup for physical location and warns that there is no self-service creation path, which prevents an agent from attempting a mutation. However, it does not explicitly name an alternative tool for when location details are not needed or when creating a location is required.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context: the tool is throttled, returns an AI-ranked recommendation, and is restricted by caller role. This goes beyond what the annotations alone provide without contradicting them.

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 three tight sentences: purpose, authorization/prerequisite, and throttling warning. Every sentence carries useful information and the most important context is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two parameters, no output schema, and strong annotations, this description is complete enough for correct invocation. It states what is returned, who may call it, what input is needed and where to get it, and a performance caveat.

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?

Both parameters already have schema descriptions, so the baseline is 3. The description adds value by explaining that free_member_id comes from specific upstream tools and that locale controls the language of generated explanations, which the schema only partially implies.

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 a specific action and resource: an AI-ranked list of teams a free agent could join within the same event. It also adds meaningful scoping details (teamless participant, same event, owner/admin only) that distinguish it from generic team 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?

The description tells the caller how to obtain the required free_member_id via event_free_agents or event_join_as_free_agent, and it gives an explicit permission boundary (owner or admin). It also warns against tight loops due to throttling, though it does not explicitly enumerate sibling alternatives or when-not-to-use conditions.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the returned id is a membership id, not a user id, and is intended for subsequent mutation calls. This helps prevent misuse of the output.

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

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

The description is two sentences with no filler. The first sentence states the core function, and the second provides essential downstream context about the id semantics. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with fully documented parameters and read-only annotations, the description covers the return content (members, role, caption) and the key behavioral nuance about membership ids. It could mention pagination behavior, but the schema already defines page and page_size defaults and limits.

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

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

Schema description coverage is 100%, so the schema already documents team_id, page, and page_size. The description does not add parameter-specific detail beyond what the schema provides, which fits the baseline of 3.

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

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

The description clearly specifies the operation: listing a team's current members, including role and caption. It is a specific verb+resource statement that is distinct from sibling tools like team_open_roles or team_roles, 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.

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

The description provides useful downstream guidance by telling the agent to use the returned row id with team_assign_role or team_remove_member. However, it does not explicitly state when to choose this tool over alternatives like company_roster or team_matchmaking_teams, leaving the selection context mostly implied.

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

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

Annotations already declare `readOnlyHint=true`, but the description adds meaningful behavioral context beyond that: visibility is constrained to what the account can see, and `event_slug`/ufiltered calls can silently return incomplete rows with a `note`. This kind of endpoint-level caveat is exactly what an agent needs to interpret results correctly.

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 dense but every sentence carries load: purpose, visibility, sibling routing, filter semantics, and a warning about truncation. The first sentence states the core function, and the caveats are organized into a compact paragraph. There is no filler or repetition.

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 read-only list with four optional parameters and no output schema, the description covers what matters: who can see results, how to filter, when to prefer `team_id`, and what incomplete results look like. It also names the sibling tools and fallback strategy, so an agent has enough to call it correctly and interpret results.

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

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

Schema description coverage is 100%, so each parameter's basic role is already documented. The description adds valuable semantics not in the schema: `team_id` is answered exactly while `event_slug` is not, and the unfiltered form has a known failure/truncation mode. That goes beyond baseline schema description without fully re-explaining every parameter.

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 a specific verb and resource ('List the positions teams are looking to fill') and draws a sharp boundary against the sibling `team_seeking_members`, so there is no ambiguity about what this tool does. The title is expanded with concrete examples and scope, making it clearly distinguishable from related 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?

It explicitly says when not to use it ('It is not a public cross-team browse... that is `team_seeking_members`) and gives pairings (`pair it with `event_free_agents` and `team_matchmaking_teams`). It also explains when to filter by `team_id` vs `event_slug` and when to ask per team, leaving few usage decisions to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no mutation warning is needed. The description adds context beyond annotations by specifying that only public updates are returned and that the result order is simply what the server returns, which prevents agents from assuming a guaranteed sort.

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

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

The description is two sentences with no filler. The resource and purpose appear first, the clarifying definition of 'twits' is compact, and the second sentence justifies practical use without repeating schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple paginated list operation, the description, combined with the fully documented input schema and read-only annotations, gives an agent everything needed to call it correctly. The lack of an output schema is not a gap because the returned resource is clearly identified as a team's list of twit posts.

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

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

Schema description coverage is 100%, so page, page_size, and team_id are already fully described in the input schema. The description adds no extra parameter-level meaning, which matches the baseline expected when the schema carries the documentation burden.

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 opens with the specific verb 'List' and a concrete resource: a team's public updates ('twits'), which are defined as short build-log posts. This clearly distinguishes team_posts from sibling getters such as team_get or team_members, which concern team metadata rather than the team's update feed.

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 gives explicit use cases: catching up on a team's activity and checking what has already been posted before writing another update. It also points to team_post as the write counterpart, providing an alternative, although it does not enumerate broader when-not-to-use exclusions or other sibling read 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?

Annotations already convey readOnlyHint=true and destructiveHint=false, so the description adds value by exposing exactly what state is inspected: self-marked readiness, ban status, and judging accessibility. It does not contradict the annotations and gives useful operational context beyond the schema.

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

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

One compact sentence carries the full purpose, lists all three checked conditions, and contains no filler. The key detail is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only check with no output schema, the description adequately captures what is being queried. It does not explicitly state the return shape, but the phrasing naturally implies the result contains readiness, ban, and judging-access indicators; mentioning this would make it fully complete.

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

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

Schema coverage is 100% with team_id described as 'Id of the team,' and the description adds no parameter-level detail. Baseline 3 is appropriate because the schema fully documents the only parameter.

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

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

States a specific verb 'Check' with a precise resource: team readiness. Naming the exact checks (ready to present, banned, judging-accessible) distinguishes it from generic team retrieval tools like team_get.

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 when to use it: whenever an agent needs a team's readiness status. It does not name alternatives or exclusion conditions, so an agent must infer that team_get or team_list would be used for general team information.

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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds context about the semantic purpose of the roles, but it does not disclose additional behavioral details such as pagination limits or whether roles are returned in any particular order; this is acceptable given the simple read-only nature.

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 one concise sentence that states the action, the resource, examples, and a relevant cross-reference to team_assign_role. There is no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list operation, the description and schema together give enough information to call the tool correctly. It does not describe the return shape, and there is no output schema, but the action is so straightforward that this is a minor gap rather than a correctness issue.

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

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

Schema description coverage is 100%, so page, page_size, and team_id are already fully documented in the schema. The description does not add parameter-specific meaning beyond indicating that the listed roles are assignable, which is not necessary for correct invocation.

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 lists a team's defined roles, with concrete examples, and indicates these roles are the ones used for assignment via team_assign_role. It is unambiguous about the resource and action, though it does not explicitly compare itself to sibling tools like team_open_roles.

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

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

The phrase 'roles a team has defined' and the mention that members can be assigned via team_assign_role gives useful context for when to call this tool. It does not explicitly list alternatives or exclusions, but the intended use is clear enough for a simple listing operation.

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?

The annotations already declare read-only and non-destructive behavior, and the description adds meaningful context beyond them: the list is public and readable even by someone who hasn't joined the event, and each row contains the team's public profile plus `open_roles`. This removes ambiguity about visibility and output granularity.

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 three purposeful sentences: the core behavior is front-loaded, the alternative tool is named for contrast, and useful follow-ups are listed. There is no filler or repetition of schema details.

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 read-only browse tool with a fully documented schema and safety annotations, the description provides all essential call-context: who can use it, what it returns at a row level, and which related tools to use next. No critical guidance is missing.

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

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

All four parameters have descriptions in the input schema, so the baseline is 3. The description reinforces the event-scoped nature of the tool but does not add parameter-specific detail beyond what the schema already provides.

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

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

States the specific verb 'Browse' and the exact resource: teams of one event that are advertising open positions. It clearly identifies the public 'who is recruiting' list and differentiates itself from the sibling `team_open_roles` direction.

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

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

Explicitly says this is the tool for a person looking for a team, names `team_open_roles` as the opposite direction, and suggests follow-up actions (`team_request_join`, `event_join_as_free_agent`). This gives the agent clear when-to-use and 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description's 'List' verb is consistent with that, and it adds semantic context about what technologies are used for, but no extra behavioral details such as pagination behavior or return 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?

A single, front-loaded sentence that names the action and resource immediately, adds clarifying context, and includes useful examples without any filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool, the description, schema, and annotations together cover what the tool lists, its domain, and pagination controls. The lack of an output schema is not a significant gap since the listed items are straightforward tech-stack tags, though a note on how this differs from tag_list would have been slightly more complete.

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

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

The input schema covers 100% of the parameters, with page and page_size fully described including defaults, minimums, and maximums. The description adds no parameter-level information, so it neither improves nor harms parameter understanding 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?

States a specific verb and resource ('List technologies'), defines the resource as 'tech-stack tags', and gives concrete examples ('React', 'PostgreSQL'). The phrase 'that projects and teams can be labelled with' clarifies the domain and distinguishes this from generic tagging tools like tag_list.

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 when to use the tool: when a list of tech-stack tags suitable for labelling projects and teams is needed. However, it provides no explicit when-not-to-use guidance or alternatives (e.g., tag_list for non-tech tags), leaving the choice mostly to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by detailing what the tool returns, emphasizing the role list, and explaining why the result is needed before other calls.

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 front-loaded with the core purpose, then elaborates with concrete return content and usage guidance. Every sentence earns its place; there is no padding or repetition.

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, read-only tool with no output schema, the description fully covers why, when, and how to use it. It explains the return value, the role dimension, and the practical next step of resolving names to slugs or ids.

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

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

The tool takes zero parameters, so there is nothing to document. Schema coverage is 100% by definition, and the description's discussion of return values is more relevant than parameter semantics here.

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 opens with a clear, specific statement: 'Who is signed in, what roles they hold, and where.' It then names the exact return payload — account, OAuth permissions, and the user's memberships with roles — which distinguishes it from sibling tools like event_my_membership and team_members.

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

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

Explicitly instructs the agent to 'Call this first in any new conversation' and to use it to decide which tools apply before calling anything else. It also explains how to resolve ambiguous references like 'my event' or 'our team' into concrete slugs or ids.

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