Stackduke Radar

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

Annotations already cover read-only, idempotent and non-destructive behavior, so the bar is lower. The description adds real value beyond them: results are limited to followed servers and to the latest listing (no history), and it discloses the case-insensitive exact default plus the 3-character minimum for '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 sentences, front-loaded with the core purpose, then matching semantics, then scope limits. No redundant restatement of the title or schema, and nothing dangles.

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. Scope, matching modes and default behavior are all covered; the only real gap is the absence of head-to-head guidance against the sibling lookup 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 coverage is 50%: 'name' is described in the schema but 'match' is only an enum with a default. The description compensates by explaining what exact vs 'contains' actually do, including the case-insensitivity and the 3-character floor that the schema's pattern does not express.

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 ('Finds which tracked vendor MCP servers list a tool with a given name') plus a secondary output ('the kind each is counted as'). It reads clearly relative to siblings like list_tracked_servers or get_server_capabilities, though it never names an alternative 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 scope constraint ('Searches only the servers the tracker follows, at their latest listing') tells the agent when results will be incomplete, which is useful context. But it never states when to choose this tool over the sibling tools (e.g. list_tracked_servers or get_server_capabilities), so usage is only implied.

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

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

Beyond the read-only, idempotent annotations, the description discloses important behavior: changes are dated between checks, changes made and undone between checks are invisible, changed text is never quoted, and failed or missing checks are reported. These are exactly the details an agent needs to interpret reliability and limitations.

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 sentence, and the remaining sentences each contribute a distinct operational caveat or coverage rule. Despite the density, there is no filler and the description is appropriately sized for a tool with change-detection semantics.

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 scope, time range, tracked-server constraint, detection limitations, output contents, and untracked-server behavior. With annotations and an output schema already present, this is complete enough for an agent to invoke the tool correctly.

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

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

Schema coverage is already 100%, including the days range and vendor examples, so the baseline is 3. The description adds meaningful vendor semantics by specifying that the vendor must be a tracked server and that untracked servers yield a 'not covered' response.

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 reports changes to one tracked vendor MCP server's tool list over a bounded time window, including added, removed, changed, and newly expanded tools. This change-history scope is clearly distinct from the sibling tools' focus on finding tools, server capabilities, or listing tracked servers.

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 clear usage context: the server must be tracked, the lookback window is 1 to 30 days with a default of 7, and untracked servers return a 'not covered' answer. It does not explicitly name alternatives such as get_server_capabilities or find_tool, so the guidance is strong but not fully comparative.

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 past the readOnly/idempotent/non-destructive annotations: it discloses where labels come from (the server's own annotations, otherwise a name-based guess biased toward the more serious kind), that they were not verified by calling the tools, that they do not imply safety, that tool descriptions are excluded, and what an untracked server returns. This is exactly the provenance and confidence context annotations cannot carry.

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

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

Front-loads the purpose, then spends its length on provenance and limits, every clause carrying signal. The parenthetical glosses on each kind are dense but justified, though the middle paragraph runs long as a single block.

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 shape needn't be explained, and the description still covers the two things an agent genuinely needs: what the labels mean and how much to trust them, plus the not-covered case. Nothing essential to correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description defines each enum value semantically (money = move or spend, destructive = irreversible changes, send = messages/publication, write = create or change, read = labelled as reading only), which adds meaning beyond the bare enum list and shapes how the kind filter is chosen.

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?

Opens with a specific verb and resource ('Gives the tool names on one tracked vendor MCP server') plus the grouping dimension. That is clearly distinct from find_tool (search) and list_tracked_servers (enumerate servers), so an agent can route without opening a 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?

Establishes the context clearly: one server at a time, optional kind filter, and the 'not covered' outcome for untracked servers implicitly points at list_tracked_servers. It never explicitly names a sibling or states when to prefer find_tool, so the routing is inferred rather than spelled out.

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 the readOnly/idempotent annotations by disclosing data provenance ('answers come from Stackduke's published tracker data'), that no vendor server is contacted, and the ~daily refresh cadence. These are exactly the operational facts an agent needs to reason about staleness and side effects.

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

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

Front-loads what is listed, then the returned fields, then freshness, then the read-only guarantee — a logical order with no filler. The parenthetical kind list is dense but genuinely informative rather than 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?

With an output schema present, the description needn't specify return values, yet it still summarizes the per-server fields (tool count, kind breakdown, last checked, last listed), and it covers scope, freshness, and safety. 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?

The tool takes zero parameters, so the baseline is 4; there is nothing parameter-wise for the description to compensate for. Schema coverage is 100% and no enum or nested semantics exist.

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 ('Lists the official vendor MCP servers that Stackduke's public tracker follows') and immediately scopes it with 'Only these servers are covered,' so an agent can tell this apart from a per-server lookup like get_server_capabilities. It stops short of naming the sibling tools outright, which keeps it from a top score.

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 context for use: this is the enumeration of tracked servers, and the data refreshes 'about once a day,' which tells the agent how much to trust freshness. There are no explicit when-not-to-use statements or named alternatives, 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.