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

No annotations are provided, so the description carries the full burden. It discloses that the tool evaluates and returns a decision, but it does not explicitly state whether it is read-only, whether it requires special permissions, or what form the decision takes. Some behavioral context is present, but important transparency cues are missing.

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 sentences, front-loaded with the core purpose and immediately followed by usage guidance. Every word earns its place with no redundancy or 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 two-parameter tool with no output schema, the description covers purpose, usage context, and a minimal return concept ('decision'). It does not explain possible decision values or side-effect behavior, but the tool is simple and the input schema is complete, so the context is mostly sufficient.

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%, with both `policy` and `artifact` documented in the schema. The description adds no extra parameter detail, so the baseline score 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 names a specific verb ('Evaluate'), the resource ('artifact against an organization policy'), and the output ('return the decision'). It also distinguishes itself from general safety checks with 'rather than whether it is generally safe', separating it from sibling verify tools.

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 when to use the tool: 'Use when the user asks whether something is allowed by their rules'. It also provides a when-not via 'rather than whether it is generally safe', clearly differentiating this policy check from general safety verification.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only 'fetch' but does not disclose authentication needs, rate limits, error handling, or pagination behavior. The 'signed' descriptor is about data nature, not tool 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, with the first stating purpose and the second giving usage context. Every word earns its place; no filler or redundancy.

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, the description is the primary source of context. It covers purpose and usage but leaves gaps: the limit parameter is unexplained, and the return structure is only vaguely described as 'signed attestations.' The simplicity of the tool raises the score, but these omissions prevent a higher rating.

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 only 50% (artifact is documented, limit is not). The description does not mention the limit parameter at all, nor does it explain how it affects results. It adds context for the artifact via 'verdict' but fails to compensate for the undocumented limit.

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 'Fetch' and identifies a concrete resource ('signed attestations behind an artifact verdict'), which clearly distinguishes this tool from siblings like verify_artifact or search_artifacts. The phrase 'artifact verdict' provides domain context without ambiguity.

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 explicit when-to-use guidance: 'Use when the user asks for evidence, provenance detail, or wants to verify offline.' It lacks explicit exclusions or alternative tool mentions, but the context is clear enough for an agent to choose this tool over verification-oriented siblings.

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?

With no annotations, the description carries the full burden. It discloses that the tool performs a reachability/token check and reports plan/quota, implying a read-only operation. It doesn't mention rate limits or exact error behavior, but the core behavior is well explained.

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 concise sentences: the first states what it does, the second gives usage context. No fluff or redundancy.

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 parameterless tool, the description is fairly complete: it covers purpose, usage trigger, and the content of the report (plan and quota). It doesn't specify exact response structure, but no output schema exists and the simplicity makes it sufficient.

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 no parameters, so the baseline is 4. The description adds context by explaining what the status check covers, though there are no parameter meanings to clarify beyond 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?

The description clearly states the tool's function: checking API reachability, token validity, and reporting plan/quota. It uses specific verbs and resources, and differs from sibling tools that handle verification, attestation, policy, and search.

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?

Provides explicit guidance on when to use the tool ('Use when other tools fail') and the diagnostic purpose ('to tell an outage apart from a plan or credential problem'). This clearly distinguishes its use case from alternatives.

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?

With no annotations, the description must carry the behavioral disclosure burden. It adds the key behavior of resolving to a concrete package URL, which is useful, but does not mention search semantics (e.g., fuzzy vs exact), result count, pagination, or error behavior. This is minimal but non-tautological 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?

Two sentences, front-loaded with purpose, and zero filler. The second sentence adds immediate usage context. Every word 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 search tool with only two simple string parameters and no output schema, the description covers the core purpose, provides a concrete use case, and hints at the return type (URL). It lacks details about behavior with multiple results or no results, but is adequate for an agent to invoke correctly in the stated workflow.

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% with descriptions for both 'query' and 'ecosystem', so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema provides, though it reinforces that 'query' is a vague package name.

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 states 'Search Phylax for artifacts by name' with a specific verb (search), resource (artifacts), and scope (by name). It also distinguishes itself from sibling verification tools by noting its role in resolving vague names to concrete URLs before verifying.

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 explicitly says 'Use to resolve a vague package name to a concrete package URL before verifying it,' providing clear context for when to use this tool. It implies the alternative (verifying) without naming specific siblings, but lacks explicit exclusions or when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses the return format: 'Returns ALLOW, WARN or BLOCK with a risk score and findings.' This clarifies the output behavior. It does not explicitly state read-only nature or permissions, but the verb 'verify' implies non-destructive assessment.

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 only two sentences long, front-loads the core action, includes concrete examples, and avoids redundant details. 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?

Given no output schema, the description adequately explains the return format (ALLOW/WARN/BLOCK with risk score and findings) and the input format. It does not cover edge cases or policy semantics, but for a straightforward verification tool it is sufficiently 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 100%, so the description adds limited value beyond the schema. The artifact parameter is already described with an example in both schema and description; the policy parameter is described in schema but not addressed in the description. No additional semantic nuance is provided.

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?

Description clearly states the tool's purpose: 'Verify a software artifact before installing, executing or depending on it.' It uses a specific verb and resource, and distinguishes itself from siblings by focusing on a single artifact and providing package URL examples (pkg:npm/express@4.18.2, pkg:pypi/requests@2.32.3).

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?

Provides explicit usage context: 'Call this before suggesting an install command for any third party package.' This is a clear trigger condition, but it does not mention alternatives or when NOT to use the tool. Sibling tools like verify_artifacts or check_policy could be alternatives, yet they are not named.

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?

No annotations are provided, so the description must carry full behavioral disclosure. It does not explain what 'verify' means (e.g., integrity, authenticity, policy checks), nor does it describe failure behavior, output format, or any side effects. This leaves significant ambiguity for a batch-verification 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?

Three concise sentences: the first states the core function, the second gives concrete use cases, and the third provides an explicit alternative. No filler or redundancy; 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?

The description covers purpose and usage well, but lacks key context: there is no output schema, and the description does not disclose what the response contains (e.g., per-artifact results, pass/fail summary). The undocumented 'policy' parameter also leaves gaps. It is adequate for basic selection but not fully complete for invoking 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 50%: the 'artifacts' parameter has a description, but 'policy' does not. The tool description adds no information about the 'policy' parameter or its relationship to verification. The agent is left guessing what policy values are valid or required, despite the description mentioning use cases.

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 ('verify') with a concrete resource ('many artifacts') and explicitly contrasts with the singular sibling tool ('verify_artifact'). The phrase 'Verify many artifacts in a single call' clearly communicates what the tool does and differentiates it from similar tools.

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 explicit use cases: 'checking a dependency list, a lockfile, or several candidate packages at once.' It also provides a direct alternative by stating it is 'preferred over calling verify_artifact repeatedly,' which helps the agent choose between siblings.

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?

Without any annotations, the description carries full responsibility for behavioral disclosure. It does well by detailing the checks performed: provenance, requested permissions, unsafe operations in the tool surface, and known risk signals. It stops short of stating potential side effects or return behavior, but the verification focus makes side effects unlikely and the disclosed checks are genuinely useful.

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 sentences, front-loaded with the core purpose, and contains zero filler. Every clause adds value: the action, the timing, the specific checks, and the explicit call-to-action.

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 tool is simple (one parameter) with no output schema, but the description covers the trigger context, the verification scope, and the action rationale. It does not describe the return value or how to interpret results, which could be useful for a verification tool, but the essential context for selecting the tool is provided.

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 schema provides 100% coverage for the single 'server' parameter with a clear description and example. The description adds no additional parameter-level semantics, but the schema fully explains what is needed, so a baseline score of 3 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 clearly states the specific verb 'Verify' and resource 'Model Context Protocol server' with the exact context ('before connecting to it or enabling its tools'). It also enumerates the verification dimensions (provenance, permissions, tool surface, risk signals), which makes the tool's scope unambiguous and distinguishes it from sibling tools like verify_artifact or check_policy that target different resources.

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 provides an explicit temporal instruction ('Call before adding any third party MCP server') and clarifies when it should be invoked ('before connecting to it or enabling its tools'). It does not explicitly name alternatives or exclusions, but the when-to-use guidance is strong and unambiguous.

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