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

Beyond the readOnlyHint annotation, the description discloses blocking semantics, timeout behavior, the return shape ({events, latestCursor, timedOut, waitedS, ...}), and a clear re-arm protocol. It also warns against infinite loops and instructs the agent to tell a human instead, which is exactly the kind of behavioral context annotations cannot 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?

Three dense sentences front-load the core action and then provide the critical protocol. Every sentence earns its place: what it does, how to resume, and how to avoid infinite polling. There is no filler or repetition of schema basics.

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 long-polling tool with no output schema, the description explains the return fields, the timeout edge case, the continuation cursor, and the stopping condition. It covers everything an agent needs to invoke and re-invoke the tool correctly, including a human-escalation path for stale cases.

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 already strong. The description adds genuine semantic value by explaining how `after` relates to `latestCursor`, why `timeoutS` matters for re-arming, and what 'timedOut' means in practice. It does not elaborate on `types` or `caseId`, 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 uses a specific verb ('Block until'), names the exact resource ('a case'), and clarifies the behavior is a long-poll for NEW events. This clearly differentiates it from sibling tools like get_case_activity and await_verdict without needing to open 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?

The description provides explicit operational guidance: omit `after` to watch from now, re-arm with the returned `latestCursor`, and stop re-arming once `caseEndsAt` is well past. It does not explicitly name alternative sibling tools for the 'when not to use' case, but the re-arm and stop-looping protocol is strong and contextually complete.

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?

Even with readOnlyHint=true, the description goes well beyond the annotation: it reveals the instant-return path for already-decided cases, the blocking timeout behavior, the return fields, and the subtle re-open/second-decision edge case. These are meaningful behavioral details an agent would not infer from the schema alone.

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 each sentence carries useful information: blocking semantics, instant return, return shape, and the receipt workflow. It is slightly longer than strictly necessary, mixing workflow protocol into the tool behavior description, but overall it is well-organized and front-loaded with the core blocking behavior.

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 description is complete for a blocking query tool with no output schema: it explains when it returns, what it returns, how to differentiate from await_case_activity, and the required follow-up workflow. The absence of an output schema is compensated by listing the verdict block fields.

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%: both caseId and timeoutS already have clear descriptions in the input schema. The tool description restates timeoutS behavior but adds no new parameter insight beyond 'returns instantly if already decided', which the schema also states. 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 names the exact action—blocking until a case reaches its VERDICT—and distinguishes it from trailing cursors by explicitly contrasting with 'a cursor-await, which would hang forever after closure'. This makes its purpose unambiguous and separable from the sibling await_case_activity.

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 provides explicit when-to-use guidance by contrasting with the cursor-await alternative, and gives a precise post-condition workflow: after the verdict, post a receipt containing the decisionUuid via tribeunal_post_comment, after checking tribeunal_list_comments to preserve idempotency. This is concrete, actionable 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?

The annotations only signal readOnlyHint=false and destructiveHint=false; the description adds meaningful behavioral context: comments appear in the case activity feed, and self-owned arbitration cases cannot be voted on because their verdict is meant for others. This goes beyond what annotations alone provide, though it does not detail failure modes or whether a vote is changeable.

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 core action and optional comment are stated first, and the key restriction is stated second, making it easy for an agent to parse the most relevant information 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 three-parameter mutation with no output schema, the description covers the essential facts: what the vote does, what the comment is for, and when voting is prohibited. It does not explain the return value or duplicate-vote behavior, but the tool is simple enough that this is a minor gap rather than a blocker.

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 extra meaning for the comment parameter by stating it is shown in the case activity feed and clarifying that a vote targets a 'specific side/option,' which enriches the otherwise already well-documented 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 ('Cast') and resource ('a vote on a case for a specific side/option'), clearly distinguishing it from sibling tools like post_comment or revoke_vote. It also adds the option of a short comment, which clarifies the tool's full scope.

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

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

The description clearly implies when to use the tool—when the agent wants to vote on a case—and provides one important exclusion: you cannot vote on an arbitration-mode case you own. However, it does not explicitly compare against alternatives such as revoke_vote or post_comment, so routing guidance is mostly implicit.

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 adds significant behavioral detail beyond the annotations: it pulls the voting deadline to now, triggers the verdict pipeline asynchronously, and explains that abandoning a jury ends in Undecided. It also discloses the arbitration-mode exception and the 'closes on its own at its deadline' behavior, which is valuable 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 dense but well-organized, front-loading the core action and ownership restriction before explaining side effects and exceptions. Every sentence adds relevant information, and 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 destructive async action with no output schema, the description covers the key operational points: eligibility, side effects, async behavior, how to retrieve the result, and edge cases. The information is sufficient for an agent to decide when to call this tool and what to expect afterward.

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 the only parameter, caseId, including the ownership and case-state constraints. The tool description reinforces these constraints but does not add new parameter-specific semantics 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 clearly states the tool's action: closing a case early, and identifies the eligible resources (open cases and jury_selection cases). It also distinguishes itself from related tools by noting the asynchronous verdict pipeline and the follow-up tool to read the outcome.

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 who may use it (case owner or admin), which cases it applies to, and when it cannot be used (arbitration-mode cases owned by the caller). It also gives clear follow-up guidance: use tribeunal_await_verdict to read the outcome.

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 are minimal (readOnlyHint=false, openWorldHint=false, destructiveHint=false), so the description carries the transparency burden and rises to it: it discloses that private cases return a view-only shareUrl, that link-polls are "unlisted everywhere, but readable and votable by anyone you send the link to," and that rotating the shareUrl revokes all old links. This adds genuine post-call behavior the annotations cannot convey, 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?

Four sentences, each earning its place: what the tool does, when to use it, private-visibility behavior, and the link-poll/shareUrl behavior. It is front-loaded with purpose before usage guidance. It loses one point because the private/link-poll content partially duplicates the already-rich visibility and allowsGuestVotes schema descriptions.

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 15-parameter creation tool with 4 required fields and no output schema, the description covers the selection-critical and invocation-critical facts: type semantics, the no-search rule, private-case jury requirements, link-poll behavior, and the private-case shareUrl return value. The exceptionally detailed input schema carries the remaining parameter burden, though the general success response shape (e.g., returned case ID) is not disclosed anywhere.

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, but the description adds meaning beyond per-field schema text: it explains what the type enum actually means in practice (jury decides / creator decides / opinion gathering) and surfaces the cross-parameter interaction that private visibility + allowsGuestVotes = link-poll. It doesn't enumerate all 15 parameters, but it enriches the two most consequential ones.

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?

"Create a new case on Tribeunal for community decision-making" is a specific verb+resource statement, and the parenthetical disambiguation (case = jury decides, advice = creator decides, poll = opinion gathering) gives the type parameter real semantic meaning beyond the title. The explicit "do NOT search first" line also distinguishes this from tribeunal_search_cases and tribeunal_get_case.

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?

"Use this directly when the user wants to start, decide, settle, or put something to a vote and no specific existing case is referenced — do NOT search first" gives explicit when-to-use conditions, a clear boundary condition (no referenced existing case), and an explicit when-not directive against searching. This is exactly the routing decision an agent faces against the search/get siblings, and it is answered directly.

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 annotations (readOnlyHint: false, destructiveHint: false), the description discloses important behavioral details: private tribes are hidden from browsing and search, joinable only by invitation, and return a shareUrl that is view-only and revocable via rotation. This adds genuine context beyond the schema and annotations, though it does not cover all possible side effects or authentication requirements.

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, starting with the core action before explaining the private-tribe nuances. Every sentence adds relevant information, and the shareUrl behavior is explained in a compact but complete way without unnecessary fluff.

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?

Given the lack of an output schema, the description compensates by mentioning that a private tribe answers with a shareUrl. It covers the most important behavioral outcomes (privacy, joining, shareUrl rotation). It could have explicitly stated a general response for public tribes, but the core creation context is well 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 already fully documents all four parameters, so the baseline is 3. The description adds meaningful extra semantics for isPublic, explaining the consequences of setting it to false (privacy, invitation-only, shareUrl behavior). This goes beyond the schema's 'Whether the tribe is publicly visible' and justifies a higher 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 opens with a specific verb and resource, 'Create a new interest-based tribe,' which clearly states the tool's function. It also distinguishes this creation tool from sibling tools like tribeunal_get_tribe, tribeunal_list_tribes, and tribeunal_join_tribe by focusing on the act of creation. The additional detail about public/private tribes reinforces the purpose without ambiguity.

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: it explains when to set isPublic to false for a private tribe and describes the implications (hidden from browsing, joinable by invitation). It does not explicitly name alternative tools or state when not to use this tool, but for a creation operation with no direct sibling, the guidance is sufficiently 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 only say readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden and fully exceeds it: one-time signing secret, exact hmac_sha256 verification formula with timestamp and hex format, 3 retries with backoff, at-least-once delivery requiring dedup on X-Tribeunal-Delivery, URL restrictions (no private/loopback/link-local/CGNAT), and the 10-endpoint cap. 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?

One dense paragraph of roughly 100 words, front-loaded with the core purpose and then flowing logically through scope, security, delivery semantics, URL restrictions, and limits. Every sentence earns its place; the security and delivery details are dense but necessary for correct invocation and safe handling of delivered events.

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 output schema, the description is complete: it covers what to provide (url, events), the constraints on those values, and the critical response detail (signing secret shown only once, with the verification formula). An agent has everything needed to create the webhook correctly and process its deliveries, so the absent output schema does not create a 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it tightens the url semantics (must be absolute https, must not resolve to private/loopback/link-local/CGNAT addresses) and contextualizes events as owner-scoped. These extra constraints and scoping information justify an above-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 opens with a specific verb+resource: 'Register a URL that Tribeunal will POST your cases' events to...' which clearly states what the tool does and its benefit (react without polling). It is unambiguously distinguishable from siblings like tribeunal_list_webhooks and tribeunal_delete_webhook because the verb and effect (registering a delivery endpoint) are specific and unique among 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?

The 'react without polling' framing gives clear context for when to prefer webhooks over polling-based siblings like await_case_activity or get_case_activity, and the owner-scoped note clarifies the delivery model. However, it does not explicitly name sibling alternatives (list_webhooks, delete_webhook) or state when NOT to use this tool, so it stops short of full when/when-not 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 flag destructiveHint=true, but the description adds substantial beyond-annotation context: deliveries stop immediately, the signing secret is destroyed, a re-registered URL gets a new secret, old receivers fail verification, and non-owned endpoints return 404 to avoid leaking existence.

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 carry dense, relevant information with no filler. The primary action is front-loaded, followed by immediate consequences and a privacy-relevant edge case.

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 destructive tool with no output schema, the description covers the action, immediate effects, security implications, and failure semantics. Nothing needed for invoking or understanding the call is missing.

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

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

Schema coverage is 100%, and the schema already states the webhookId is the 'Webhook endpoint UUID to delete.' The description reinforces ownership and the URL concept but adds little new parameter-specific meaning 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 uses a specific verb and resource: 'Permanently delete one of your webhook endpoints.' It clearly distinguishes deletion from the neighboring create_webhook and list_webhooks operations even without naming 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?

The intended use is implied clearly: call this when you want to permanently remove a webhook endpoint you own. However, it does not explicitly mention alternatives or conditions like 'use create_webhook to re-register,' so the when-vs-alternative guidance is only implied.

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

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: private cases you own return a shareUrl, the link is view-only (no voting/joining), and links can be rotated to revoke. This adds permission and security-relevant context 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 concise and front-loaded with the core purpose, then adds one targeted behavioral note about shareUrl. Both sentences earn their place 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 covers the essential use and an important edge case (private-case shareUrl). It does not enumerate response fields or error conditions, but the low complexity and read-only annotation make the definition sufficiently 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 already documents the sole parameter with a clear description including the UUID pattern and the note about using the case uuid rather than the numeric id. Schema description coverage is 100%, so the tool description does not need to add parameter detail, and it provides none.

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: 'Get detailed information about a specific case.' It distinguishes itself from search/list tools by emphasizing a single specific case, though it does not explicitly name sibling alternatives like get_case_activity.

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: whenever detailed information about a specific case is needed. It adds context about private-case shareUrl behavior, but it does not explicitly address when not to use it or how it compares to alternatives such as search_cases or get_case_activity.

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 indicate readOnlyHint=true, and the description reinforces this with a read-only, non-blocking operation. It goes beyond annotations by disclosing the exact return shape: events[], per-event cursor, latestCursor, hasMore, and a verdict block, including the condition under which the verdict is non-null.

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 dense sentences: the first states the operation, the second describes the response contract, and the third gives routing guidance. Every sentence contributes unique value and the most important usage distinction 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 read-only paginated feed with no output schema, the description fully explains what the caller gets back, how to continue paging, and when to choose an alternative. Combined with the 100%-covered input schema and read-only annotation, 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 schema already fully documents caseId, after, limit, and types. The description mentions cursor-based pagination and event types, but it does not add parameter-level detail beyond what the schema provides. Baseline 3 is appropriate given the 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 opens with a specific verb and resource: 'Read a page of a case's activity feed,' and enumerates the event types involved (votes, comments, evidence marks, jury joins, closure). It also names the sibling tools it should not be confused with, making the purpose immediately distinguishable.

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 states when to use this tool: 'for a one-shot read,' and tells the agent to use tribeunal_await_case_activity or tribeunal_await_verdict when blocking is needed. This directly addresses tool selection among closely related siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description aligns by describing a read-only profile retrieval. It adds useful context not present in annotations: the operation concerns the authenticated user, implying authentication is required and that this is a safe, non-mutating call.

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 conveys the action, resource, and scope with no unnecessary words. It is exactly as concise as the tool's simplicity allows.

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, the description is largely complete: it names the resource and the authentication context. A small gap is that it does not reference tribeunal_get_user as the alternative for non-current users, and it does not enumerate profile fields, but neither is essential 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 tool has zero parameters, so there is nothing for the description to explain. The empty schema and parameter count fully align with the description, making the baseline of 4 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 clearly states a specific verb ('Get') and resource ('profile information for the currently authenticated user'), which distinguishes it from the sibling tribeunal_get_user that likely targets a different user. The 'currently authenticated' qualifier removes ambiguity about which user is being accessed.

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 makes the usage context explicit: use this tool when you need profile data for the currently authenticated user. It does not explicitly mention tribeunal_get_user as an alternative for other users, but the phrase 'currently authenticated' strongly implies the intended scope.

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 richly supplements the readOnlyHint annotation by disclosing actual behavioral details: private tribes return 404 to unauthorized users, the shareUrl appears only for owned private tribes, it is view-only, and rotating it revokes old links. These are important, non-obvious behaviors an agent needs to know.

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 response contents and then adds exclusion, visibility, and shareUrl details. Every sentence contributes essential behavioral information, and nothing is redundant or 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?

For a single-parameter read-only tool with no output schema, the description is exceptionally complete: it lists response fields, states what is excluded, clarifies access control and 404 semantics, explains the shareUrl feature, and mentions how to revoke links. No critical 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?

The input schema already fully documents the single parameter, including the UUID format and the note that it must be the uuid field, not slug or numeric id. The description does not add additional parameter-specific semantics, so the baseline score of 3 for 100% schema coverage 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?

Description clearly states the operation ('Get a tribe') and the exact resource fields returned: name, description, visibility, owner, tags and timestamps. It also explicitly distinguishes itself from tribeunal_list_tribe_members by noting the member roster is not included, which helps an agent differentiate from a closely related sibling 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?

Provides explicit guidance on when to use this tool versus tribeunal_list_tribe_members for the roster, and details visibility rules for private tribes including the 404 behavior and who can read. This goes beyond generic usage and clearly routes the agent to the right 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?

The readOnlyHint annotation already communicates that this is a safe read operation. The description adds that the data is 'public profile information,' which is useful, but it does not disclose error cases, authentication needs, or return behavior. This is acceptable for a simple getter but is not rich 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 a single, front-loaded sentence with no filler or repetition. Every word contributes to understanding what the tool does.

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 getter with a readOnlyHint and no output schema, the description is mostly complete: it identifies the resource, the target user, and the public nature of the data. It could be slightly stronger by explicitly pointing to get_current_user, but nothing critical 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 the single parameter as 'User ID or username' with 100% coverage. The description's phrase 'specific user' reinforces the parameter's purpose 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 states a clear verb and resource: it retrieves public profile information for a specific user. It is distinguishable from tribeunal_get_current_user through the phrase 'specific user,' though it does not explicitly name that sibling or contrast with it.

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 makes it clear this tool is for looking up a particular user's public profile by ID or username, which gives an agent useful context. It does not explicitly state when not to use it or mention get_current_user as the alternative, but the intended use is inferable 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?

The readOnlyHint annotation already signals a safe read operation; the description adds only the 'real-time' qualifier, which hints at data freshness but reveals little else. It does not clarify what kind of statistics are returned or whether the data is computed on demand, and there is 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?

The description is a single front-loaded sentence with no filler, which is appropriately concise for a one-parameter read-only getter. It slightly under-delivers on context, but the structure itself is 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 simple getter with one required parameter and a read-only annotation, the description gives enough to attempt a call, but 'voting statistics' is vague and there is no output schema to clarify the return shape. It would be more complete if it described whether the stats are counts, percentages, per-juror breakdowns, or something else.

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 caseId parameter is already documented with a UUID pattern and descriptive text. The description adds no additional meaning beyond restating that the stats are 'for a case,' leaving the baseline of 3 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 clearly identifies the action ('Get'), the resource ('voting statistics'), and the scope ('for a case'), making the tool's basic purpose evident. However, it does not explicitly distinguish this from siblings like tribeunal_get_case_activity or tribeunal_await_verdict, so it stops short of full differentiation.

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 'for a case' implies the tool should be used to retrieve live voting data about a specific case, but there is no explicit guidance on when to choose it over alternatives or when not to use it. No sibling tools or exclusions are mentioned.

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

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

Annotations only say readOnlyHint=false, destructiveHint=false, so the description carries the behavioral burden and exceeds it: it reveals the no-accept-step seating behavior, the independent per-invitee processing, the duplicate/not_found reporting, and the privacy-critical shareUrl behavior for private cases. That shareUrl disclosure is the kind of behavioral context annotations never encode.

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 earns its place; the most actionable constraint (owner/admin required, at least one of invitees/tribeId) is front-loaded. It is somewhat long relative to typical tool descriptions, but given the non-obvious seating behavior and the private-case shareUrl pitfall, the length is justified rather than padded.

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

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

For a write-like tool with no output schema, the description covers prerequisites, parameter selection rules, per-invitee outcome reporting, and the response's shareUrl nuance. There are three parameters, all documented in both schema and description, and no enums or nested objects. Nothing an agent needs to invoke this correctly and use its output well 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 already 100%, so the baseline is 3, but the description adds meaningful semantics: invitees are processed independently with per-entry outcomes, tribeId behavior is expanded to 'every current member plus the chieftain', and the response's shareUrl semantics for private cases are explained. It tells the agent that for a private case, giving the bare url 404s, which is decisive for how the agent uses the returned values.

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 — 'invite users to the jury of a case you own (owner or admin only)' — and immediately distinguishes the tool from sibling jury tools like tribeunal_join_jury and tribeunal_jury_duty_accept by framing invitations as recruitment, not acceptance. It clearly differentiates from tribeunal_invite_tribe_members by targeting case juries rather than tribes.

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?

States explicit preconditions: ownership/admin on the case, and membership/ownership/admin on the tribe. It explains when to use tribeId vs invitees, that at least one is required, and gives a clear when-not: opening the case page seats the invitee as a normal juror without a separate accept step. This makes selection against the sibling jury tools 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 only show readOnlyHint=false and destructive=false, so the description carries the behavioral burden. It discloses meaningful traits: partial success per invitee, exact outcome categories, automatic acceptance on page visit, explicit join via API, and the 400 for public tribes. This is rich, useful context beyond the raw 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 core purpose appears first, then batch behavior, then acceptance mechanics, then the public-tribe restriction. Every sentence contributes a distinct piece of information 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 only two simple parameters and no output schema, the description covers the essential operational context: authorization requirements, private/public constraints, per-invitee resolution, and possible outcomes. An agent has enough information to call the tool 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?

The schema already documents both parameters at 100% coverage, which earns the baseline. The description adds value by explaining that invitees are resolved independently and each gets its own outcome, which changes how an agent should reason about batch failures. It reinforces the tribeId UUID/private-tribe constraint already in the schema.

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

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

The description states a specific verb ('invite'), a specific resource ('PRIVATE tribe you own, or any as an admin'), and the input method ('by username or email'). It also distinguishes this from public-tribe join flows by explicitly saying public tribes return 400.

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 specifies when this tool is appropriate: inviting people into a private tribe, with admin override. It also says public tribes are already open and invitations there return 400. It does not explicitly name alternative sibling tools like join_tribe or invite_jurors, but the context provides enough 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 only say readOnlyHint=false and destructiveHint=false, so the description carries the safety burden. It adds behavioral context: the server does not check the invite list, meaning the client must self-police invitation validity. This is a meaningful disclosure beyond structured fields, though it doesn't detail what happens on success, idempotency, or duplicate-seat behavior.

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

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

Three sentences deliver action, usage conditions, an alternative, and a critical warning with no waste. The core meaning is front-loaded and every sentence contributes.

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 low-complexity single-parameter tool with a documented schema, adequate annotations, and a description that covers when, when-not, and a behavioral caveat. Nothing an agent needs to correctly invoke it 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?

With one parameter and 100% schema coverage (caseId described as 'Case UUID of the jury to join'), the schema already fully documents the parameter. The description does not add extra param semantics, so the baseline of 3 applies.

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

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

The description opens with 'Seat yourself on a case's jury,' which states a specific action and resource. It also distinguishes from voting directly for public juries, so the tool's place among siblings (like cast_vote) is 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?

The description explicitly says when to use the tool ('when you hold an invitation to an invited-jury case, or a wait-mode case needs jurors'), when not to use it ('public juries need no seat — vote directly'), and adds a cautionary rule about not joining uninvited juries. This is complete 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 already flag it as a non-read-only, non-destructive mutation, and the description adds genuinely useful behavior beyond that: private tribes require a pending invitation, and joining without one returns a 404 indistinguishable from a nonexistent tribe. This prevents the agent from misinterpreting a 404 as a bad tribeId.

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 tight sentences with the core purpose first and the key edge-case behavior second. Every sentence earns its place with zero 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 mutation with full schema coverage and safety annotations, the description covers the main gotcha (private-tribe 404 ambiguity) that could trip up an agent. Minor gaps remain — behavior when already a member and the return format, given no output schema — but they are secondary for a simple join action.

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%: the tribeId parameter is fully documented with a UUID pattern and the instruction 'not its slug or numeric id'. The description adds no parameter-level detail, so the schema carries the burden; 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 states a specific action — 'Join a tribe' — with a clear verb and resource. The action is naturally distinct from sibling tools like leave_tribe, get_tribe, and create_tribe, though no sibling is explicitly named.

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

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

Usage context is implied through the invitation-only note, which tells the agent this tool succeeds for public tribes or pending invitations and fails with 404 otherwise. However, the description never explicitly addresses when to choose this over siblings like leave_tribe or invite_tribe_members.

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 indicate readOnlyHint=false and destructiveHint=false, and the description does not contradict them. However, it adds little behavioral context beyond restating the action: it does not explain what accepting changes, whether it can be undone, or any downstream effects.

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

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

The description is a single, concise sentence that is front-loaded with the action and includes the resource and purpose. There is no wasted wording 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 action, the description plus schema cover the input adequately. However, since there is no output schema, the description does not clarify what happens after acceptance or what result the agent should expect, leaving the behavioral outcome under-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?

Schema description coverage is 100%, and the memberId parameter is clearly described as 'Member ID from the jury assignment'. The description does not add extra parameter detail, but the schema already carries the necessary 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?

The description uses a specific verb ('Accept'), identifies the resource ('jury duty assignment'), and states the purpose ('to serve on a specific case'). This clearly distinguishes it from sibling tools like jury_duty_reject, jury_duty_cancel, and jury_duty_start.

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 tool's usage is implied: call it when you want to accept a jury duty assignment. However, the description does not explicitly mention alternatives or when not to use it, such as choosing jury_duty_reject or jury_duty_cancel instead.

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 establishes that this is a safe read operation. The description adds concrete context by listing the returned data points and the reset time, which goes beyond what annotations provide. No contradiction exists.

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 with no filler or repetition. Every clause adds specific, useful information about what the tool returns.

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 info tool, the description covers the essential returned content: usage counts, active jury count vs limit, and reset time. It is sufficiently complete, though it could more clearly distinguish itself from sibling jury-duty tools.

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

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

The tool has zero parameters and an empty schema, so there are no parameter semantics to document. With 0 parameters, a baseline of 4 is appropriate, and the description does not need to compensate for schema gaps.

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 'Get' and the resource 'daily jury duty allowance info', plus the exact fields returned: requests used/remaining, active jury count vs limit, and reset time. It is clear and distinct from siblings like jury_duty_dashboard or jury_duty_status, 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 implies the use case: checking daily allowance and remaining quota for jury duty. However, it does not explicitly say when to use this tool instead of sibling tools such as jury_duty_dashboard or jury_duty_status, nor does it provide exclusions.

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 annotation set is minimal, so the description carries the behavioral burden. It discloses the primary effect (canceling the search request) and adds useful details about the refund policy for same-day cancellations. It could mention reversibility or confirmation behavior, but the provided information is adequate.

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

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

The description is compact, with the primary action front-loaded in the first sentence and the secondary refund condition in the second. Every sentence adds meaningful information without 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 zero-parameter cancellation tool, the description gives enough context to invoke it correctly: it targets an active search request and clarifies the financial consequence. It does not specify the return value or failure modes, but the simplicity of the operation makes this a minor omission.

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, and schema coverage is effectively 100% since the input schema is empty. The description does not need to explain parameters, and the absence of parameter details is not a gap.

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

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

The description clearly states the action (cancel) and the resource (an active jury duty search request). It distinguishes itself from sibling jury duty tools like start, accept, reject, and status by specifying the cancellation action and the active-request scope.

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

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

The description provides clear context that the tool is for canceling an active jury duty search request, which signals when it should be used. It does not explicitly name alternatives, but no sibling tool offers the same cancel functionality, so the lack of exclusions is acceptable.

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, so no destructive side effects need explaining. The description adds value by disclosing what the response will contain and clarifies that case assignments are cases to vote on, which is useful 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?

Two compact sentences, each earning its place: the first states the action and content, the second sharpens selection. There is no repetition of the schema 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 parameter-free, read-only dashboard with no output schema, the description communicates the return contents and the primary use case clearly. An agent can decide whether to call this tool instead of the more specific jury-duty siblings.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter-level burden for the description to carry. The baseline for parameter-free tools 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 starts with a concrete action and resource ('Get jury duty dashboard') and enumerates the dashboard's contents: case assignments, allowance info, active request status. The closing line ('Best tool for finding cases assigned to you') makes its purpose unmistakable and separates it from the surrounding jury-duty siblings.

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

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

It gives a clear usage context and a selection rule: use this when you need cases assigned to you. It does not explicitly name alternative tools or say when not to use it, but the dashboard's composite scope is enough to guide 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the time-window scoping but does not disclose what the returned history contains, how records are ordered, or whether pagination applies. 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?

A single sentence that front-loads the action and resource, then adds the key window constraint. There is no filler or redundant content beyond the schema values, which are brief and acceptable.

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 is mostly adequate: annotations cover safety, schema covers parameters, and the purpose is clear. However, with no output schema and no explicit routing among the many jury-duty sibling tools, a bit more context about expected return data or when not to use this tool would make it fully complete.

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

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

The input schema already fully documents the 'days' parameter with type, default, minimum, maximum, and a descriptive sentence. The description merely repeats the default and max values without adding new semantic meaning, so it stays at the baseline for 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 uses a specific verb ('Get') and a specific resource ('jury duty allowance usage history') with a clear time window ('past N days'). This differentiates it from sibling tools like tribeunal_jury_duty_allowance, which likely returns current allowance, and tribeunal_jury_duty_status or dashboard.

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 context of retrieving historical usage is clear, but the description does not explicitly say when to prefer this tool over siblings such as tribeunal_jury_duty_allowance or tribeunal_jury_duty_status. Usage guidance is implied by the word 'history' rather than stated with alternatives or exclusions.

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 destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds useful behavioral context: the action is not just a rejection but also returns the juror to the queue for a different case. This goes beyond the bare 'reject' concept.

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 with the core action stated first and the consequence immediately following. There is no filler, repetition, or unnecessary detail.

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 destructive action with annotations, the description gives enough to understand the operation and its immediate effect. It could mention prerequisites like whether an active assignment is required, but the invocation context is otherwise 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 schema fully documents memberId as 'Member ID from the jury assignment' with 100% coverage. The description does not add parameter-specific guidance, but with full schema documentation, 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 names a specific action ('Reject') and a specific resource ('jury duty assignment'), and adds a meaningful consequence ('return to the queue for a different case'). This clearly distinguishes it from sibling tools like jury_duty_accept or jury_duty_cancel, even without naming them explicitly.

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

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

The description clearly places the tool in the context of declining a jury assignment and being requeued. It does not explicitly state when not to use it or name alternatives such as cancel/accept, but the context is clear enough for an agent to select it for the rejection flow.

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 provide no safety profile details beyond readOnlyHint=false, so the description carries the burden of disclosing side effects. It adds meaningful behavioral context: joining the matchmaking queue and consuming 1 daily allowance. This goes beyond what annotations alone reveal, though it does not cover edge cases like already being in the queue.

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 deliver the core action, the expected outcome, and the resource cost with no wasted words. The key information is front-loaded and easy to parse.

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 parameterless, low-complexity tool, the description is largely complete: it explains what happens, the purpose, and the cost. It omits behavior for already-active sessions and return format, but no output schema is defined, and the use case is simple enough that these are minor gaps.

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

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

The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to explain. The description appropriately avoids inventing parameter-related details that would be irrelevant.

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: 'Start a jury duty search' and 'join the matchmaking queue to be assigned to a case needing jurors.' This distinguishes it from sibling tools like cancel, accept, reject, and status. However, it does not explicitly differentiate itself from tribeunal_join_jury, so it stops short of a 5.

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

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

The description gives clear context for when to call the tool: to begin a jury duty session and enter the matchmaking queue. However, it does not explicitly state when not to use it or which sibling tools might be alternatives for related actions, leaving usage guidance implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Get' without contradicting it. It adds useful context by listing the specific status fields returned, which is important since there is no output schema. It does not disclose edge-case behavior (e.g., response when no jury request exists), but for a read-only status endpoint 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?

The entire description is a single, front-loaded sentence with no filler. Every phrase conveys a distinct piece of information: status, queue position, and active search/assignment.

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

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

For a no-parameter read-only status tool, the description covers the essential return values, especially given the absence of an output schema. It could be more explicit about default behavior when no jury request exists or about the scope (current user), but the meaning is largely inferable from the wording.

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 and 100% coverage, so the baseline is 4. The description appropriately adds no parameter details since there are none to describe.

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 ('Get') and names the exact resource ('current jury duty request status') plus concrete data points returned (queue position, active search/assignment). This clearly separates it from mutation siblings like tribeunal_jury_duty_start or tribeunal_jury_duty_cancel, though it does not explicitly distinguish from the similarly-named tribeunal_jury_duty_dashboard.

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 checking status but provides no explicit when-to-use guidance or alternatives. With siblings like tribeunal_jury_duty_dashboard, tribeunal_jury_duty_history, and tribeunal_get_current_user, an agent must infer when this specific status check 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?

Annotations already mark this as destructive, and the description adds valuable context beyond that: leaving a private tribe consumes the invitation, prevents rejoin without a new invitation, and is irreversible without the owner's action. This explains exactly what is destroyed and the permanence of the operation.

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, with the primary action first and the critical irreversible consequence immediately after. No filler or redundant restating of the tool name or 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?

This is a single-parameter tool with no output schema. The description covers the operation, the membership precondition, the private-tribe exception, and the consequences. Nothing essential is missing for an agent 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 already fully documents the tribeId parameter with a pattern and a clear note that it must be the UUID, not slug or numeric id. The description does not add parameter-level meaning beyond what the schema provides, which is acceptable given 100% 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 and resource: 'Leave a tribe you are currently a member of.' It clearly identifies the action and distinguishes this tool from siblings like join_tribe, create_tribe, and get_tribe.

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: when the agent/user wants to leave a tribe the user is currently a member of. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for correct selection among siblings.

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

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

Annotations already declare readOnlyHint=true, so the read-only behavior is covered. The description adds practical context (avoid duplicates, find ids) but doesn't disclose return format, ordering, or pagination. This is acceptable given the annotation coverage, but not particularly 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?

A single, front-loaded sentence that explains both the core action and two key use cases. Every word 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 simple read-only list tool with one parameter and no output schema, the description is adequate: it names the action, the target, and what the results are useful for. It doesn't cover edge cases or output shape, but those are minor for this straightforward 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?

Schema description coverage is 100%, and the single parameter caseId already has a clear description ('Case UUID to list comments for'). The tool description adds no new parameter-level meaning, so the 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 states a specific verb and resource: 'List a case's comments'. It also distinguishes the tool from siblings like list_evidence by mentioning comment ids, and from post_comment by framing it as a way to avoid duplicates.

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 gives usage context: use it to avoid posting duplicates and to find comment ids for evidence marking. This tells the agent when to call it relative to post_comment and mark_evidence, though it doesn't explicitly name alternatives or state exclusions.

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 the description adds useful context about what 'evidence' means here: comments and case files marked by the owner/jury. This goes beyond the annotation by scoping the read operation to a specific subset of case 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?

One concise sentence that is front-loaded with the core action and resource, then clarifies the evidence kinds. Every clause earns its place with no redundant wording.

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 one well-described parameter and no nested objects, the description is adequate. It does not specify the exact return shape, but the nature of the resource ('comments and case files') gives enough context for an agent to infer the result.

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 single caseId parameter with a clear description, so the schema carries the semantic burden. The tool description adds no significant parameter detail beyond what is already in the schema, matching 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 uses a specific verb ('Get') and resource ('a case's marked evidence'), and further clarifies the content type ('comments and case files ... kind: comment|file'). This clearly distinguishes it from sibling tools like list_comments or mark_evidence.

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 makes clear that this is for marked evidence only, which implies the context where it should be used. However, it does not explicitly name alternatives such as list_comments or explain when the agent should prefer one over the other.

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 discloses important privacy/error behavior: unauthorized access returns 404 for private tribes or 403 for public tribes you are not in, and it never exposes emails, credentials, or share tokens. This provides context that annotations alone cannot convey, helping the agent anticipate failure modes and sensitivity.

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?

Every sentence earns its place: the first defines the output payload, the second explains access controls and error semantics, the third gives a practical usage scenario. It is detailed yet compact, with 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?

Even without an output schema, the description fully covers the returned fields, access restrictions, error behavior, data privacy guarantees, and a suggested workflow use case. The pagination parameters are already in the schema, so nothing critical is missing for an agent to select and invoke this 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%, with tribeId, page, and limit all already documented in the input schema. The description does not add any parameter-specific details beyond what the schema provides, so it hits the baseline of 3 without requiring compensation.

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 'List who is in a tribe' and enumerates the exact roster fields (chieftain, each member's username, role, AI status, join date), making the resource and action unmistakable. It also distinguishes itself from sibling tools like tribeunal_get_tribe and tribeunal_list_tribes by focusing on member roster composition.

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: 'Use this to see a roster before inviting a whole tribe to a case jury' and even references the accepting sibling (tribeunal_invite_jurors). It implicitly communicates access boundaries (members/owner/admins only) but does not explicitly state when to avoid this tool or name alternatives for other roster-like needs.

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 declare readOnlyHint=true, so the agent already knows this is read-only; the description adds meaningful context beyond that: it returns both public and private tribes the user belongs to, supports query search, and explains the uuid-return behavior. It does not describe pagination behavior in detail, but the schema already covers page/limit. Not contradicting 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 with the most important information: scope, then the purpose, then parameter usage, then downstream integration. Every sentence earns its place and there is no dead weight.

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 full schema coverage and no output schema, the description covers the key contextual facts: scope, special behavior (private tribes), parameter intent, and integration with a sibling tool. Nothing necessary for invoking 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?

Schema description coverage is 100%, so the parameters are already documented. The description does add meaning by explaining what 'query' is useful for ('search by name or description') and implies the pagination params, but it does not add much beyond the schema.

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

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

The description states a specific action ('List tribes on Tribeunal') and delineates the scope ('every public tribe plus the private tribes you own or belong to'). It also distinguishes itself from a potential sibling by noting there is no separate 'my tribes' tool, and it ties the tool's output to a concrete downstream use (pass a uuid to tribeunal_invite_jurors).

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 explains when to use this tool: to find your own tribes and to resolve a tribe name to its uuid. It also points to an alternative action ('there is no separate my tribes tool') and tells the agent what to do with the returned uuid, which is clear 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 already declare readOnlyHint=true, but the description adds meaningful behavioral detail: it never returns signing secrets, and it exposes delivery health fields. This goes beyond the annotation's safety signal and helps an agent understand what this endpoint will and will not 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 sentences with no filler. The core listing behavior is front-loaded, and the important exception about signing secrets is placed immediately after, followed by the practical use case.

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 parameters, no output schema, and read-only annotations, the description carries the responsibility for explaining the operation's results. It covers what is returned, what is intentionally excluded, and the primary use case, making the tool fully callable by an agent.

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

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

The tool has zero parameters and schema description coverage is 100%, so there are no parameter gaps for the description to fill. The 4 baseline for zero-parameter tools applies, and the description adds relevant context about the returned payload instead of parameter 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 names a specific verb and resource: 'List your registered webhook endpoints.' It also enumerates the returned data (subscribed events, active status, delivery health), which clearly distinguishes it from create_webhook and delete_webhook among the 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?

The description gives a concrete use case: 'Use this to find an endpoint's uuid before deleting it.' It also clarifies when signing secrets are available, implicitly directing agents to endpoint creation or secret rotation rather than this listing tool. It does not explicitly name alternatives or when-not-to-use, but the guidance is clear.

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

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

The description adds significant behavioral context beyond the annotations: it explains who is allowed to mark, prohibits marking your own comment, and reveals a tricky 403 error interpretation ('evidence_frozen' = record closed, not permission denied). This prevents costly retries and clarifies a non-obvious API behavior.

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

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

Two dense sentences carry all essential information: main purpose, role constraint, self-marking prohibition, and a critical error-handling nuance. No fluff, and the most important behavior 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 mutation tool with no output schema, the description fully equips an agent to call it correctly: what to mark, who may mark, what cannot be marked, and what a specific error means. No critical context 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 meaningful semantic detail by clarifying the id must reference another user's comment, and that kind 'file' refers to a case file. This complements, rather than restates, 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 the exact action ('mark as evidence'), the specific targets ('another user's comment or a case file'), and the actor/role restriction. This clearly differentiates from sibling tools like unmark_evidence and list_evidence.

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 explicit when-to-use context through role restrictions ('case owner or jury members only') and a clear when-not-to-use signal: if the case has left open, do not retry because the 403 evidence_frozen means the record is closed. This is actionable guidance beyond 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 signal a non-read-only, non-destructive write. The description adds behavioral context beyond annotations by stating that comments appear in the case activity feed and can later be marked as evidence by the case owner or jury. This helps the agent understand the downstream visibility and significance of the action.

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 with no wasted words. The primary action is front-loaded, the voice/usage intent is stated immediately, and the consequence is added in the second sentence. Every part 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 two-parameter write tool with full schema coverage and annotations already covering the read-only/destructive profile, the description is complete. It explains what to post, where it appears, and the potential evidentiary role, while the schema handles all required arguments.

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 has 100% coverage with clear descriptions for both caseId and text. The tool description does not add additional parameter-level semantics, 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 states a specific action and resource: 'Post a comment on a case.' It clarifies what kind of content is expected ('your analysis or perspective, in your own voice') and distinguishes this from sibling tools like list_comments, cast_vote, and mark_evidence.

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 it when you want to add your own commentary or analysis to a case, and it explains that the comment appears in the activity feed. It does not explicitly name alternatives or exclusions, 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 indicate this is a non-read-only, non-destructive action, so the description does not need to re-establish the mutation profile. It adds a useful input-scope constraint (evidence IDs only), but does not disclose whether a rating overwrites a previous rating, whether repeated ratings are allowed, or any other side effects.

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 short sentences with no filler. The core action and rating values are front-loaded, and the important constraint about comments is stated directly afterward.

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 rating action, the description covers the essential purpose, accepted values, and a key input restriction. The schema covers required parameters, and no output schema is expected. Minor gaps include re-rating behavior and the purpose of sideId, but these are not critical for basic 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 already documents all parameters with 100% coverage, including the rating enum. The description adds a helpful restriction on evidenceId ('file-evidence ids only') and comments-not-ratable guidance, but otherwise relies on the schema for 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?

The description clearly states the action ('Rate'), the resource ('case-file evidence'), and the exact rating scale (1/0/-1). It also distinguishes what is not ratable ('comments are not ratable'), though it does not explicitly contrast this with sibling tools such as mark_evidence or cast_vote.

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 useful context: only file-evidence IDs are accepted and comments are excluded. However, it does not explicitly state when to prefer this tool over alternatives like mark_evidence, unmark_evidence, or cast_vote, so the usage guidance is implied rather than fully explicit.

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

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

Annotations already indicate this is not read-only and not destructive, and the description adds the non-obvious behavioral detail that penalties may apply. It does not explain the nature or severity of penalties, so it stops short of full 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 sentence with the core action front-loaded and the important warning in a parenthetical. Every word 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 two-parameter action with annotations covering safety, the schema and description together are nearly complete. Minor gaps include the vagueness of 'penalties may apply' and no mention of what happens if the caller has not previously voted.

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 both required parameters are already documented with types, patterns, and explanations. The tool description itself adds no additional parameter meaning 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 uses a specific verb and resource ('Revoke a previously cast vote') and is naturally contrasted with sibling cast_vote. The title and description are aligned, so an agent can immediately tell what the tool does.

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 'previously cast vote' implies the tool should be used after a vote has been cast, but there is no explicit guidance about when to use it versus alternatives or what conditions apply. No exclusions or prerequisities are stated.

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 safe read-only nature, so the description does not need to restate that. However, the description adds no additional behavioral context such as pagination behavior, result ordering, or what happens with no filters. It is consistent with the annotations but offers no extra transparency beyond 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 two sentences with no filler: the first states the operation and filters, the second routes to the key alternative. The most important 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 search tool with six optional, well-documented parameters and no output schema, the description plus schema gives sufficient information to select and invoke the tool. The only notable gap is the lack of explicit guidance to use tribeunal_get_case for direct case retrieval, which would make the context fully complete.

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

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

The input schema is fully described (100% coverage), including enums with status meanings, defaults, and constraints. The description only repeats filter dimensions already present in the schema, adding no new semantic detail, so 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?

The description clearly states a specific action ('Find existing cases') and identifies the searchable resources and filter dimensions (query, status, type, tags). It distinguishes the tool from tribeunal_create_case, but it does not explicitly contrast it with tribeunal_get_case, a sibling that could also serve 'look up an existing case' intents.

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 ('only when the user wants to look up or reference an existing case') and names the alternative for creating new cases (tribeunal_create_case). It does not mention using tribeunal_get_case for retrieving a specific known case, so the routing guidance is good but incomplete.

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 annotations, the description discloses meaningful behavior: the image is downloaded and re-encoded server-side, only png/jpeg/webp up to 5 MB are accepted, and http URLs, private/internal hosts, and non-images are rejected. This gives the agent a realistic model of what happens when the tool is invoked.

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 core action, permission, constraints, and identifier guidance are all front-loaded and each clause carries 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?

For a simple three-parameter mutation, the description is nearly complete: it covers ownership, URL requirements, file constraints, server-side processing, and identifier sourcing. A minor gap is that there is no success/error return expectation described, and no output schema exists to fill 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 coverage is 100%, so the baseline is 3, but the description adds value by instructing the agent to derive caseId and sideId from tribeunal_get_case's uuid fields and explicitly warning against numeric ids. This reduces the chance of passing incorrectly resolved identifiers.

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: 'Set or replace the image shown on a case side's vote card.' It is immediately clear what the tool does and what object it affects, and no sibling tool appears to overlap with this operation.

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 important usage context: it is owner-only, the image must come from a public https URL, and callers should use the uuid fields from tribeunal_get_case rather than numeric ids. It does not name alternatives, but no direct alternative exists among the siblings, so this is clear enough.

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 adds valuable behavioral context beyond the annotations: it discloses the 403 evidence_frozen edge case and instructs not to retry. This complements readOnlyHint=false and destructiveHint=false by explaining how the system behaves in a specific state. It does not contradict 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 two sentences with no filler. The first sentence immediately states the action and permission, and the second sentence delivers a crucial error-handling nuance. 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 simple mutating tool with no output schema, the description covers the essential operational details: what is removed, who can do it, and a critical failure scenario with explicit guidance. The one minor gap is that it does not describe the expected success response, but for a low-complexity action this is not a significant omission.

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 describes both parameters fully, with id as a UUID and kind as an enum of 'comment' or 'file.' The description echoes 'comment or case file' but adds no meaning beyond what the schema provides. Baseline 3 is appropriate given the 100% schema description 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 and resource: 'Remove an evidence mark from a comment or case file.' This clearly identifies the operation and differentiates it from sibling tools like tribeunal_mark_evidence and tribeunal_list_evidence. The permission qualifier '(case owner or jury members only)' adds further precision.

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 the tool is applicable: only for case owners or jury members, and it explicitly warns that on arbitration-mode cases, once the case leaves open, the evidence record freezes and 403 evidence_frozen means the record is closed rather than a permission failure. It does not name specific alternative tools, so it falls short of a 5, but the guidance is strong.

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