UND Assay

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

Annotations already cover read-only/idempotent/non-destructive, so the safety profile is handled; the description adds real value beyond them by disclosing the shape of the return and its limits — notably that some checks could not run and that 'No warnings is NOT a safety guarantee.' That interpretive caveat is exactly the kind of disclosure an agent needs. Deducting one point because failure behavior (unknown identifier, partial resolution) isn't described.

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, purpose front-loaded before the evidence list, and the caveat placed last where it lands as a warning. The enumeration is dense but every item names a distinct evidence category the caller will receive, so none of it 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 usefully substitutes by naming the returned evidence categories, and annotations handle the safety profile. It's slightly incomplete in not covering bad/unresolvable identifiers, especially given a resolve_identifier sibling exists that hints at a preprocessing step the caller isn't told about.

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 single parameter's description already spells out the accepted forms (server name, catalog id, or GitHub repo URL). The description text adds nothing about the identifier, so baseline 3 applies — the schema carries all parameter meaning.

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

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

States a specific verb-and-resource outcome: an evidence summary about an MCP server, and enumerates the evidence categories (publisher identity, provenance, vulnerabilities, install scripts, maintenance, warnings, skipped checks, recent changes). What's missing is sibling differentiation — several siblings (get_evidence, get_publisher, get_tool) sound like they return overlapping data, and the description never says this is the composite/pre-install rollup versus the granular getters.

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?

'before you install or connect it' gives an explicit trigger condition, which is clear decision context. It stops short of exclusions or alternatives — it never says when to prefer get_evidence or get_tool instead, or what to do if the identifier isn't recognized.

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 that this is a safe, idempotent, read-only operation. The description adds useful scope by naming the types of metadata changes reported and clarifying that comparison is between consecutive published versions, but it omits edge cases such as first-version tools or empty results.

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 efficiently sized and front-loads the core resource scope. However, it is a sentence fragment rather than a complete action statement, which slightly weakens 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?

For a simple one-parameter read tool with read-only annotations, the description covers what kinds of changes are returned. It still leaves gaps around how tool_id is interpreted, what happens when no prior version exists, and the shape of the 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?

Schema description coverage is 0% and the description never mentions tool_id or what it identifies. The single parameter is self-explanatory by name, but the description does not compensate for the missing 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 states a specific resource and scope: metadata changes between consecutive published versions, with examples of the change categories. It is clear what the tool reports, though it lacks an explicit verb and does not differentiate itself from siblings such as get_evidence or check_before_install.

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 like get_evidence or check_before_install. The description gives no exclusions, prerequisites, or routing 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds useful substance by enumerating what an evidence record contains (URL, fetch time, SHA-256), which is behavior beyond the annotations, but says nothing about what happens when a field has no evidence or whether records are paginated.

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 compact sentence that front-loads the resource and then the payload fields. No filler, though the colon-list of return fields sits where usage guidance would have been more valuable.

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's enumeration of URL, fetch time, and SHA-256 is genuinely helpful for anticipating the response. However, for a two-required-parameter lookup tool it leaves gaps: no explanation of tool_id provenance, no behavior for missing evidence, and no linkage to the sibling tools that would precede this 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% with two required parameters, so the description must carry the load. It clarifies that 'field' is a field name, but 'tool_id' is never explained (format, source, or how to obtain it), leaving half the parameters undocumented in both schema and description.

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 (evidence records for a single assertion of a tool) and the keying parameter (field name), but it is phrased as a noun phrase rather than a verb+resource, and it never explicitly says 'retrieve' or 'return'. An agent can infer what it fetches, but the phrasing reads more like a return-value label than a statement of purpose, and it does not differentiate from siblings like get_tool or get_changes.

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 get_tool, get_changes, or search_tools, and no prerequisites or context are given. The agent must infer from the name alone that this is the drill-down for a specific assertion after inspecting a 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 readOnlyHint, idempotentHint and openWorldHint=false, so the safety and determinism profile is covered. The description adds that the result enumerates link state per ecosystem, which is useful context about what is returned, but says nothing about what happens when a publisher_key is unknown or partially linked.

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 compact sentence that front-loads the resource and taxonomizes the identity dimensions. Efficient, though the missing verb makes the opening marginally less scannable.

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 is the only source of return-value information, and it does outline the four identity surfaces plus link state. However, it leaves the required publisher_key's accepted formats unexplained and omits resolution-failure behavior, both of which an agent needs.

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 description says nothing about the single required publisher_key — no format, no accepted identifier shapes (namespace vs domain vs GitHub handle), no note on which ecosystems can be resolved. With the only parameter entirely undocumented, the description fails to compensate.

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 (publisher identity across MCP namespace, domain, GitHub, packages) and implies a lookup, but never states a verb such as 'retrieve' or 'look up'. It is clearly about publishers, which distinguishes it from get_tool or search_tools, but the action itself is only implied by 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?

There is no guidance on when to call this versus resolve_identifier or check_before_install, both plausible siblings for publisher/package workflow. No prerequisites, no exclusions, no stated call 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 the read-only, idempotent, closed-world profile, so the description is free to add substance — and it does: it discloses that auth stays null until sign-in metadata has been checked, that warnings are graded by severity, and that checks which could not run are reported rather than silently omitted. Declaring 'Never a safety rating' also pre-empts a likely misread of the output.

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 compact — one long enumerating sentence plus two short qualifiers — and the schema_version anchor is front-loaded. The trailing 'Never a safety rating' is the most routing-critical clause and would be stronger earlier, but nothing is wasted.

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

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

There is no output schema, so the description carries the burden of return-shape disclosure, and it does so by listing the payload's constituent parts and the null-auth state. The one remaining gap is that 'warnings' and 'contradicted claims' are named without saying what entity they attach to, but an agent can still call the tool 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?

With a single parameter at 100% schema description coverage, the schema already tells the agent that identifier accepts a server name, catalog id, or GitHub repo URL. The description adds nothing further about identifier handling, so the baseline of 3 applies.

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

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

The description opens with 'One stable answer (schema_version 1) for connecting an MCP server' and then enumerates the exact contents (remote URL, transport, packages, setup snippets, warnings). This is specific enough that an agent knows it retrieves connection/setup data, though the verb 'get' is implied rather than stated and the framing is more about the answer than the action.

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?

'One stable answer' plus 'Never a safety rating' implicitly separates this from evaluation-oriented siblings like check_before_install, but no sibling is named and there is no explicit when-to-use or when-not-to-use statement. The agent must infer the routing boundary.

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 adds useful context by disclosing the shape of the payload — per-assertion state, reason, check and evidence records — but says nothing about volume, pagination, or what happens with an unknown tool_id.

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 sentence fragment with no waste, and the field enumeration is front-loaded. However, the missing verb makes it read as a noun phrase rather than an actionable description.

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 does well to enumerate returned fields, which is the critical gap-filler. But it leaves out how to form tool_id and gives no hint about the result set's size or ordering for a one-parameter lookup 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 coverage is 0% — tool_id is an undescribed string — so the description bears full responsibility. It only hints that the parameter refers to 'a tool', without saying whether it is an ID, slug, or name, or where to obtain a valid value (e.g., via resolve_identifier or search_tools).

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 (a tool's assertions) and enumerates the returned fields — state values, reason, check, evidence records — so an agent knows exactly what data it yields. The verb is only implied ('Every assertion for a tool'), and nothing distinguishes it from the sibling get_evidence, 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?

There is no statement of when to call this instead of get_evidence, check_before_install, or get_changes, nor any exclusions or prerequisites. The agent must infer the use case from the field list 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 read-only, idempotent, non-destructive, closed-world behavior, and the description adds beyond that: no account required, and the notable non-exact-match fallback that returns the closest real names. It does not describe the shape of a successful entry, but the fallback and auth context are the higher-value disclosures.

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 core action, then the fallback behavior, then the auth note. 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 one-parameter read tool with rich annotations and no output schema, the description covers input forms, fuzzy fallback, and auth requirements. Only the format of a returned registry entry is 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?

Schema coverage is 0% and the single required param is bare, but the description compensates by enumerating accepted identifier forms: server name, catalog id, or GitHub repository URL. It stops short of format examples (scoped names, URL variants) that would fully close the 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?

Specific verb (resolve) plus a concrete resource (an MCP server name, catalog id, or GitHub repo URL to the real registry entry). The look-alike detection clause separates it conceptually from search_tools and get_tool, though no sibling is named 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 'so look-alikes and invented names can be caught' clause implies the verification use case, but it never states when to pick this over check_before_install, get_tool, or search_tools, nor any precondition such as doing this before install.

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 readOnly, idempotent, non-destructive and closed-world, so the bar is lower, and the description still adds real value by disclosing the return payload and a critical semantic caveat about verified_publisher meaning domain/org control rather than authorship. It does not mention result limits, ranking, 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?

Two sentences, front-loaded with the action, with no filler. The parenthetical caveat is dense but every clause carries necessary meaning; it could be split for readability but nothing is wasted.

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

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

With no output schema, the description correctly spends its budget explaining return fields and the classification enum. However, it leaves the official_only filter undefined and says nothing about result volume or ordering, which matters for a search tool with a limit cap.

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 and largely does not. 'By keywords' loosely explains query, but limit (max 50) and especially official_only are never defined — an agent cannot tell whether official_only filters to verified_publisher, official publishers, or something else.

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 ('search cataloged MCP servers by keywords') plus what the results carry (classification, identity level, warning counts). It is distinguishable from siblings like get_tool or get_publisher, though it never names them explicitly.

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

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

Usage is only implied: keyword lookup versus identifier lookup implies this is the discovery entry point before get_tool or check_before_install. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer the routing itself.

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