PrufGate MCP

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

Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds useful detection categories, but it does not explain what the output looks like, where findings are reported, or how the scan is scoped beyond the parameters.

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 a single sentence with no wasted clauses, and the detection categories are front-loaded. However, the cryptic 'Engine 1:' prefix does not help an agent select the tool, and the fragment lacks a clear action verb.

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 scan tool with eight siblings and no output schema, the definition is too thin. It omits the action performed, expected results, how findings are surfaced, and when this tool should be chosen over the other prufgate engines.

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 all three parameters are documented in the schema with clear descriptions. The tool description adds no parameter-specific meaning, which is acceptable at full schema coverage but earns only the baseline score.

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 domain as fabricated production logic and lists concrete detection targets (canned fallbacks, simulated return values, stub handlers), which lets an agent infer an anti-fabrication scan. However, it never states the action with a verb such as detect, scan, or report, and it does not distinguish itself from the many sibling prufgate scan 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?

There is no guidance on when to use this tool versus prufgate_fast_scan, prufgate_full_scan, prufgate_test_audit, or the other siblings. No prerequisites, exclusions, or workflow context are provided.

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, non-destructive, open-world, idempotent behavior. The description adds that an active two-token probe against a live URL is gated on target_url — meaningful context about outbound network activity — but says nothing about what gets reported, credentials required for the two tokens, or rate limits. With annotations carrying the safety profile, this partial addition earns a 3.

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 clauses with no filler, and the conditional probe behavior is stated directly. The leading 'Engine 5:' label is the only noise, contributing nothing an agent can act on.

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 scanner with no output schema, the description should convey what findings look like or what the check surface covers. It covers the gating condition but leaves the agent unsure whether this is a static repo scan, a live probe, or both, and what result to expect.

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 both parameters are already fully documented, and the description only restates the target_url gating condition verbatim from the schema. No added syntax, format, or example information beyond structured fields.

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?

It names the resource being checked (routes and queries lacking auth or tenant scoping), which is specific, but there is no verb describing the action — is it a scan, a report, a probe? 'Engine 5' is opaque internal jargon that does not identify the operation, so an agent must infer it is the BOLA-specific check from the tool name 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?

The clause 'the live two-token probe runs only when target_url is set' gives one useful conditional, implying the workspace scan is the default and the live probe is opt-in. However, nothing says when to choose this over prufgate_fast_scan, prufgate_full_scan, or prufgate_contract_check, all of which likely overlap in security-scan territory.

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, non-destructive and a closed-world scan, so the safety profile is covered elsewhere. The description's added value is naming the three detection categories, which is genuine behavioral content; it says nothing about output shape, failure on a bad ref, or whether findings are advisory or blocking.

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 dense sentence with no filler, and the detection categories are front-loaded. The only waste is the 'Engine 4' ordinal, which consumes prime position with information an agent cannot use.

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?

Three optional parameters and no output schema mean the description could stay short, but for a multi-engine analysis suite the agent still needs to know what a run produces and how this check differs in depth from full_scan. Those gaps keep it at minimum-viable rather than 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%, with base_ref, changed_only and workspace_path each documented in the schema. The description adds no parameter meaning beyond that, which is acceptable at full coverage but earns only the baseline.

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 concrete things being detected (undeclared/hallucinated imports, undocumented env vars, frontend/backend route mismatches), which is a real resource scope rather than a tautology. However there is no verb at all and the leading label 'Engine 4' is opaque without product context, so an agent must infer that this is a static-analysis check.

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 statement of when to run this versus prufgate_full_scan, prufgate_anti_fabrication, or prufgate_diff_guard, even though several siblings plausibly overlap on import/route analysis. Nothing tells the agent what prerequisite state (a git repo, a configured baseline) is expected.

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 covered. The description's added value is the diff-scoping behavior (it analyzes changes against a base ref rather than the whole repo) and the specific defect classes flagged, but it says nothing about output shape, severity levels, or whether it blocks/fails. That is useful but thin additional 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?

One compact sentence with no filler in the detection list, which is good. However it is a noun-phrase fragment rather than a front-loaded statement of purpose, and the leading 'Engine 3:' token consumes prime space with information an agent cannot act on.

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 only two well-documented parameters and no output schema, the definition should carry more weight: what a finding looks like, whether results are per-file or aggregated, and how it relates to the eight sibling checks. The description provides a detection list but no return-value or routing context, leaving an agent unable to predict the response or choose it over prufgate_test_audit.

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 base_ref and workspace_path both documented in the schema, so the baseline is 3. The description reinforces that this is a differential scan against a base ref but adds no format details, defaults, or edge-case behavior 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 names a concrete set of things it looks for (skipped tests, suppression comments, unsafe casts, weakened lint/CI config) scoped to the diff, which is more specific than the name alone. But it never states a verb or that this is a scan/detection tool, and the 'Engine 3:' prefix is opaque internal jargon. An agent can guess it flags diff-introduced quality regressions but not with confidence against siblings like prufgate_test_audit or prufgate_full_scan.

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 use this versus prufgate_test_audit (overlapping skipped-test detection) or prufgate_fast_scan/prufgate_full_scan (whole-repo vs diff scope). The 'added in the diff' phrasing implies diff-scoped usage, but no prerequisites, exclusions, or alternative routing are given.

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 read-only, idempotent, non-destructive behavior. The description adds useful context by listing the five engines and changed-file scope, but it does not explain report format, failure behavior, or what the scan 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?

A single front-loaded sentence that names the engines and scope with no wasted text. It is compact and directly useful for tool selection.

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 read-only scan has full schema coverage and annotations that cover safety, but there is no output schema and the description does not explain the return value or failure semantics. That leaves an important gap for an agent deciding what to expect from the scan.

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 both parameters are already documented in the schema. The description only reinforces the changed-file scope and adds no additional meaning for base_ref or workspace_path 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?

Uses a specific verb ('Run') and names the exact engines included, plus scopes the scan to changed files. It is clear what the tool does, though it does not explicitly contrast itself with prufgate_full_scan or the individual engine 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 'fast_scan' name and 'changed files' scope imply a quick targeted scan, but there is no explicit guidance on when to use this versus prufgate_full_scan or individual engine tools. No prerequisites or exclusions are stated.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the conditional probe behavior, but omits the traits that most distinguish a 'full scan' — expected runtime, cost, and why it is heavier than the fast variant.

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 zero filler; the primary scope comes first and the conditional clause follows. Nothing is repeated or 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 says nothing about what a scan returns or how results are surfaced, and it never explains the 'engines 1-5' concept. For a heavy composite scan tool, that leaves real gaps for an agent deciding whether to invoke it.

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 all three parameters are documented in the schema with examples and defaults. The description only echoes the target_url condition already stated in the schema, adding no new 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 action (run engines 1-5 plus the diff reviewer over the whole workspace) and a conditional extra (BOLA probe when target_url is set), which contrasts implicitly with prufgate_fast_scan and prufgate_bola_check. However 'engines 1-5' is unexplained jargon, so an agent cannot tell exactly which checks are bundled.

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 'whole workspace' scope and the target_url conditional give some usage context, but there is no explicit guidance on when to pick this over prufgate_fast_scan, prufgate_bola_check, or prufgate_review. The choice is left to inference from the word 'full'.

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 covered. The description adds genuinely new behavior: the review is deterministic and base_ref is resolved the way 'prufgate check --changed' resolves it. It never says what the review produces (findings list, severities, exit status), which matters since there is no output schema.

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 tight sentence with no padding, and the core object (diff against base_ref) is front-loaded. The only wasted token is the meaningless 'Engine 6:' prefix, which also front-loads jargon instead of intent.

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 review/analysis tool with no output schema, the description leaves the agent unable to predict the result: no mention of what a 'review' returns, whether it blocks, what categories of issues it checks, or how it relates to the sibling check tools. Two optional params keep the surface small, but the missing return semantics is a real 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%, so both parameters are already documented in the schema; baseline is 3. The description adds only a little beyond that: the defaulting/derivation behavior for base_ref. workspace_path is not discussed at all.

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?

Names a verb ('deterministic review') and a resource ('the diff against base_ref'), so the rough shape is clear. But 'Engine 6' is opaque internal jargon and 'review' is never defined (lint? findings? pass/fail?), and the description does not differentiate it from the sibling prufgate_diff_guard, which sounds like it covers the same ground.

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 only usage signal is the parenthetical 'default: resolved like prufgate check --changed', which implies a CI-style changed-files workflow but is stated as a default-resolution detail rather than a when-to-use rule. There is no statement of when to pick this over prufgate_diff_guard, prufgate_fast_scan, or prufgate_full_scan.

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, but the description adds a crucial nuance the annotations don't: it reads a previously-written artifact from ./prufgate.sh, so results can be stale and no scan cost is incurred. It does not state what happens when no report 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?

A single sentence with no waste; the no-scan constraint is front-loaded where an agent will see it 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 simple one-param read tool with rich annotations this is close to sufficient, but with no output schema the description should indicate what is returned (raw SARIF vs. Markdown text) and the failure mode when no prior report 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?

Schema coverage is 100% with the single optional workspace_path fully documented, so the description adds nothing about parameters. 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?

Precise verb+resource: 'read the last SARIF/Markdown report'. It implicitly contrasts with the scan siblings by stating 'without running a scan', though it never names them directly.

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 phrase 'without running a scan' implies the retrieval use case versus the prufgate_*_scan siblings, but there is no explicit 'use this when you already have a report; use prufgate_full_scan to produce a fresh one' routing 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the detection categories, which hints at what findings come back, but says nothing about result volume, whether it executes tests, or how findings are reported.

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 short fragment, so there is no waste, but it is not front-loaded with the most important information: 'Engine 2' leads while the actual subject (scanning test integrity in a repository) is never stated. Brevity here reflects under-specification rather than disciplined 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?

This is a parametrized scanner with no output schema, so the description should explain what a run returns (findings list? score? file locations?). It also leaves ambiguous the default behavior when no base_ref is supplied. Given a 3-parameter tool in a family of nine, this is thin.

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 all three parameters fully described (base_ref, changed_only, workspace_path), so the schema carries the load. The description adds no semantics about how these parameters interact with the engine, e.g. that base_ref only matters when changed_only is used.

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 specific defect classes the engine detects (zero-assertion tests, tautologies, self-mocked units, weakened assertions), which does separate it from sibling engines like prufgate_bola_check or prufgate_contract_check. However, it never states the action: there is no verb indicating it scans/audits a repository's test suite, and 'Engine 2' is opaque without outside context.

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 guidance on when to run this engine versus the eight sibling prufgate tools, no prerequisites, and no mention of whether it should follow prufgate_fast_scan or feed into prufgate_review. The agent must infer the workflow entirely.

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