Ternivo Connect

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description does not need to restate safety. It adds only the 'normalized' and 'cross-network' qualifiers, which hint at aggregation behavior across providers but stop short of disclosing auth requirements, rate limits, or whether snapshot freshness is guaranteed. The bar is lower with annotations, but the added value is 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 five-word sentence with no filler. Well front-loaded and free of redundancy. For a short description, this is ideal structure.

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

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

An output schema exists, so return values need not be explained. However, with one undocumented parameter at 0% schema coverage, zero usage guidance, and no differentiation from eleven siblings, the description is not complete enough for an agent to invoke the tool confidently. The time-window parameter alone warrants at least a clause.

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 'since' parameter is completely undocumented in the structured data. The description does not mention the time-window parameter, its expected format (ISO 8601? relative?), or any default behavior when it is omitted. Given the zero coverage, the description should have compensated and does not.

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 ('Get') and resource ('analytics snapshots') and adds a scope qualifier ('normalized cross-network'). This is more specific than a tautology, but it does not differentiate from siblings like get_connection_health, get_delivery_receipt, or get_post_status. It remains vague about what an 'analytics snapshot' concretely contains versus other status/health tools in the set.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The phrase 'cross-network analytics snapshots' implies a multi-account summary, which may distinguish it informally from per-connection diagnostic tools, but the description never states that condition. The agent is left to infer selection 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that output is 'normalized' and lists the failure states it handles, but does not explain the unusual idempotentHint=false on a read-only diagnostic or any rate-limit/return-shape behavior.

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

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

Two compact sentences with no filler; the trigger conditions come first and the outcome statement second. Efficient, though 'Get normalized connection health and diagnostics' is mildly redundant with the first 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?

An output schema exists so return values need not be described, and annotations cover safety. Still missing the disambiguation from get_connection_health and any meaning for account_id, which an agent needs to pick correctly and invoke 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% and the single parameter account_id is never mentioned or explained in the description. For a one-parameter tool the meaning is largely guessable, but the description does nothing to compensate for the total lack of schema documentation.

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

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

The description gives a specific verb ('get', 'diagnose') and resource ('normalized connection health and diagnostics'), so the agent knows it returns diagnostic output rather than raw data. However, it never distinguishes itself from the very similar sibling get_connection_health, leaving the two tools 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 states explicit trigger conditions: unhealthy, expired, scope-limited, or provider-review-limited connections. That is clear 'when to use' context, but there is no 'when not to use' and no pointer to get_connection_health as the alternative for the same domain.

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, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds useful behavioral content beyond that: it returns a normalized root cause plus a next action and support bundles, telling the agent the output is actionable rather than raw diagnostics.

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, front-loaded with the usage condition, with no filler. There is mild redundancy between 'failed or needs explanation' and 'normalized root-cause diagnostics' in the second sentence, but the structure is efficient.

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

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

An output schema exists, so return values need not be spelled out, and the safety profile is covered by annotations. The remaining gap is the unresolved resource_id semantics, which the description should have clarified given the post-vs-delivery ambiguity it itself introduces.

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 required parameter resource_id has no documented meaning anywhere. The description's phrase 'post or provider delivery' leaves it ambiguous whether resource_id is a post ID, a delivery ID, or either, which is exactly the ambiguity the description should resolve.

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: it returns normalized root-cause diagnostics and support bundles for a post/delivery. It is distinguishable from siblings like get_post_status or get_delivery_receipt, though it never names them, so differentiation is implied by the word 'root cause' rather than explicit.

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

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

It gives a clear trigger condition — use when a post or provider delivery failed or needs explanation — and discourages guessing. It stops short of naming alternatives (e.g. diagnose_connection) or stating when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the scoping detail that the settings are organization-level and white-label related, but says nothing about permissions, caching, or idempotency behavior beyond what annotations provide.

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

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

A single front-loaded sentence with no filler or redundancy. Every word carries meaning and the object of the read is placed 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 no-argument read with an output schema present, the description does not need to enumerate return fields. The only real gap is the absence of any usage context, which is minor given the tool's narrow scope.

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; baseline for a no-arg tool is 4. The description correctly implies no input is required by describing a pure read of a single settings object.

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 ('Read') and resource ('organization white-label settings'), which is more precise than many sibling names. It does not need to differentiate from siblings like analytics_summary or diagnose_connection, which are clearly unrelated domains, but it also names no 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?

There is no when-to-use guidance, no preconditions, and no mention of alternatives. The agent is left to infer that this is the tool for reading white-label branding, which is plausible from the name but not stated as policy.

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, destructiveHint=false and openWorldHint=false. The description adds genuine context beyond that: it enumerates the health states reported and notes that diagnostics are normalized, telling the agent what signal to expect before acting.

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, zero filler, with the pre-action timing guidance front-loaded before the return-content detail. 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?

An output schema exists so return values need not be re-explained, and annotations cover the safety profile. The description is sufficient for a single-param read tool, with only the account_id semantics left implicit.

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?

Only one parameter (account_id) with 0% schema description coverage, and the description never names or explains it. The phrase 'a specific social connection' loosely implies account_id identifies the connection, but the description does not compensate for the undocumented parameter.

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

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

States a specific verb and resource ('Get token/scopes/provider capability health and normalized diagnostics') and enumerates the states it reports (healthy, expired, limited, needs human action). It is clear what the tool returns, though it never explicitly distinguishes itself from the sibling diagnose_connection.

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 a concrete usage trigger: 'Use this before provider actions when you need to know whether a specific social connection is healthy...'. That is clear context for invocation, but there are no exclusions or guidance on when diagnose_connection would be the better pick.

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 it read-only, non-destructive and closed-world, so safety is covered. The description contributes genuine behavioral context beyond that: provider acceptance alone is not success, so status must be checked for a terminal verified state. It does not cover error auth or rate-limit behavior, but that is a minor gap against the annotation coverage.

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

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

Three sentences, front-loaded with the usage condition and the key caveat about acceptance vs. success. The final sentence degrades into a loose list of return fields, which is slightly wasteful since an output schema exists, but overall it is tight.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. Purpose and timing are well covered. The only real omission is the semantics of the required id parameter, which prevents a 5.

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 burden for the single required 'id' parameter. It never explains what that id identifies (post id, delivery id, attempt id?). The word 'IDs' appears only in the list of returned data, not as an input clarification, leaving the required parameter 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 gives a specific operation and scope: verify whether each provider reached a terminal verified state, returning deliveries, attempts, IDs, URLs and receipts. It clearly reads as a delivery-verification tool distinct from get_post_status, though it never explicitly names sibling tools to sharpen the distinction.

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

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

It states the trigger condition explicitly: 'Use this after a publish or scheduled run.' That tells the agent when to reach for it. No exclusions or named alternatives are offered, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description's added value is the disclosure that results reflect a dynamic 'current beta approval state' rather than static provider facts, with the explicit warning not to infer from provider name. It adds no info on error behavior, caching, or freshness, but for a read-only capability lookup this is solid supplemental context.

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

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

Three short sentences, front-loaded with the actionable 'use before writes' instruction. The final sentence restates the purpose already implied by the first, so it is mildly redundant but not wasteful.

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

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

An output schema exists, so return values need not be explained. Purpose and trigger condition are well covered; the only meaningful gap is the semantics of the optional provider argument, which neither the schema nor the description resolves.

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 the single 'provider' parameter, and the description only implies that a provider is the subject of the lookup. It does not say whether provider is optional (it is not required in the schema), what happens when omitted, or what string format/value is expected. Partial compensation, but the omission case is a real 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?

States a clear verb+resource: retrieve current provider/posting capability and review limitations. It also scopes why it exists (pre-write checks against actual availability and beta approval state). It does not differentiate from the nearby sibling get_publishing_policy, which an agent might 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?

Gives an explicit trigger: 'Use this before any provider-specific write,' plus a negative instruction not to infer availability from the provider name. It stops short of naming alternatives (e.g., get_publishing_policy) or stating when this tool is unnecessary.

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 (readOnlyHint=true, destructiveHint=false, openWorldHint=false), but the description adds nothing beyond them – no note on what "canonical" vs "provider" state means, staleness, or whether it hits the provider. With annotations present the bar is lower, yet this contributes almost no additional behavioral context.

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

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

A single short, front-loaded sentence with no wasted words. It is efficient, though its brevity borders on under-specification rather than tight editing.

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

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

An output schema exists, so return values need not be described, and the operation is simple. However, with an undocumented `id` parameter and no usage guidance, the definition is only minimally adequate for an agent to invoke it correctly.

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

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

One required parameter (`id`) with 0% schema description coverage, and the description never says whether `id` is a canonical post ID, a provider post ID, or an internal identifier – a distinction that matters given the tool returns both canonical and provider states. The description fails to compensate for the coverage 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?

States a verb ("Get") and a resource ("post status") but the object "canonical post and provider delivery states" is jargon that doesn't clearly separate this from siblings like get_delivery_receipt or diagnose_post. An agent can guess the general area but not the precise 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?

There is no when-to-use guidance, no prerequisites, and no named alternative. With get_delivery_receipt and diagnose_post in the sibling set, the description leaves the agent to infer the routing decision 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile needs no restating. The description earns credit by framing the tool as a precondition gate for autonomous writes and naming what the policy decides (human approval vs. volume controls) — behavioral context the annotations cannot convey. It does not mention caching, freshness, or failure behavior.

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

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

Two sentences, zero filler, with the usage trigger front-loaded before the resource description. Every clause carries 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?

An output schema exists, so return values need no explanation, and a zero-parameter read tool is otherwise low-complexity. The description covers purpose, trigger, and decision content. Only marginal gaps remain (what happens if no policy is set, or how agent policy interacts with the write 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?

The tool takes no parameters, so per the rubric the baseline is 4. There is nothing for the description to add or omit on parameter semantics.

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

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

States a specific verb ('Read') and resource ('organization publishing/approval/agent policy'), and the scope of what the policy governs is enumerated. No sibling tool (get_brand_settings, get_platform_capabilities, etc.) covers policy/approval reads, so an agent can distinguish it immediately.

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 explicit timing and trigger: 'Use this before autonomous public writes when you need to know whether human approval or volume controls apply.' That is a concrete when-to-use condition. It stops short of naming alternatives or stating when-not-to-use (e.g., for human-initiated interactive writes), so it is not a full 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the workspace-scoping constraint and the 'authorized workspace' qualifier, which is useful context but not rich behavioral detail beyond the structured fields.

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 when-to-use guidance. There is mild redundancy between 'discover the exact accounts available' and 'List social accounts assigned to this workspace,' but nothing wasteful.

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, a full output schema, and annotations covering the safety profile, the description needs only to establish purpose and timing, which it does. Return-value explanation is correctly omitted since an output schema exists.

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 baseline for a no-param tool is 4. No syntax or format concerns arise.

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'/'discover') and resource ('social accounts') with scope ('assigned to this Ternivo workspace'). It is clearly distinguishable from siblings like analytics_summary or get_post_status, though it does not explicitly name what it is not.

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

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

'Use this at the start of a social task' gives a clear triggering context for invocation. It does not name alternatives or exclusions, but for a discovery/listing tool the when-to-use guidance is concrete enough.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=false, so mutation is not a surprise and 'Refresh' is consistent with them. The description adds the side-effect surface (which categories get synced) but omits rate limits, latency/async behavior, and any cost of triggering an external provider call — meaningful gaps for an openWorld, non-idempotent 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?

A single front-loaded sentence with the action verb first and no filler. Slightly opaque noun pile ('owned-channel inbox', 'analytics' as things being refreshed), but structurally efficient.

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

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

With an output schema present, return values need no explanation, but for a mutating, non-idempotent, open-world sync with zero parameter coverage the description is too thin: no timing expectations, no permission/connection requirements, no clarification of which account is targeted or what happens if account_id is omitted.

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 account_id parameter has 0% schema description coverage, and the description says nothing about it — no format, no scope, and no hint at the implication that it is not required (sync all accounts vs. one?). The description does not compensate for the 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 verb 'Refresh' plus four enumerated data categories ('connection health, analytics, owned-channel inbox and capability information') tells the agent what the tool does in one pass. However, it never differentiates itself from siblings like get_connection_health or get_platform_capabilities, which cover overlapping data, so the agent could confuse a refresh with a plain read.

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 statement of prerequisites (auth/connected provider), and no mention of alternatives such as the get_* siblings that return the same data. The agent must infer that this is the write/fetch-triggering variant.

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, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the safety and external-call profile is covered. The description reinforces the read-only nature ('Read') and the external dependency ('connected broadcaster'), which is mild added value. It does not describe rate limits, pagination, or what happens when no schedule exists.

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

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

Three short sentences, with the primary action front-loaded in the second sentence after the usage trigger. The closing platform-scope note is slightly tangential but short and non-redundant. Nothing is bloated.

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

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

An output schema exists, so return values need not be explained, and annotations carry the read-only/external profile. For a single-parameter read tool, the description covers purpose, timing, and domain scope adequately. The only gap is the undocumented account_id semantics, which is a minor omission.

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

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

Schema description coverage is 0% for the single account_id parameter, so the description has to compensate. Saying 'the connected Twitch broadcaster's stream schedule' implies account_id identifies which broadcaster's schedule is read, which adds modest meaning. It does not specify format or whether the ID is a platform account ID versus an internal one.

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

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

The description states a specific verb and resource: 'Read the connected Twitch broadcaster's stream schedule.' That is unambiguous, and the added note that Twitch is a community/stream platform clarifies the domain. It does not differentiate against the listed siblings, but those cover unrelated functions (analytics, diagnostics, posting), so confusion risk is low.

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 usage context: 'Use this to inspect Twitch stream scheduling before creating or changing community activity.' That tells the agent when the tool is relevant. It stops short of naming a specific alternative or a when-not-to-use condition, so it falls 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.