connectorreport

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

readOnlyHint=true already establishes this as a safe read, so the description's added value is modest. It does disclose the return content (status plus last test date) and enumerates the possible status values, which goes slightly beyond the annotations, but says nothing about what the values signify, freshness, or whether a failed test is indicated.

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 return payload and followed by the actionable cue. No filler, no restatement of the tool name, and the parenthetical defining the status values earns its space.

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

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

For a one-parameter read-only status check with no output schema and safety fully covered by annotations, the description supplies everything needed to decide to call it and what to expect back. It stops short of explaining how to interpret Clear/Cloudy/Stormy, which is a minor gap.

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

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

Schema description coverage is 100% and the single parameter already documents that it accepts a connector name or slug with an example. "By name" in the description merely echoes this, adding no new semantics, so the baseline 3 applies.

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

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

States a specific resource (a connector, identified by name) and what is returned: a status value plus the last test date. It is distinguishable from siblings like list_connectors and compare_connectors, though the nonstandard term "Connector Weather" requires the parenthetical to be interpretable.

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?

"Check this before relying on a connector" gives a clear when-to-use cue, but there is no when-not guidance and no sibling is named as an alternative, even though get_connector_report and compare_connectors plausibly overlap. Usage is implied rather than delimited.

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?

readOnlyHint=true already establishes that this is a safe read. The phrase 'hands-on results' does add useful context that the tool may perform live probing rather than reading cached data, hinting at latency or cost. Beyond that it says nothing about timeouts, partial failures, or what happens if a slug is unknown.

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 sentence, front-loaded, with no filler. It is appropriately terse, though the terseness comes at the cost of the missing detail noted in other dimensions rather than being a model of economical precision.

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

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

For a read-only aggregation tool with no output schema and zero schema description coverage, the description should indicate what the comparison returns and how the count constraint actually works. It omits the return shape entirely and leaves the slug-count conflict with the schema unresolved.

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 semantics. It states a '2 to 10' slug range, which is partially useful, but that range contradicts the schema's minItems=1 (and maxItems=10), so an agent may wrongly reject a valid single-slug call or pass an invalid two-slug call with false confidence.

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 give a clear verb+resource (compare connectors), and the description adds that output is side-by-side results. However, 'hands-on results' is vague about what dimension is being compared (features, pricing, live status, integration behavior), so an agent cannot distinguish this from get_connector_report or check_connector_status on the basis of the description 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?

No when-to-use guidance, no prerequisites, and no mention of the sibling tools (list_connectors, get_connector_report, check_connector_status). An agent must infer from the name that this is the multi-connector comparison entry point rather than a single-connector lookup.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by enumerating what the report contains (status, pass rate, tasks, gotchas, fix recipes), but says nothing about latency, caching, or whether a missing slug errors.

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 a compact colon-delimited list of fields. No filler, though the list of report contents is slightly dense.

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

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

With one required param, readOnlyHint, and no output schema, the description compensates well by summarizing the returned report fields. It is nearly complete for such a simple lookup, missing only usage routing and error behavior.

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

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

Schema coverage is 100%, and the slug parameter even documents examples and points to list_connectors. The description's 'by slug' adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb (get) and resource (connector report) scoped by slug, and enumerates the report's contents. It is clear what the tool returns, though it does not explicitly distinguish itself from siblings like search_reports or check_connector_status.

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: fetch the full test report for one connector. There is no when-to-use/when-not guidance and no mention of which sibling to prefer for a partial or multi-connector view (e.g. check_connector_status or compare_connectors).

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?

readOnlyHint=true already establishes the safe-read profile, and the description adds the useful detail that results are limited to hands-on tested connectors and that they carry a pass rate and last test date. It says nothing about ordering, pagination, result size, or what an empty category 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?

Two tight sentences with the purpose front-loaded and the optional filter trailing. Slight waste in re-listing the enum values already present in the schema, but the overall size is appropriate for the tool's simplicity.

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-optional-parameter read-only list tool with no output schema, the description covers what is returned and that results are scoped to tested connectors, which is sufficient to invoke it correctly. Missing only minor operational details like ordering or truncation behavior.

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

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

Schema description coverage is 100% and the single optional category parameter is fully documented in the schema. The description merely restates the same enum list verbatim, adding no matching semantics or filtering behavior beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (MCP connectors tested hands-on) and even enumerates the returned fields (status, pass rate, last test date). It is clear against singular siblings like check_connector_status, but it never names an alternative, so differentiation is inferred 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?

Usage is only implied: the tool enumerates the full tested-connector set, which an agent can contrast with check_connector_status or get_connector_report. There is no explicit when-to-use, when-not-to-use, or alternative-naming guidance.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description usefully adds the searchable corpus (connectors, task details, run notes, gotchas), but says nothing about result ordering, limits, empty-result behavior, or pagination – a gap that matters for a search 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 that names the scope first and tucks examples at the end. No wasted clauses, though the enumerated corpus list is slightly dense.

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 search tool with readOnly annotations this is close to adequate: the agent knows what is searched and can form a query. However, with no output schema there is no disclosure of what a result looks like, so the definition stops short of fully equipping the caller.

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 parameter with 0% schema description coverage, so the description carries the burden. It clarifies that 'query' is free-text terms and supplies two examples, but omits the 2-char minimum and 100-char maximum constraints present 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?

States a specific verb (full-text search) plus the resources searched (tested connectors, task details, run notes, gotchas), which is far more than restating the name. It does not explicitly distinguish itself from siblings like get_connector_report or list_connectors, but 'full-text search' vs 'get'/'list' is functionally evident.

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, when-not-to-use, or alternative routing is given. The example terms ('OAuth', 'token') illustrate query shape, not the decision of when this tool should be chosen over get_connector_report or compare_connectors.

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