Callpaymin

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is partly covered. The description adds genuinely new information not present in structured fields: the confirm gate that makes the call a no-op by default. It does not explain why the operation is flagged destructive or whether the link can later be removed, so it is not a 5.

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

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

Two short sentences with the effect and the gating condition front-loaded; nothing is buried. "Uses the existing referral linker" is implementation detail that adds little for an agent choosing or invoking the tool.

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

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

For a destructive, idempotent mutation with no output schema and zero schema coverage, the definition covers the confirm gate but omits what happens on success, whether the link is reversible, and failure modes such as an invalid or already-used code. Adequate to call, not complete enough to predict outcomes.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the confirm flag precisely (no effect unless true), but says nothing about the code parameter beyond the implied "referral code" — no format, length, case-sensitivity or validity notes despite a 4-32 char constraint 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?

"Links your account to a referrer" gives a specific verb and resource that clearly separates this mutation from read-side siblings like get_referral_code and get_referral_stats. It stops short of naming those siblings explicitly, so it lands at 4 rather than 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?

"Does nothing unless confirm=true" is a concrete operational precondition that tells the agent exactly how to make the call take effect, which is the main usage decision for this tool. It does not cover when to prefer this over fetching a code first, nor exclusion cases such as already having a referrer.

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 'destructive' hint provided in annotations, the description explicitly states a critical operational behavior: the tool only performs an action if the 'confirm' parameter is true. This is a vital behavioral detail not captured in the schema or hints.

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 definition is highly concise and impactful. It uses strong, capitalizations ('DESTRUCTIVE') and front-loads the essential operational constraints.

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 covers the scope (user's bookings), the trigger (confirm=true), and the nature of the operation (destructive), leaving no ambiguity about how or when the tool should be used.

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 0% schema description coverage, the description adds significant semantic value by explaining that the operation is conditional on the 'confirm' flag and defining the ownership constraint (user-owned bookings).

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 ('Cancels') and identifies the resource ('a booking'), making the purpose immediately clear to an agent.

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 a clear operational boundary by stating it only cancels bookings the user is part of, helping the agent avoid trying to cancel external bookings.

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 cover read-only, idempotent, non-destructive behavior, so the description's job is to add context — and it does, disclosing the one-minute staleness window and the fact that this is a directory flag rather than a live media presence signal. That is exactly the kind of caveat annotations cannot express.

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, front-loaded with the behavior and immediately followed by the limitation. Nothing is wasted and nothing is buried.

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 tool with full annotation coverage, the caveats are the main missing piece and they are present. However, with no output schema, the description should indicate what the flag actually returns (a boolean value, an object, an availability enum), and it never addresses the only input parameter.

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

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

Schema description coverage is 0%, so the single parameter expertId is documented nowhere; the description never mentions it, its format, or where it comes from. It should have compensated for the schema gap rather than relying on the parameter name being self-explanatory.

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

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

States a specific verb and resource ('reads the directory availability flag') and adds a negative boundary ('not a live media presence check') that separates it from presence-style tools. It stops short of naming the closest sibling, get_expert_availability, so the distinction from that tool must be inferred.

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 staleness caveat ('up to a minute old') implies when the result is acceptable and when the caller needs something fresher, but no alternative tool is named. With get_expert_availability in the sibling list, the description should say which one to prefer in which case.

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 asserts 'Nothing is read or changed', directly contradicting annotations that declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true. An agent reading both signals gets flatly incompatible safety profiles for the same tool. The honesty about the tool being unsupported is useful, but the explicit side-effect contradiction forces the lowest score.

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

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

Three short sentences, each carrying a distinct load: the reason, the support status, and the side-effect guarantee. The critical information (nothing to clear, not supported) is front-loaded with no filler.

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

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

For a stub tool the description covers the essentials — no effect, not supported — and there is no output schema to explain. However, it leaves unexplained why a no-op exposes four parameters including a monetary acknowledgement field, and gives no guidance on whether invoking it is harmless or returns an error, which an agent needs in order to decide between calling and refusing.

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

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

All four parameters (orgId, confirm, idempotencyKey, acknowledgedAmountUsd) have 0% schema description coverage and the description addresses none of them. The description's claim of no effect partially excuses this, but it leaves the agent unable to reconcile why a no-op tool accepts an idempotency key and a dollar amount.

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 precisely what the tool would do (clear a do-not-disturb window) and immediately clarifies that the operation is a no-op because the call router does not read such a window. That is a specific, unambiguous purpose statement that lets an agent identify it as the counterpart to set_do_not_disturb, though it never names that sibling 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?

'This tool is not yet supported' functions as an explicit when-not-to-use directive, which is the single most important routing signal here. It stops short of a 5 because it does not name the alternative an agent should call instead (e.g., set_do_not_disturb or get_my_profile) when a user asks about do-not-disturb settings.

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?

Strong for a stub: it discloses that no rate source exists, that wallet charges are USD, that no invented rate will be returned, and that 'nothing is read or changed'. This adds real behavioral context beyond the readOnlyHint/destructiveHint annotations. Minor tension between 'nothing is read' and readOnlyHint=true, but not a contradiction since readOnlyHint concerns mutation.

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?

Short and front-loaded, but the four sentences largely restate one idea — no rate source, unsupported, no invented rate, nothing changes. The redundancy is tolerable but doesn't earn every sentence.

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 disabled stub, the description is arguably sufficient to prevent a bad call, and no output schema is needed. But with seven undocumented parameters and no pointer to a working alternative, an agent is left without a next step.

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?

Seven parameters at 0% schema description coverage, and the description explains none of them — not 'from'/'to' currency codes, not 'amount' bounds, not 'confirm' or 'acknowledgedAmountUsd'. The description must compensate here and does not at all.

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 name and title say 'Convert currency', but the description never states what the tool does or would do — it only declares that it cannot do it ('not yet supported', 'no foreign-exchange rate source is configured'). An agent learns the tool is a non-functional stub, which is useful, but gains no positive statement of purpose or 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?

Usage is implied rather than stated: 'not yet supported' signals do-not-call. However, it names no alternative — sibling tools like get_supported_currencies or get_wallet_balance would be the natural substitutes, and the description never routes the agent there.

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?

Goes well beyond annotations by disclosing the pending_payment state transition, the 20-minute hold window, and the returned callpaymin.io payment link, plus the explicit safety claim that no card is charged or wallet debited. It does not explain how the idempotencyKey should be used despite idempotentHint=false, which matters for retry safety on a hold-creating 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?

Three tight sentences, front-loaded with the default (quote-only) behavior and then the conditional confirm path. Every clause carries decision-relevant 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 mutating, open-world tool with no output schema, the description supplies the return shape (price vs. payment link) and the lifecycle after the call. Remaining gaps are retry/idempotency guidance and conflict handling, which are real but secondary.

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

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

Schema description coverage is 0%, so the description carries the burden, and it only explains confirm and acknowledgedCostUsd (including that the latter must equal estimatedCostUsd). The other six parameters – expertId, start, durationMinutes, callType, notes, idempotencyKey – get no semantic treatment at all.

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 concrete verb and resource ('Quotes a scheduled call', optionally holds the slot) and makes the two-mode behavior explicit, which is more than the title alone conveys. It does not distinguish itself from the nearby sibling 'estimate_call_cost', which sounds like an overlapping quote operation, so an agent must still infer which one to call.

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

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

It gives an explicit when-to-use split: omit confirm to get a price only, pass confirm=true plus a matching acknowledgedCostUsd to actually hold the slot. It does not state what to do if the price has changed since estimating, nor point to 'estimate_call_cost' as the read-only alternative.

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

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

Annotations already declare readOnly=false, idempotent=true, destructive=true, and openWorld=false. The description adds meaningful behavior beyond those annotations: no billing side effects, a confirm gate that makes the call a no-op unless true, and replay semantics for the idempotency key. It does not explain why destructiveHint is true, but the added context is still substantial.

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 short sentences, front-loaded with purpose and followed by the important behavioral constraints. Every sentence carries useful information with no filler, aside from the slightly awkward 'through the meetings service'.

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

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

There is no output schema, so the description could say what a successful call returns (e.g., a room object or ID). It also leaves maxParticipants and name semantics undocumented, despite zero schema description coverage. The behavioral gating and idempotency notes are good, but completeness for a four-parameter creation tool is only adequate.

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

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

Schema description coverage is 0%, so the description needs to carry parameter meaning. It explains the confirm gate and the idempotency key's replay behavior, which is valuable. But it says nothing about name constraints or maxParticipants, leaving half the parameters semantically undocumented.

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 ('Creates a meeting room') and scopes it to the signed-in expert. It implicitly distinguishes creation from siblings like join_meeting_room and list_my_meeting_rooms, but does not name or contrast those alternatives 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?

It gives a crucial prerequisite ('Does nothing unless confirm=true'), which tells the agent when the call will actually take effect. However, it does not state when to choose this tool over join_meeting_room or list_my_meeting_rooms, nor does it describe any other conditions for use.

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 idempotentHint=true; the description adds genuinely new context that a 'destructive' flag alone would not convey — namely that no money is charged or debited and that the call is inert without confirm. It stops short of describing success/failure outcome or reversibility (whether recharge can be re-enabled).

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

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

Three short sentences, front-loaded with the action and its consequence, then the non-effect, then the precondition. Nothing is redundant.

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

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

No output schema exists, and the description adequately covers what the tool does and does not do. It leaves the return value and error behavior unspecified, which is a small gap for a state-changing wallet 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 0% for the single `confirm` boolean, so the description must carry the load — and it does, stating that nothing happens unless confirm=true, which implies the default and the gate. This is more than 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?

States a specific verb and resource ('Turns off wallet auto-recharge') plus the operational consequence ('so a saved card is not charged later'). No sibling tool touches auto-recharge, and the description makes the scope unambiguous without needing the schema.

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

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

Explicitly states the activation precondition ('Does nothing unless confirm=true'), which is the key usage decision for this tool. It does not name alternatives or when-not-to-use, but no sibling offers an equivalent capability, so the gap is minor.

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 destructive=true, idempotent=true and readOnly=false, and the description adds meaningful context beyond them: no billing or settlement occurs, and the call is a silent no-op unless confirm=true. What is missing is the failure mode for an invalid or already-cancelled callId.

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

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

Three short sentences, all load-bearing, with the scope constraint front-loaded ahead of the caveat. The clause 'that cleanup path bills the live session' is compressed jargon that costs the reader a re-read.

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 two-parameter mutation with no output schema, the definition covers the critical quirks: no charge, no effect without confirm, and no effect on live calls. Only the callId sourcing and error/repeat-call behavior remain unstated.

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

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

Schema coverage is 0%, so the description has to carry both parameters. It effectively defines confirm by declaring the tool does nothing unless it is true, but callId is only indirectly characterized through 'invite you created' — no format, lookup source, or error behavior is given for it.

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

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

The description gives a specific verb and resource ('Cancels an incoming invite you created') and explicitly negates the implication of its own name by saying a connected call is not ended here. That correction is genuinely useful, but the phrase 'incoming invite you created' is internally odd and leaves the exact object being cancelled slightly ambiguous.

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 clearly states the condition under which this is the wrong tool ('A connected call is not ended here') and explains why. It stops short of naming the alternative path for terminating a live session, so the agent knows when not to use it but not what to use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description correctly reinforces that with 'does not book or charge'. It adds the useful detail that the figure is derived from the expert's public per-minute rate, but does not say whether the estimate excludes fees, taxes, or rate-cap adjustments that a real charge might include.

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, zero filler, with the core result (USD estimate) front-loaded and the safety caveat immediately after.

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-param calculation tool with no output schema this is nearly sufficient, but the description never states that the return value is a numeric USD amount, nor whether currency conversion or rate caps affect it. With 0% schema coverage, one more sentence on those points would close the gap.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only loosely implies that expertId selects the rate ('expert public per-minute rate') and that minutes is the multiplier. Nothing explains the 1–180 minute bound, the expertId format, or what happens if the expert is offline.

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

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

States a specific verb and result ('USD estimate') and the basis for it ('expert public per-minute rate'), so the agent knows it is a pure pricing calculation rather than a booking action. It does not name the sibling to use instead, but the phrase 'does not book or charge' already separates it from create_booking.

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

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

There is no explicit 'use when' statement; the only guidance is a negative clarification that it does not book or charge, which implies pre-booking price checking. No alternatives (e.g. get_country_rate_caps, convert_currency) are mentioned for related pricing questions.

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

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

Annotations already declare the profile: non-readOnly, idempotent, non-destructive, closed-world. The description adds a genuine behavioral constraint with 'approved expert', implying the call can fail on a non-approved target, but it never says what happens then or whether the operation is reversible. With annotations carrying the safety profile, this is adequate but thin.

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 short sentence with no filler, front-loaded with the verb. It is appropriately sized for a one-parameter mutation, though the brevity borders on under-specification rather than tightness.

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 with no output schema and zero parameter description coverage, the description should at minimum point the agent to where expertId comes from and relate the tool to unfavorite_expert/list_favorites. Neither is present, so an agent must go outside the definition to call it confidently.

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

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

Schema description coverage is 0% for the single parameter, so the description is the only place meaning could be added — and it says nothing about expertId. It does not indicate that the ID should come from search_experts or get_expert, nor any format or length expectations, leaving the agent to infer the source of the identifier.

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 verb ('Saves') and resource ('an approved expert on your account'), but it is close to a restatement of the name/title 'Favorite an expert'. The only real increments are 'approved' (a prerequisite) and 'on your account' (per-account scoping); it does not distinguish itself from list_favorites or unfavorite_expert, which sit right next to it in the toolset.

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

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

There is no guidance on when to call this versus unfavorite_expert or list_favorites, and no mention of what to do if the expert is already favorited or is not approved. The implied prerequisite ('approved') is stated but not actionable — nothing tells the agent how to verify approval before calling.

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 read-only, idempotent, non-destructive behavior. The description adds only ambiguous notes like "Approval is a profile field" and does not explain what status values are returned, whether expert status is required, or how approval relates to this 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?

The description is short and front-loads the resource name, but the second and third sentences are ambiguous and seem off-topic. They do not clearly earn their 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 zero-parameter read-only tool with rich annotations, the description is minimally adequate for invocation. However, with no output schema, it should explain what the returned application status contains or means; instead it leaves the result shape and approval/profile relationship unclear.

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

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

The tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the schema is fully described.

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

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

The phrase "Your expert application status" identifies the resource, but it does not explicitly state a retrieval verb or distinguish this from siblings such as get_my_profile or submit_application. The following sentences about approval being a profile field and consumer tools do not clarify the tool's specific purpose.

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

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

There is no guidance on when to use this tool versus alternatives, nor any when-not conditions. The statement "Every account can use the consumer tools" is a broad permission note, not a usage guideline for this specific tool.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds useful negative disclosures (no media credentials, no cost estimate) and a self-only access scope, which is real value, but it omits what status values are returned or whether results change as the call progresses.

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

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

Two short sentences with the resource front-loaded, so it is efficient. The second sentence is cryptic ('a guessed running cost') and its relevance is unclear without context, so not every clause clearly 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?

There is no output schema, so the description is the only place to learn what a 'status' contains, and it never enumerates possible states (ringing, active, ended) or the shape of the response. For a status-inspection tool with zero schema coverage and no annotations about returns, this leaves the agent guessing at the primary output.

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

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

The single parameter callId has no schema description (0% coverage), so the description carries the full burden. It only hints that the id refers to a 'call invite' but never says where the callId comes from or whether it accepts a session id versus a booking id, leaving the one required input ambiguous.

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

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

The description identifies the resource (a call invite/session) and implies a status read, plus an access scope ("where you are the caller or the expert"). But it never uses an explicit verb like 'retrieve' or 'get', and it does not distinguish itself from near siblings such as list_my_calls, estimate_call_cost, or end_call, so an agent must infer the boundary.

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

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

There is no statement of when to call this rather than list_my_calls or estimate_call_cost, and no prerequisites (e.g., an active invite or callId obtained from start_call) are given. The only guidance-like content is a negative about return values, which is behavioral rather than usage.

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 claim 'Nothing is read or changed' is consistent with readOnlyHint=true and destructiveHint=false and adds genuinely useful information beyond the annotations: the tool is non-functional and has no side effects. It does not explain why the schema contains confirm, idempotencyKey, and acknowledgedAmountUsd, which could mislead an agent into thinking a charge is involved.

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

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

Three short sentences with the most decisive fact (not supported) placed early, and no filler. Slight deduction for the somewhat indirect opening clause before delivering the actionable point.

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 deliberately unsupported stub, the description supplies the one thing an agent needs: do not call this. Given no output schema and no required parameters, that is largely sufficient, though the unexplained billing-flavored parameters leave a residual ambiguity worth addressing.

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

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

Schema description coverage is 0% across five parameters, and the description explains none of them. In particular, acknowledgedAmountUsd and confirm strongly imply a paid, confirming mutation that an agent would need context on; the absence of any explanation leaves those semantics entirely opaque.

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

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

The description identifies the resource and scope ('AI chat recaps ... for organization sessions') and, crucially, states the tool is not supported, so an agent immediately knows this is a no-op stub. It falls short of a full 5 because it never contrasts itself with the consumer-facing chat siblings (list_my_chats, start_chat) that would be the actual correct routes.

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

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

It gives an explicit when-not-to-use signal ('not a consumer-thread tool', 'not yet supported'), which is the most important routing guidance for this entry. It does not name the alternative tool an agent should call instead, which is why it is not a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful domain context (the value is a per-minute USD ceiling, tiered by country income/region). However, with no output schema it does not disclose the response shape, precision, or what happens for an unsupported country code.

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 no filler, and the core meaning (max USD/min) is front-loaded. The second sentence is slightly tangential but still informative about the cap tiers.

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 lookup the description covers what the value represents, which is the main thing. Without an output schema it should still say something about the returned fields or unknown-country behavior, and it omits any mention of the input parameter it requires.

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

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

Schema description coverage is 0% and the single parameter countryCode is undocumented in both schema and description. The phrase "in this country" hints that a country is the input, but nothing specifies format (ISO 3166 alpha-2?) or how the 2-80 character constraint is interpreted, which matters at zero 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 names the specific value returned: the maximum USD-per-minute rate an expert in a given country may charge. That is concrete and distinguishable from siblings like update_rate or estimate_call_cost. It lacks an explicit verb ("Returns/Gets") and never says the lookup is keyed by country code, but the purpose is unambiguous.

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

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

No guidance on when to call this versus alternatives such as get_supported_payout_countries, estimate_call_cost, or update_rate, and no stated prerequisites. The note that high-income countries and Europe use the higher cap is background information, not usage direction.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact: the returned link is unsigned and carries no embedded token, which matters for security and sharing decisions. It stops short of saying whether the URL is stable, whether it expires, or what it looks like.

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, the core function front-loaded, with no filler or repetition. Every sentence carries information the schema does not.

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 two-parameter tool with zero schema description coverage and no output schema, the description leaves too much open: no URL format or example, no per-target semantics, no indication of how `expertId` interacts with `target`. The reader understands the shape of the output artifact but not how to produce a correct call.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely fails: neither `target` nor `expertId` is mentioned. Critically, the implicit rule that `expertId` is presumably required when target=expert (and ignored otherwise) is never stated, and the enum values are never explained.

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?

"Builds a ... URL" gives a specific verb and resource, which is better than a tautology. But "Callpaymin" is unexplained jargon and "a known page" defers entirely to the schema enum, so an agent cannot tell what kinds of pages are addressable or how this differs from any sibling. Adequate but vague on 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?

No guidance on when to use this, whether it is a prerequisite for another flow, or who needs the resulting URL. The only boundary information (not signed, no token) describes the artifact's nature rather than when to call the tool. An agent must guess the use case.

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, idempotentHint, and non-destructive, so safety is covered. The description adds real behavioral context beyond that: the figures are live totals rather than an estimated window, which tells the agent results are not scoped by query. It says nothing about freshness latency, currency, or whether totals include pending holds waiting on release.

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, front-loaded with the returned categories before the scoping caveat. No filler; each sentence carries information. Slightly compressed to the point that the period sentence reads ambiguously.

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

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

With no output schema, the description usefully names the three earning states an agent will receive, which is the minimum needed to trust the result. However, the unresolved tension between the offered 'period' parameter and the claim that no custom period is applied leaves a real gap for a zero-required-parameter read tool.

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

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

Schema description coverage is 0%, so the description must carry the one parameter, and it does so only by negation: 'A custom period is not applied.' That leaves the agent unsure whether 'period' is honored, ignored, or rejected, and gives no format guidance (maxLength 40 with no documented syntax). The statement adds uncertainty rather than semantics.

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

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

The description names a specific resource (expert earnings) and enumerates the exact breakdown returned: pending, releasable, and paid. It clearly contrasts with an estimate over a window by stating the figures are live totals. It does not differentiate itself from closely related siblings such as get_releasable_balance, get_wallet_balance, or list_payouts.

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 is only implied: an agent can infer this is the right tool for a snapshot of lifetime earnings totals rather than a period report. There is no explicit statement of when to prefer get_releasable_balance or get_wallet_balance, nor any prerequisites. The one exclusion offered ('a custom period is not applied') is about the period argument, not about choosing between tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description earns extra credit by disclosing the return shape (profile, rate, scheduling rules) and, importantly, the privacy boundary — no email or phone — which steers the agent away from promising contact details. It does not state what happens for a non-approved or unknown expertId.

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

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

Two tightly packed sentences with zero filler; the payload contents are front-loaded and the negative scope follows immediately. Nothing could be removed without losing information.

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

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

For a one-parameter read tool with rich annotations and no output schema, the description adequately conveys what comes back and what is deliberately withheld. The remaining gap is the bare expertId contract (validity, error behavior), which is modest but real given 0% schema coverage.

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

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

Schema coverage is 0% and the single expertId parameter has no description, format hint, or source-of-truth (how to obtain a valid ID). The description only weakly compensates by scoping the ID to 'one approved expert'; it never says what an invalid or unapproved ID yields.

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

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

The description names a concrete resource (one expert) and enumerates returned content: public profile, per-minute rate, scheduling rules. The singular scope implicitly separates it from search_experts, but it is a noun phrase without a verb and never explicitly names the sibling it differs from (e.g. get_expert_availability, which also touches scheduling).

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?

'For one approved expert' implies this is a single-entity lookup rather than a search, giving implied routing versus search_experts. However, no explicit when-to-use, no when-not, no named alternative, and no note that get_expert_availability may be the better tool if only scheduling is needed.

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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description usefully confirms the read semantics with 'open booking slots' but says nothing about how the required durationMinutes shapes the result set, whether results are timezone-adjusted, or whether an expert can return zero slots.

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 clause with no filler, which is the right shape. It is slightly too terse for a three-required-parameter tool, leaving no room for the usage and parameter context that would be more valuable than the whitespace.

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

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

No output schema, so the description must convey what a 'slot' is (start/end time, timezone, price, expert-side metadata) and does not. Combined with an unexplained durationMinutes and no booking-flow context, an agent cannot confidently call this or interpret 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?

Schema description coverage is 0%, so the description carries the full burden. It explains date as YYYY-MM-DD (already enforced by the schema pattern) and implies expertId, but the third required parameter, durationMinutes (5-180), is never mentioned, and its likely role in filtering slots is left undocumented.

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

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

States a specific verb and resource: returns open booking slots for a given expert and date. It does not distinguish itself from neighbours such as get_expert, check_expert_online, or set_availability, so the agent must infer it is the read side of the availability pair.

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

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

No when-to-use guidance, no prerequisites, and no mention of the obvious downstream sibling create_booking. The agent is left to guess whether this must be called before booking or whether create_booking validates slots itself.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds one genuinely useful fact beyond that — the result is scoped to the signed-in user, requiring no identifier — but says nothing about auth prerequisites or what 'profile fields' comprises.

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 short sentence with zero filler, and the key scoping fact ('own') is up front. It is arguably under-specified rather than padded, so length is not the problem.

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 and no output schema, the description is the only place an agent could learn what is returned, and 'profile fields' stays abstract. For such a simple read tool this is adequate but leaves a real gap about the response shape.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The 'own profile' wording usefully confirms that no user identifier is accepted.

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 phrase 'signed-in user's own profile fields' identifies the resource and its implicit scope (the caller, not an arbitrary user), but it is a noun fragment with no verb, so the retrieval action is only inferred from the 'get_' prefix. It also does not explicitly contrast with the sibling update_profile.

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

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

There is no statement of when to call this versus alternatives such as update_profile, get_earnings_summary, or get_wallet_balance, which also relate to the current account. The agent must infer all routing from the name alone.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: data is masked, and full card numbers and vault ids are deliberately withheld, which shapes how an agent should present or reason about the result.

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

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

A single tight sentence with zero waste; the key scope ('saved on the wallet') comes first and the privacy constraint follows. Nothing could be removed without losing 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?

With no parameters and no output schema, the description does most of the needed work by sketching the return shape (brand, last four) and the empty case. It stops short of saying the result is a collection or how multiple cards are ordered/returned, a minor gap for a display-oriented read tool.

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

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

The tool takes zero parameters, so the schema carries the full burden and the baseline of 4 applies. There is nothing for the description to clarify on the input side.

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

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

The description clearly identifies the resource: card brand and last four digits of payment methods saved on the wallet, with the empty case ('if any') noted. It lacks an explicit verb ('list/retrieve') and does not distinguish itself from the sibling get_payout_methods, so an agent must infer the split from names alone.

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 is only implied: an agent can deduce this is the read path for displaying saved cards, and the 'never returned' clause hints it is safe for display contexts. There is no explicit statement of when to call it versus get_payout_methods, or what to do when the wallet is empty.

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

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

The annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context by stating that full account numbers are not returned, which tells the agent the output is masked for security.

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 that lists the relevant return fields and the masking constraint with no wasted text. It is appropriately sized for a zero-parameter read tool.

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

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

With no output schema, the description carries the burden of explaining the return shape, and it does list the key fields plus the account-number masking behavior. It could mention ordering or empty-state behavior, but the essential information is present.

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

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

There are zero input parameters, so parameter semantics are not a source of ambiguity. The baseline score for a parameterless tool is appropriate.

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

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

The description identifies the resource as saved payout destinations and enumerates the returned fields, which helps distinguish it from payment-method tools. It lacks an explicit verb like 'list' or 'get' and does not name the closest sibling, get_payment_methods, 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 says what data is returned but gives no explicit guidance on when to use this tool versus alternatives such as get_payment_methods, list_payouts, or add_payout_method. Usage is only weakly implied by the phrase 'Saved payout destinations.'

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that: only approved experts are counted, and other totals are deliberately omitted rather than estimated, which tells the agent not to expect a broader stats object. It does not describe the response shape for a tool with no output schema.

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

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

Two short sentences, front-loaded with what is returned, followed by the scope caveat. No filler and nothing redundant.

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

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

For a no-parameter, read-only tool the description covers what is counted and what is excluded, which is the material information. Since no output schema exists, a brief note on the returned value's form (e.g., a single integer) would close the last gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the empty schema is self-explanatory. Baseline 4 applies.

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

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

States a specific resource and scope: the count of approved experts in the directory. The name 'platform stats' is broader than the actual payload, but the description immediately narrows it. It does not name a sibling (e.g., search_experts or get_referral_stats) to differentiate against.

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

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

There is no explicit statement of when to call this versus alternatives such as search_experts or get_referral_stats; usage is only implied by the noun 'directory'. The only guidance-like sentence ('other totals are omitted') describes the payload, not when to invoke the tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuine context beyond that: the comparison basis (country cap plus peer median), the sampling bound (up to 20 experts), and the advisory/non-binding nature of the result. It stops short of saying what happens if no rate is set or how the comparison is presented.

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

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

Two sentences, no filler. The comparison mechanics come first and the interpretive caveat second, so the agent gets the essential semantics immediately.

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 lookup with no output schema, the description supplies enough to call and interpret it. The only real gap is prerequisite behavior — e.g., what is returned when the caller has no rate set or an industry that yields no peers.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate — baseline 4 applies. Implicit inputs (the caller's own rate, country, and industry) are drawn from the profile, which the description hints at by phrasing everything as 'your rate' and 'your industry'.

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 operation — comparing the caller's rate against their country cap and the median public rate of up to 20 listed experts in their industry. The scope qualifiers (country cap, industry, sample size) make it unmistakable against siblings like get_country_rate_caps or update_rate, which return raw caps or mutate the rate.

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 line 'It is a hint, not a required price' tells the agent how to treat the output, which is useful usage framing. However, there is no explicit when-to-call guidance and no routing to alternatives such as get_country_rate_caps for the raw cap or update_rate to act on the suggestion — the agent must infer the decision context.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the description's added value is in disclosing two real traits: authorization scoping (other people's calls are not found) and an output limitation (recording URLs are not included). That is meaningful context beyond the annotations, though it doesn't say what happens on not-found or what the receipt contains.

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

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

Three short sentences, purpose front-loaded, no filler. Each sentence delivers a distinct fact: what it returns, who can access it, and what is excluded.

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

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

For a one-parameter read tool with rich safety annotations and no output schema, the description covers scope and exclusions adequately. It still leaves the parameter source and the receipt's contents unexplained, which an agent would need to call it confidently.

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

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

Schema description coverage is 0% for the single callId parameter, so the description carries the burden. It only implies via 'one of your calls' that the ID must belong to the caller; it never says where to obtain the callId or what form it takes.

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

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

The description states the resource (a receipt) and scope (one of your calls), which is clear enough to distinguish it from siblings like list_my_calls or get_call_session. It does not use an explicit verb and does not name a sibling alternative, keeping it 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?

'Other people's calls are not found' gives a useful exclusion, implying this tool only works for calls the caller owns. However, it never says when to reach for this versus get_call_session or list_my_calls, so routing 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?

Annotations already declare this as a safe, read-only, idempotent operation. The description adds useful domain behavior beyond those annotations: the conditional issuance of a referral code and the 5%/12-month commission terms.

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

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

The description is three short sentences with no wasted text. The core purpose is front-loaded, followed by relevant commission context and a sibling pointer.

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 getter with rich annotations, the description covers purpose, issuance condition, business context, and the relevant sibling. It is mostly complete, though without an output schema it could clarify the exact return shape or behavior when no code has been issued.

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

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

There are no parameters, so there is no parameter semantics to explain. The baseline for zero parameters is 4, and the description does not need to compensate for missing schema coverage.

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

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

The description states a specific resource, 'your own referral code', and its issuance condition. It explicitly distinguishes itself from the sibling get_referral_stats by noting that referred people are covered there.

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 clearly indicates when this tool applies ('if one has been issued') and routes referral-statistics queries to get_referral_stats. It does not explicitly mention apply_referral_code or other alternatives, but the usage context is clear.

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

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

Annotations already declare this as a safe, read-only, idempotent, non-destructive operation in a closed world. The description adds useful scope about included fields and explicitly excludes emails and account ids. However, it does not clarify whether results are paginated, ordered, or limited by time range, which matters for interpreting 'stats.'

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-loads the key returned fields, followed by a useful exclusion note. It could be slightly stronger if it began with a clear action verb, but there is no wasted content.

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 input parameters and annotations covering safety, the main missing context is the shape of the result. The description explains the core fields and exclusions, which is helpful, but leaves unclear whether this returns all referrals, a paginated list, or aggregate statistics.

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 no parameter semantics burden. The empty schema is sufficiently clear, and the description correctly focuses on the returned data instead.

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

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

The description clearly identifies the resource: people who used the user's referral code, including name/initials, join date, and active status. It is specific about the returned data but does not use an explicit action verb or differentiate from siblings like get_referral_code or get_platform_stats.

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

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

There is no guidance on when to use this tool versus alternatives such as get_referral_code or get_platform_stats. The usage is only implied by the name and description.

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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely non-redundant domain context: the 7-day hold rule that determines what counts as releasable, and the explicit clarification that it has no side effect on payouts. Return shape (currency, amount breakdown) is not described, but with a zero-param read tool this is a minor gap.

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

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

Two short sentences, zero filler, with the defining business rule (7-day hold) front-loaded before the negative clarification. 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 zero-parameter read-only tool with full annotation coverage and no output schema, the definition covers what the value represents and what it does not do. The only omission is a hint at what the response contains (e.g., amount and currency), which the absence of an output schema makes slightly more relevant.

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 no parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly does not waste space restating an empty schema.

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

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

States a specific resource (expert earnings past the 7-day hold, available to withdraw) with a clear read verb implied by the name. It explicitly distinguishes itself from request_payout, though it does not differentiate from close siblings like get_wallet_balance or get_earnings_summary, leaving some overlap for the agent to resolve.

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 sentence 'This does not request a payout' provides an explicit when-not, which is useful routing guidance toward request_payout. However, there is no positive statement of when to call this instead of get_wallet_balance or get_earnings_summary, so the choice among three balance-like reads is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context (results are public; reviewer emails are redacted), but says nothing about ordering, pagination behavior for the limit cap, or what happens for a non-approved expert.

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, front-loaded sentences with no filler; the privacy caveat earns its place. The first sentence is a fragment rather than a complete statement of action, which is the only structural weakness.

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

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

For a simple two-parameter read tool with no output schema, an agent still needs to know the shape of a review, the ordering, and the pagination behavior — none of which are described. The redaction note is helpful but not sufficient on its own.

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

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

Schema description coverage is 0% for two parameters, so the description must compensate and largely does not. 'For an approved expert' weakly implies expertId, but the limit parameter (max 20, min 1) and any default page size are never mentioned in either place.

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

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

The description names the resource ('reviews') and constrains it to a public, approved-expert scope, so an agent can tell this apart from siblings like get_expert or get_rate_coach_suggestion. It lacks an explicit retrieval verb and never mentions the required expertId, but the purpose is unambiguous.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g., getting an expertId from search_experts), and no alternatives named. The only hint is the qualifier 'approved expert', which implies a constraint but is never stated as a condition.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world list, so the safety profile is fully covered without description help. The description adds one piece of real behavioral context: this returns currencies for charging, not exchange rates. It says nothing about whether the list is static or user-dependent, or how many entries to expect, which is the remaining unknown for a zero-param read.

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, front-loaded with the scope and followed by the disambiguation clause — no filler. The phrasing is slightly terse and telegraphic ('charges in'), and 'Callpaymin' is an unexplained brand token, but nothing is 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?

With no input params and no output schema, the description carries the full burden of describing what comes back, and it only says they are currencies. An agent cannot tell whether the response is ISO codes, objects with symbols, or which currencies are excluded. For a simple enumeration tool this is close to adequate but leaves a real gap.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly avoids inventing inputs. Schema coverage is moot at zero properties.

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

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

The description names the resource (currencies) and scopes it to those the Callpaymin wallet charges in, which is specific enough for an agent to know it's a static billing-currency list rather than a rate table. The explicit 'not a foreign-exchange table' line distinguishes it from the sibling convert_currency. It stops short of a clean verb-first statement like 'List supported wallet currencies', but intent is unambiguous.

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

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

The negative guidance ('not a foreign-exchange table') implicitly steers an agent toward convert_currency for FX needs, which is useful routing. However, it never states the affirmative case — e.g. 'use this to validate currency codes before add_funds or request_payout' — and names no alternative explicitly. Usage must be inferred from scope alone.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the key behavioral nuance beyond that: the data mirrors the payout settings page config rather than a live provider check, which tells the agent results may be static. Freshness/refresh policy is still unstated, keeping it below 5.

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, front-loaded with the core answer (countries + rail), followed only by useful exclusions. Nothing is repeated from the title and no sentence is filler.

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

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

With no output schema, the description must convey the return shape, and it does minimally: a set of countries plus an associated rail value. It stops short of describing the exact field names or shape of each entry, which would fully close the gap for a zero-param, no-output-schema lookup.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline of 4 applies with no semantic 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 resource (payout countries) and the associated payload (rail: Stripe or Wise), which an agent can distinguish from get_supported_currencies or get_payout_methods. It never uses an explicit verb like 'list' or 'return', so the action is inferred from the noun phrase rather than stated.

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 two negative clauses ('does not check a live provider', 'does not return bank details') implicitly steer the agent away from using this for live provider verification or bank details. However, no sibling tool is named and no positive trigger for when to call this versus get_payout_methods is given, so routing is left to inference.

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

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

'Nothing is read or changed' is consistent with readOnlyHint=true and destructiveHint=false, and usefully discloses that the call is a no-op rather than a real retrieval. It stops short of stating what actually happens on invocation (thrown error vs. empty payload) and does not reconcile the oddly mutation-flavoured parameters (confirm, idempotencyKey, acknowledgedAmountUsd) with a read-only stub.

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

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

Three short sentences with the unavailability stated up front, which is the right ordering for a dead tool. Nothing is padded, though the third sentence repeats the read/write message already inherent in 'not yet supported'.

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 stub with no output schema and no annotations covering error behaviour, the description should say what a caller experiences when invoking it and what to use instead. Neither is present, leaving an agent unable to decide this over send_support_ticket or other ticket-adjacent 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?

Schema description coverage is 0% across five parameters, so the description carries the full explanatory burden and adds nothing. If the tool is non-functional the parameters are arguably moot, but acknowledgedAmountUsd and idempotencyKey are genuinely confusing and get no clarification.

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 plainly that no support-desk API exists here and the tool is unsupported, which does let an agent tell it apart from functional readers like get_receipt. However, it defines the tool by negation rather than saying what a call would actually yield (an error, an empty result, or nothing at all), so the operational purpose remains ambiguous.

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?

'This tool is not yet supported' implies the agent should avoid it, but no explicit directive is given and no alternative is named. The sibling list contains send_support_ticket, which is the obvious substitute for anything ticket-related, and the description never routes the agent there.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with "Nothing is read or changed" plus the crucial disclosure that the endpoint is unimplemented and returns nothing. That is real information an agent could not get from the structured fields. One tension: idempotentHint=false is odd for a pure no-op, but it is not a direct contradiction.

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

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

The front-loaded statement that documents cannot be generated is good, but the next four sentences circle the same idea ("Nothing is returned in their place", "not yet supported", "Nothing is read or changed") without adding distinct information. It could be one or two sentences.

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

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

With no output schema and no annotations describing the stub behavior, the description correctly carries the critical fact that this tool is a no-op. However, it leaves the five-parameter schema entirely unexplained, which is a meaningful gap for a tool whose signature suggests side effects that the description denies.

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

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

Schema description coverage is 0% across five parameters, including non-obvious ones like `confirm`, `idempotencyKey`, and `acknowledgedAmountUsd` on a tool that supposedly reads nothing. The description says nothing about what these parameters mean or whether they are ignored, so the agent must guess why a read-only no-op takes an idempotency key and a dollar amount.

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

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

The description states a specific resource (tax documents) and, unusually, states the outcome: the server cannot generate them and nothing is returned. An agent immediately learns this tool will not produce data, which is the key fact about its purpose. It gets no credit for sibling differentiation, but the tax-document scope is unambiguous.

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

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

"This tool is not yet supported" combined with "Nothing is returned in their place" is effectively an explicit do-not-use-for-data directive. What is missing is a stated alternative for obtaining tax documents, so the agent knows what to do 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?

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world. The description adds meaningful context beyond that by identifying what balance is for and by explicitly saying payout account numbers are not returned, which is a useful data-boundary disclosure.

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

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

The description is short, front-loaded, and each sentence contributes information. The final sentence 'No payout account numbers' is slightly terse and could be phrased more explicitly, but it still earns its place as a scope boundary.

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 tool with strong annotations and no output schema, the description gives a reasonable sketch of the returned content: balance for calls plus withdrawable, pending, and paid earnings for experts. It stops short of describing currency or exact response shape, but the overall context is adequate.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter behavior, and nothing misleading is introduced.

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

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

The description states a specific resource (wallet balance), its purpose (used to pay for calls), and the extra earnings fields experts receive. It also sets a clear data boundary (no payout account numbers), though it does not explicitly distinguish itself from overlapping siblings such as get_earnings_summary or get_releasable_balance.

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 is implied by 'used to pay for calls' and by the mention of expert earnings, so an agent can infer when to call it. However, there is no explicit when-to-use versus alternatives guidance, which matters given several related balance, earnings, and payout tools.

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

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

The description asserts 'Nothing is read or changed', while annotations declare readOnlyHint=false, destructiveHint=true, openWorldHint=true and idempotentHint=false. These are directly at odds: an agent trusting the annotations would treat this as a destructive open-world write, and one trusting the text would treat it as a no-op.

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 short sentences, front-loaded with the blocking constraint and ending with the no-side-effect claim. Nothing is padded, though the sentences are terse enough to read as fragments.

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 6-parameter, no-output-schema tool the description explains nothing about the parameters, and the one behavioral claim it does make conflicts with the annotations. A 'do not call' stub can be brief, but leaving the safety profile contradictory is not 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?

Six parameters with 0% schema description coverage, and the description mentions none of them. Fields like confirm, idempotencyKey and acknowledgedAmountUsd are especially opaque and get no explanation from either source.

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 operation (joining a meeting room) and explains the underlying requirement (a mediasoup WebRTC client), then states plainly that the tool is not yet supported. An agent can tell what the tool would do and that it is currently unavailable, though it never spells out the intended effect in the positive sense.

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 strong negative usage signal: MCP cannot open the media path or start billing, so the tool should not be invoked. No alternative sibling is named (e.g. create_meeting_room or a web client), which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no indication of whether results are cached, static, localized, paginated, or how large the set is.

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?

It is a single short phrase with no filler and no buried information. The only structural weakness is that it is a noun fragment rather than a statement of what the call 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 trivial zero-param read with rich annotations and no output schema, the description is minimally adequate but leaves the return shape unspecified (names only? IDs plus labels? hierarchical industries vs topics?). Given no output schema exists, that gap should be closed in prose.

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

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

The tool takes zero parameters, so there is nothing for the description to document; the baseline for a no-param tool applies.

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

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

The description identifies the resource ('industries and topics used by the expert directory') but never states a verb like 'list' or 'returns', leaving the action implied by the name/title. It also does not distinguish this reference-data call from siblings such as get_supported_currencies or get_supported_payout_countries, which serve a similar enumeration role.

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

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

There is no guidance on when to call this versus alternatives, and no mention of the obvious downstream use (e.g., supplying an industry/topic filter to search_experts or post_job). The agent must infer the usage context entirely.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds no behavioral context such as ordering, pagination, or what fields are returned, so it contributes nothing 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 short fragment with no wasted words and is front-loaded. It is perhaps too terse to be a complete sentence, but it is not padded or structurally confusing.

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 list tool with rich annotations but no output schema, the description minimally conveys that the result is a list of favorited experts. However, it omits any mention of return shape, ordering, or pagination, which leaves the agent with only the bare minimum context.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain. Baseline score is 4 for a parameterless tool, and nothing in the description misleads about inputs.

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 'Experts you have favorited' essentially restates the tool name and title ('list_favorites' / 'List favorites') without adding a clear verb or scope beyond the obvious. It does clarify that favorites are experts, but an agent gets nearly all of its information from the name itself.

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

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

There is no indication of when to use this tool versus siblings like search_experts, favorite_expert, or unfavorite_expert. The description offers no alternatives or exclusions, leaving usage entirely implied.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description nonetheless adds real value by disclosing what is filtered out of the results: poster emails, invite codes, and draft/pending jobs — behavior an agent could not learn from the annotations or schema.

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

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

Two short sentences with zero filler. The core scoping fact ('active jobs on the public board') is front-loaded and the exclusion list follows compactly.

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

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

For a simple read-only list tool with annotations and no output schema, the description covers scope and exclusions. It still omits the meaning of 'limit', any default page size, and any hint of what a returned job record contains, leaving gaps for an agent assembling a call.

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

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

The single parameter 'limit' has 0% schema description coverage and is never mentioned in the description. Its bounds (1-50) come only from the raw schema, with no guidance on defaults or what happens when it is omitted.

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

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

The description names the resource and its scope precisely: active jobs on the public board. That distinguishes it in substance from list_my_jobs, but the sibling is never named, so the agent must infer the distinction rather than being told.

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

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

There is no explicit statement of when to use this versus list_my_jobs, post_job, or respond_to_job. The phrase 'public board' implies a browsing use case, but the agent is left to draw that inference unaided.

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, idempotentHint, non-destructive and closed-world, so the safety profile needs no restating. The description adds genuinely new behavior: results default to upcoming bookings only, a default not encoded in the schema's upcomingOnly property.

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 no filler, and the scoping constraint is stated before the default behavior. The first sentence is a bare fragment without a verb, which is slightly awkward but costs no meaning.

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 three undocumented parameters, no output schema and no required fields, the description covers the essential default but leaves an agent guessing about how status and limit interact with that default. Adequate, not complete.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, but it only implicitly touches upcomingOnly via the default statement. Neither limit (max 20) nor the status enum values receive any explanation of their effect on results.

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

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

The description names the resource (bookings) and the exact ownership scope (signed-in user as quester or expert), which is more specific than the title alone. It does not explicitly contrast with near-neighbors like list_my_jobs or list_my_calls, but the 'bookings' resource word does enough to separate 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?

It conveys the default condition ('Defaults to upcoming bookings'), which implies how to use the tool without extra arguments. There is no explicit when-to-use/when-not guidance and no named alternative for listing past or cancelled bookings.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds two genuinely useful traits: recordings are excluded and only the 40 most recent calls are scanned (explaining why results may be incomplete despite limit allowing 20). It does not explain ordering or what happens beyond the scan window.

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 short sentences, front-loaded with the scope and the key limiting behavior. The cost/earnings and recordings sentences earn their place as disambiguating facts, though the description could be tightened.

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

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

No output schema exists, so the description should carry more weight on return shape and filtering. It covers the scan cap and exclusions but leaves three undocumented parameters and the sort order unexplained, which is the largest remaining risk for correct invocation.

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

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

Schema description coverage is 0% for three parameters, and the description never mentions to, from, or limit. The meaning of to/from is genuinely ambiguous (dates? phone numbers? user identifiers?), so the description does not compensate for the coverage gap at all.

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 (list) and scoped resource (calls where the signed-in user is caller or expert), which cleanly separates it from session-level tools like get_call_session or list_my_chats. It doesn't explicitly name an alternative, but the scope is unambiguous.

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

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

Says what is returned (recent calls, user's cost/earnings) but gives no guidance on when to choose this over get_call_session, list_payouts, or get_earnings_summary. No prerequisites, no exclusions, no indication of what 'recent' means in practice.

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 state readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Nothing is read or changed,' explicitly telling the agent the call is a no-op rather than a read. It also explains the reason (no safe user-scoped query), which annotations cannot convey. It does not describe what an invocation returns (error vs empty result).

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

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

Three short sentences with the unsupported status stated up front and no filler. Efficient for its purpose, though the first sentence's rationale could be trimmed.

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 tool is a deliberate no-op with no output schema and no required parameters, the description supplies the one thing an agent needs: that calling it accomplishes nothing and why. Missing only a redirect to an alternative tool.

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

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

Schema description coverage is 0% for four parameters (orgId, confirm, idempotencyKey, acknowledgedAmountUsd) and the description mentions none of them. For an unsupported stub the parameters are moot, but the description provides no compensation for the total documentation 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 never says what the tool would do beyond the title 'List my chats'; its actual content is a status disclosure that consumer chat threads are not exposed via a safe user-scoped query. An agent can determine the tool is unusable, which is the operative fact, but the purpose itself is only inferable from the name.

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?

'This tool is not yet supported' effectively tells the agent not to invoke it, which is the key routing signal. However, it does not point at a workable substitute (e.g. get_chat_summary) even though a sibling exists, so the guidance is negative-only.

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 cover the read-only, idempotent, non-destructive profile, so the description correctly focuses on data semantics instead: pending-review jobs are included, invite links are stripped, and applied jobs are absent with a reason given. That is meaningful context beyond the annotations. It stops short of describing ordering, pagination, or what happens when `role` is set to 'applied'.

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

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

Three short sentences, front-loaded with the primary scope before the exclusions, with no filler. The final clause about the poster account is slightly cryptic but earns its place as the justification for the exclusion.

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 two-parameter list tool with no output schema, the description covers inclusion and exclusion but leaves the return shape, ordering, and the meaning of `role`/`limit` unexplained. The unresolved tension between the stated exclusion and the 'applied' enum value is a real completeness gap.

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

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

Schema description coverage is 0%, so the description carries the full burden for `role` and `limit` and largely fails. It never explains the `role` enum values and actually contradicts the 'applied' option by asserting applied jobs are not listed, and it says nothing about the `limit` bound or default. The one sentence it does spend on applications raises more questions than it answers.

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

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

The description states a specific resource (jobs) and a clear scope (posted by the signed-in user), which separates it from the broader list_jobs sibling even though it never names that sibling. An agent can tell what it returns without opening the schema.

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

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

It gives one useful exclusion (applied jobs are not listed), which implies when to pick list_my_jobs over an application-oriented path. But there is no explicit routing to list_jobs or get_application_status, and the stated exclusion directly conflicts with the `role` enum that offers 'applied', leaving the agent unsure which source of truth to trust.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful data-scope context by saying rooms are scoped to the signed-in expert and participant emails are excluded, but it does not describe return fields or pagination 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?

The description is two short sentences with no filler, front-loading the ownership scope and then adding the participant-email exclusion. Every sentence 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 zero-parameter, read-only listing tool with full annotation coverage, the description gives enough context to understand scope and one important data exclusion. It could still be slightly richer about return shape, but it is adequate for this tool's complexity.

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 input schema is an empty object, so there are no parameter semantics for the description to explain. The baseline score for zero-parameter tools is 4.

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

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

The description identifies the resource and ownership scope: meeting rooms hosted by the signed-in expert. It does not explicitly include the verb 'list' in the description and relies on the tool name/title for that action, but it still clearly distinguishes this read-only listing from create/end/join meeting room 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?

Usage is implied by the scope 'hosted by the signed-in expert' — use this to retrieve your own hosted rooms. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as list_participants.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds real value by disclosing the host-only authorization constraint and by stating which fields are deliberately withheld (emails, media tokens). It does not cover ordering, empty-room behavior, or errors, which keeps it at 4.

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, zero filler, with the scope constraint front-loaded and the field-exclusion note immediately after. Every sentence earns its place.

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

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

For a one-parameter read tool with no output schema, the description covers purpose, host restriction, and return shape (names only). Minor gaps remain around result ordering and behavior for an empty or non-hosted room, but nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 0% for the single required roomId, so the description must compensate. "A meeting room you host" gives context about which room is meant but never names the roomId argument or its format, leaving the mapping to inference.

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

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

States a specific verb and resource (display names of people in a meeting room) plus a scoping condition ("you host"), which separates it from siblings like list_my_meeting_rooms and mute_participant. It never names a sibling explicitly, so it falls 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 phrase "in a meeting room you host" implies the context of use (you must be the host) but gives no explicit when-to-use/when-not guidance or pointers to alternatives such as join_meeting_room or list_my_meeting_rooms. Usage is inferable rather than 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful trait beyond that: it fixes the returned field set and explicitly notes bank account numbers are excluded, which matters for privacy expectations. It says nothing about ordering, default page size, or how the optional limit behaves.

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, front-loaded with the resource and its fields, then one high-value caveat. Nothing is wasted and nothing is buried.

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 tool with no output schema, listing the returned fields plus the exclusion note covers the essentials of what comes back. It is still incomplete on pagination/limit semantics and on how many records are returned by default, which matters given the maximum of 30 in the schema.

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

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

Schema description coverage is 0% for the single `limit` parameter, so the description would need to compensate, and it never mentions limit, its max of 30, or the default when omitted. An agent must read the schema to discover the parameter exists at all and cannot learn from the description what happens if it is not supplied.

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 (list) and resource (your payout requests) and even enumerates the returned fields, so the agent knows exactly what it retrieves. It does not contrast itself with near-neighbours like request_payout, get_payout_methods, or get_earnings_summary, which is the main thing keeping it from 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?

There is no statement of when to call this versus the many money-related siblings (request_payout, get_releasable_balance, get_earnings_summary, get_payout_methods). The possessive 'Your' implies per-user scoping but no exclusions or preconditions are given.

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 says 'Nothing is read or changed,' while the annotations declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false. Those are directly opposing claims about side effects, and an agent cannot tell which to trust. Even though the prose explains the underlying reason (the MCP layer cannot reach the media server), the contradiction with structured fields is disqualifying.

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

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

Three short sentences with no waste, and the critical fact (nothing is muted, tool unsupported) is front-loaded after the naming sentence. Each sentence carries distinct information: what it nominally does, why it cannot work, and the net effect. Nothing to cut.

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 stub tool this covers the essential question — can I use this? — with a clear no and a reason. But it leaves the annotation conflict unresolved and names no alternative tool, so an agent trying to actually mute someone is left with nothing actionable.

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

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

All six parameters have zero description coverage in the schema, and the description explains none of them — not orgId, roomId, participantId, nor the confirm/idempotencyKey/acknowledgedAmountUsd safety fields. The only implicit guidance is that parameters are moot because nothing executes, which is at least some signal, but the field-level semantics are entirely unaddressed.

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 name pairs a specific verb (mute) with a resource (participant), and the description immediately clarifies that the operation is a mediasoup host command that this server cannot actually execute. An agent reading it knows both the nominal purpose and the real-world status, which effectively distinguishes it from working siblings like list_participants or end_call. It stops short of 5 only because it never names a working 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 gives an unambiguous when-NOT-to-use signal: 'This tool is not yet supported. Nothing is read or changed.' An agent should never invoke it, and that is stated plainly. However, it offers no redirection to a sibling tool that could accomplish muting, which is the missing piece for a top score.

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 openWorldHint=true, yet the description adds real value: the job is held for admin approval, is not published to the public board, and the invite link is shown only once. Minor residual tension: idempotentHint=false alongside a required idempotency key is not explained (dedupe vs. true idempotency), leaving the agent to infer the semantics.

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 short sentences, front-loaded with the DESTRUCTIVE warning, then lifecycle state, then the gating condition, then the one-time return. No filler and the highest-risk information comes first.

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 13-parameter mutation with no output schema and no per-parameter descriptions, the description accounts for only the two control fields. It says nothing about budget/rate interactions, the isPublic flag's effect versus the pending_review hold, or required fields beyond the schema's own required list.

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

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

Schema description coverage is 0% across 13 parameters, and the description only explains confirm and idempotencyKey. The remaining 11 fields — including the jobType and budgetType enums, isPublic, and the min/maxBudgetPerMin pair — carry no semantic guidance anywhere, so the agent must guess at their meaning and interactions.

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

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

States a specific verb and resource ('Creates a job') plus the exact lifecycle state it lands in ('pending_review'), which separates it cleanly from list_jobs, list_my_jobs, and respond_to_job. An agent can tell what this does without opening the schema.

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

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

'Does nothing unless confirm=true, and then requires an idempotency key' gives concrete invocation preconditions that prevent a wasted no-op call. It does not name an alternative (e.g. an update/edit path) or say when not to use it, so it falls short of full when/when-not 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 description asserts "Nothing is read or changed," while annotations declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true — a direct behavioral conflict about whether the call mutates state. Because the two structured and unstructured sources disagree, an agent cannot determine the actual safety profile; this is precisely the kind of contradiction that warrants a 1.

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?

It is short, but three of the four sentences restate the same point (the check isn't wired, the tool isn't supported, nothing changes). The non-functionality notice could be a single front-loaded sentence; the repetition adds length without adding 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 seven-parameter mutation-flagged tool with no annotations alignment and no output schema, the description should at minimum resolve the destructive-vs-noop conflict and name where rating actually happens. It leaves both open, so an agent cannot act correctly on it with confidence.

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?

Seven parameters (orgId, stars, callId, review, confirm, idempotencyKey, acknowledgedAmountUsd) have 0% schema description coverage and the description adds no parameter semantics whatsoever. Notably, acknowledgedAmountUsd and confirm hint at a monetary confirmation flow that is entirely unexplained, so the description fully fails its compensation duty.

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 communicates that this tool is meant to submit a post-call review but is currently a non-functional stub, which is the most decision-relevant fact for an agent. However, it never states the operation directly ("rate a call" only appears in the title), and it frames the action as belonging to a separate "post-call review API" rather than describing this tool's own purpose.

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?

"This tool is not yet supported" is a strong implicit signal not to call it, which is useful routing guidance. But no alternative is named — the description references an unnamed "post-call review API" rather than any sibling tool such as get_reviews, so an agent that wants to see or submit ratings is left without a destination.

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, openWorldHint=true and idempotentHint=false; the description adds real value on top by noting the confirm gate, the eligibility exclusions, and that no credits or fees are charged. It stops short of saying whether an application can be withdrawn or what a rejected call returns.

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 short sentences, each carrying a distinct fact — action, confirm gate, eligibility limits, no cost — with the primary action front-loaded. No filler.

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

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

For a mutation tool with no output schema, the description covers the safety-relevant constraints well, but leaves two of four parameters unexplained and gives no indication of what a successful call returns or how failures surface.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only explains confirm (implicitly) and jobId. The message and proposedRatePerMin parameters are never mentioned, so an agent has no idea what they do or when to supply them.

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

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

States a specific verb and resource: applies the signed-in user to an active public job, and clarifies it uses the same application record as the website. However, a sibling named submit_application exists and the description never distinguishes the two, leaving an ambiguity an agent must resolve elsewhere.

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

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

Gives clear gating context: nothing happens unless confirm=true, and it cannot be used on your own job or an inactive job. What's missing is any routing guidance versus the sibling submit_application.

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile needs no restating. The description earns credit for two genuinely non-obvious traits: bios are user-written (data quality caveat) and availability can be up to a minute stale (freshness bound). It stops short of describing result ordering, pagination, or how multiple filters combine.

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 purpose is front-loaded in the first clause, and the two long comma-separated value lists are justified because the schema documents none of them. The trailing caveats are short and earn their place, though the two lists dominate the description visually and could have been compressed into a reference to list_categories.

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 11 optional parameters, no output schema, and zero schema descriptions, the description is thin in key places: it never states the currency or units for min_rate/max_rate, whether query matches bios or names, whether filters AND together, or what a result contains. The freshness note helps, but an agent could still easily call this incorrectly.

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

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

Schema coverage is 0% across 11 parameters, so the description carries the full burden and only partly meets it. It enumerates allowed values for category and topic, which is high-value, but leaves query, country, industry, language, min_rate, max_rate, online_only, availability, and limit entirely unexplained — and the phrase 'Categories (industries)' blurs the distinction between the separate category and industry parameters.

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

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

The description opens with a specific verb and resource — 'Search approved Callpaymin experts' — and the word 'approved' signals a scoping filter that plain 'search' would not. It is clearly distinct from get_expert or list_favorites, though it never names a sibling to route the agent away from.

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

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

There is no statement of when to use this versus get_expert, check_expert_online, get_expert_availability, or list_favorites, all of which appear in the sibling list and overlap in intent. The freshness caveat hints at a check_expert_online handoff but never says so explicitly.

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 genuinely useful undisclosed behavior: sends may be billed after a free allowance, nothing is persisted, and the tool is a no-op. But "Nothing is read or changed" directly conflicts with the annotations' readOnlyHint=false and destructiveHint=true, leaving the agent unable to tell whether this is a destructive write or an inert stub.

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?

It is short (four sentences) and each sentence carries some signal, but the ordering is poor: the billing caveat leads, while the decisive fact ("not yet supported") is buried in the third sentence. Front-loading the unsupported status would make the whole definition scannable in one line.

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 stub that should never be invoked, the description is sufficient in substance: it says the tool is unsupported, performs no I/O, stores nothing, and may incur billing. The gaps are around parameters and a fallback path, but the essential decision—do not call this—is fully conveyed.

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

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

Schema description coverage is 0% and none of the six parameters (text, orgId, confirm, threadId, idempotencyKey, acknowledgedAmountUsd) are explained in the description. The billing sentence loosely gestures at acknowledgedAmountUsd/confirm, but idempotencyKey, threadId, and orgId remain entirely undocumented in both places.

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 never states what the tool does beyond what the name and title already say; its opening sentence is about billing, not about sending a chat message. Its most useful content is negative framing ("not yet supported"), which tells an agent to avoid it but leaves the actual operation undefined.

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

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

There is an explicit exclusion ("This tool is not yet supported"), which is real when-not-to-use guidance that few sibling definitions provide. However, it names no alternative despite obvious candidates (start_chat, send_support_ticket, get_chat_summary), so an agent is told what not to do but not what to do 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 description asserts 'Nothing is read or changed,' but annotations declare readOnlyHint=false and destructiveHint=true, i.e. a potentially destructive write. That is a direct conflict about the tool's side-effect profile, and an agent cannot tell which source to trust. The stub disclosure is valuable, but it is stated in a way that contradicts the structured safety metadata.

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 short sentences, front-loaded with the decisive fact that no support-desk API exists. Minimal waste, though 'MCP will not pretend a ticket was filed' and 'Nothing is read or changed' partly restate the same point.

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 7-parameter tool with zero schema coverage and annotations claiming destructive writes, the description is too thin: it does not say what an agent should do instead, whether the params are validated or discarded, or what (if anything) the call returns. It resolves the 'is this implemented?' question but little 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?

Seven parameters with 0% schema description coverage and the description says nothing about any of them. Critically, it does not say whether these inputs are ignored, validated, or rejected by the unimplemented stub, and opaque fields like acknowledgedAmountUsd and idempotencyKey go entirely unexplained.

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 never states what the tool does beyond the title; its content is a negative claim ('There is no support-desk API in this app... This tool is not yet supported'). It does make clear the tool is a non-functional stub, which is the most important fact, but an agent must infer the intended purpose (filing a support ticket) from the name alone.

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?

Effectively answers 'when should I use this?' with 'never — it is not supported', which is unambiguous routing guidance and prevents wasted invocations. It stops short of naming a fallback (e.g. get_support_ticket for reading existing tickets), so the agent is left with no alternative to route to.

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 idempotent, non-destructive, closed-world write behavior, so the safety profile is covered. The description adds meaningful scope ('the flag other people see'), but says nothing about how this interacts with do-not-disturb state, active calls, or whether it takes effect immediately.

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 front-loaded sentence with no filler; the resource and the key qualifier come before the value list. Nothing needs trimming.

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 tool with full annotation coverage and no output schema, the description gives enough to call it correctly. The only real gap is the lack of guidance on its relationship to the do-not-disturb 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?

Schema coverage is 0% and the single parameter has no description, so the description must compensate. It does list the three states matching the enum, but that largely restates the schema's enum rather than explaining what each state means for the agent's own session.

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?

Specific verb (Sets) plus resource (directory availability flag) and enumerates the three accepted states. The phrase 'other people see' distinguishes it from internal-state tools like get_expert_availability, though it never names a sibling 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 visibility framing ('other people see') implies when an agent would set this, but there is no explicit when-to-use, no exclusions, and no mention of the closely related set_do_not_disturb or clear_do_not_disturb siblings that an agent could easily confuse with this one.

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 asserts a complete no-op ("Nothing is read or changed"), while the annotations declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, i.e. a mutating, potentially data-destroying operation. The two signals directly conflict, so an agent cannot tell whether invoking this is harmless or irrevocable. Annotation Contradiction.

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

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

The critical fact is front-loaded in the first two sentences and there is no boilerplate padding. Slight redundancy between "does not read a do-not-disturb window" and "would not change who can reach you," but both are short and clarifying.

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 stub tool with no output schema, the description tells the agent everything needed to avoid a useless call. However, with six fully undocumented parameters and annotations that contradict the stated no-op behavior, an agent lacks the context to reconcile the safety profile.

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

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

Schema coverage is 0% for six parameters, including consequential-sounding ones (confirm, acknowledgedAmountUsd, idempotencyKey) that the description never mentions or explains. The only implicit guidance is that parameters are irrelevant because nothing happens, which does not help an agent that decides to call it anyway.

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

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

The description identifies the resource (a do-not-disturb window) and immediately states its actual status: the call router ignores such a window and the tool is not yet supported. That is more useful than a bare verb+resource statement, though it never contrasts itself with the sibling clear_do_not_disturb, which an agent could reasonably confuse it with.

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?

"This tool is not yet supported" plus "would not change who can reach you" is an unambiguous do-not-use signal, which is exactly the guidance an agent needs here. It stops short of naming an alternative (clear_do_not_disturb, or set_availability for reachability), so a 4 rather than a 5.

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

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

The description says "Nothing is read or changed," but annotations declare destructiveHint=true and readOnlyHint=false, creating a direct contradiction about side effects. This is a serious transparency failure for a mutation-shaped tool.

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

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

The description is short, but it front-loads billing background that does not help an agent invoke the tool. The key fact, that the tool is unsupported, appears only after irrelevant 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?

With five undocumented parameters, no output schema, and annotations that conflict with the description, the definition is not complete enough to support correct invocation. The only actionable statement is that the tool is unsupported.

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

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

There are five parameters with 0% schema description coverage, including confirm, idempotencyKey, and acknowledgedAmountUsd, and the description explains none of them. It does not compensate for the undocumented schema at all.

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 does not state what start_chat actually does; it mainly explains that chat billing is not wired to MCP and that the tool is unsupported. An agent can infer it is a chat-start placeholder, but the operational purpose is absent.

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

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

It explicitly says the tool is not yet supported, which is useful guidance not to invoke it. However, it does not name alternatives such as start_call, send_message, or get_chat_summary, so routing guidance is 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?

The description asserts 'Nothing is read or changed', directly contradicting annotations that declare destructiveHint=true, readOnlyHint=false and openWorldHint=true. The statement about the review email is useful context, but the core behavioral claim conflicts with the structured safety metadata.

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?

It is short and front-loads the context, but the last two sentences are largely redundant restatements of 'not supported' and 'nothing happens'. The four sentences do not build a coherent picture of the tool.

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

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

A five-parameter tool with no schema descriptions, no output schema and destructive/open-world annotations needs far more: what each parameter means, whether any cost is incurred, and what an agent should do instead. Saying the tool is unsupported partly excuses the gap but does not explain the parameters or the alternative path.

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?

Five parameters with 0% schema description coverage and no parameter information in the description at all. Opaque names like 'docs', 'confirm', 'idempotencyKey' and especially 'acknowledgedAmountUsd' (which implies a monetary commitment) are left completely unexplained.

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 talks about the expert-application signup flow (document upload, review email) but never states the tool's own action — that it would submit an expert application for review. The only concrete claim is that it is unsupported, which leaves the actual purpose to be inferred from the name and title.

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?

'This tool is not yet supported' plus 'MCP will not mark an application submitted' gives an explicit when-not-to-use instruction, which is more routing help than most definitions provide. It stops short of the top score because it never names the sibling an agent should use instead, e.g. get_application_status for tracking an application.

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=false, idempotentHint=true, and destructiveHint=false, so the description needs only to add context — but it adds none beyond restating the operation. It says nothing about what happens if the expert was not favorited, whether auth is required, or what the call returns.

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 short sentence with the action and object front-loaded — no filler. Its brevity is appropriate, though it tips into under-specification rather than tight completeness.

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 mutation with annotations covering the safety profile and no output schema, the minimal description is close to sufficient. Still, it omits the parameter's meaning and the no-op/error case for an expert not in favorites, which an agent would want before calling.

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

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

Schema description coverage is 0% and the description never mentions  expertId, so nothing clarifies that it is the identifier of the expert to remove or what format/limits apply (the schema only enforces 1–128 chars). The parameter's meaning is guessable from the name but not documented.

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 ("Removes an expert from your favorites"), so the operation is unambiguous. It does not reference the obvious counterpart avorite_expert or  list_favorites, so sibling differentiation is left to the tool name alone.

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

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

There is no guidance on when to use this versus avorite_expert or how to discover existing favorites via  list_favorites. The use case is only inferable from the name, and prerequisites (e.g. the expert must already be favorited) are unstated.

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 non-destructive, idempotent, non-read-only behavior, so the floor is set. The description adds the valuable exclusion set (email/role/balance/payout are immutable here), but says nothing about partial-update semantics — whether omitted fields stay untouched and whether arrays like topics or languages are replaced or merged.

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, zero filler, with the scope constraint front-loaded before the exclusions. Nothing here repeats the schema or wastes tokens.

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 nine-parameter mutation with no output schema and no per-parameter documentation, the description should at minimum state that all fields are optional and how omission/array replacement behaves. It covers only exclusions, leaving the actual update contract under-specified.

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