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

With no annotations, the description carries the full burden and delivers non-obvious behavior: always fetches live data, first call returns nothing but a baseline, and the acknowledge flag controls whether the cursor advances. It omits auth/permission requirements, rate limits, and the response shape (counts vs. lists).

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

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

Front-loads the core purpose and packs high-value state semantics into a few sentences with little waste. The mid-sentence parameter notes ('conference: optional UrlSegmentName...') interrupt the flow slightly but remain efficient.

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 2-param tool with no annotations and no output schema, the description covers purpose, statefulness, and both parameters adequately. Remaining gaps are minor: the concrete return format of the delta and any failure modes are unspecified.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: 'conference' is described as an optional UrlSegmentName defaulting to all of the user's conferences, and 'acknowledge=false' is explained as a non-advancing peek. The default acknowledge=true behavior is only implied, not stated explicitly.

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 precise verb+resource: 'What changed since the last time get_delta was called', then enumerates the change types (status changes, reviews, submissions). This is clearly distinguishable from siblings like list_submissions and get_reviews, which report current state rather than a delta.

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 real usage context: it is stateful (first call only records a baseline), and 'acknowledge=false peeks without moving the baseline forward.' It does not, however, explicitly name a sibling alternative or state when-not-to-use this tool (e.g. first-time users who want current state should use list_submissions).

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely valuable trait: results are access-scoped to what the author can see, and the payload includes review Q/A text. However, it says nothing about the 'refresh' parameter's caching/staleness behavior or result ordering, which are exactly the traits an agent needs for this kind of fetch.

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 tight sentence with no filler, and the most important qualifier (author-visible scope) is front-loaded. It sacrifices a little clarity for brevity by omitting the subject/verb framing.

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?

An output schema exists, so return values need not be explained, and the description correctly covers the resource and its visibility scope. But it leaves parameter semantics, refresh semantics, and any usage context unaddressed, which is thin for a tool with zero annotations and zero schema descriptions.

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

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

Schema description coverage is 0% across three parameters, so the description would need to compensate and does not. In particular the non-obvious 'refresh' flag (likely cache bypass) is left completely undefined in both schema and description.

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

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

Names a specific verb (get) and resource (reviews) and adds useful scope: reviews 'visible to the author for a submission', including question/answer text. It's clearly distinct from siblings like list_submissions or get_submission, though it never explicitly differentiates itself from them.

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

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

There is no guidance on when to call this versus alternatives such as get_submission or list_submissions, nor any prerequisites. The phrase 'visible to the author' implies a permission context but stops short of stating when this tool is the right choice.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists what data is returned, which is useful, but omits key behaviors such as read-only status, permission needs, caching/refresh semantics implied by the refresh parameter, and error handling.

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, front-loaded sentence fragment with no filler. Every word contributes to describing the returned data, though the fragment format lacks a clear verb and leaves the explanation minimal.

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

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

With no output schema and 0% schema description coverage, the description partially compensates by listing returned fields. However, it does not document required parameters, does not explain the refresh option, and provides no usage context for a tool that requires a conference and submission_id.

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

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

Schema description coverage is 0%, and the description adds no meaning for any of the three parameters. It does not explain conference, submission_id, or the refresh flag, leaving an agent with no semantic guidance beyond parameter names.

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 the resource (submission) and specifies the full set of data returned: authors, abstract, files, subject areas, question answers, dates. It is clearly a detail-fetch tool rather than a list tool, though it does not explicitly contrast itself with siblings like list_submissions or get_reviews.

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 contains no when-to-use or when-not-to-use guidance. It does not mention alternatives such as list_submissions, nor does it explain when a full submission summary is preferable to other retrieval tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state that authentication is required, what the response looks like, or — most tellingly — what the cache-affecting `refresh` flag does; the description never alludes to any caching behavior at all.

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 with no filler. The parenthetical field list is somewhat wasted effort since an output schema already exists, which keeps it from a 5.

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 output schema means return values need not be described, so the parenthetical field enumeration is redundant. What is missing is the authentication requirement and the meaning of `refresh`, both of which an agent needs to invoke this 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?

There is one parameter (`refresh`) with 0% schema description coverage, and the description never mentions it. With low coverage the description is expected to compensate, and here it adds no semantics for the only input the tool takes.

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

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

The description gives a specific verb and resource ("List conferences") plus a clear scope restriction: only those the logged-in CMT user participates in. It does not, however, distinguish this from the sibling search_conferences, so an agent cannot tell from the text alone which to pick.

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 "the logged-in CMT user participates in" implicitly separates this from a general conference search, but there is no explicit when-to-use statement, no mention of search_conferences as the alternative, and no stated prerequisites such as being authenticated.

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

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

With no annotations, the description carries the full burden and does most of it: it discloses result caching (15 min), the refresh override, the cross-conference default scope, and the compact shape of the payload (no abstract/files). It does not cover permissions/auth requirements, which is the main remaining 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?

Front-loads the core action, then handles each parameter and the caveat in tight sentences with no filler. The line-wrapping and parenthetical style are slightly dense, but 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?

An output schema exists, so return values need not be re-explained, and the description correctly stops at describing result shape rather than schema. For a two-param, no-annotation read tool it covers scope, caching, and the alternative sibling, leaving only auth/permission context unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: conference is documented as a UrlSegmentName with a concrete example and a default-scope rule, and refresh is explained as a cache-bypass flag. Format details are adequate; the only omission is whether conference accepts an ID versus a name beyond the single 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?

States a specific verb and resource ('List the user's submissions with status') and immediately scopes what the result contains versus what it omits. It also distinguishes itself from the sibling get_submission by pointing there for abstracts/files, so an agent can differentiate without opening either 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?

Gives clear conditions: omitting conference pulls submissions across ALL conferences, and get_submission should be used when abstract/file detail is needed. It also explains refresh=true as the escape hatch from the cache. It lacks explicit 'when not to use' guidance (e.g. vs get_delta), so it falls just short of the top band.

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

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

With no annotations, the description carries the full burden and does disclose two useful traits: the corpus size (~10k) and that results are paged via top/skip. It omits what an empty query returns, matching behavior (exact vs partial), and any auth/rate-limit 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?

Two short sentences with no filler, and the scope-plus-searchable-fields information is front-loaded before the paging note. Slightly terse given the gaps, but nothing is wasted.

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

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

No output schema and no annotations mean the description must be self-sufficient, and it stops short: it never says what a result record looks like or how query matching works. For a 3-param, zero-documented search tool this is minimal but not 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 0%, so the description must compensate. It identifies top/skip as the paging mechanism and names the fields query searches, but does not define top as page size, skip as offset, or note their defaults (50/0). Partial compensation only.

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 (search) and resource (CMT conferences) with a scale hint (~10k) and enumerates the searchable fields (name, city, country, UrlSegmentName). It is clear what the tool does, though it does not explicitly contrast itself with list_my_conferences.

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

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

There is no explicit when-to-use guidance. The word 'ALL' weakly implies a global search versus the sibling list_my_conferences, but the description never states the alternative or the condition that selects it, leaving the agent to infer.

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