scamgate

Overview Schema Source Related Servers Discussions Admin

check_url

Read-onlyIdempotent

Verify a link before opening it to get an allow, ask, or deny verdict with risk score and plain-English reasons, so agents can decide whether to proceed.

Instructions

Check a link before opening it. Returns a verdict: decision (allow | ask | deny), risk_score 0-100, plain-English reasons, and checked_host, the host the link really opens. If the decision is ask, stop and show the reasons to the human. If deny, do not proceed. Results are advisory, not a guarantee.

Input Schema

Name	Required	Description	Default
`url`	Yes	The full URL the agent is about to open.
`intent`	No	What the agent is trying to do, e.g. "book a hotel in Galway".

Output Schema

Name	Required	Description	Default
`reasons`	No
`summary`	Yes
`advisory`	No		scamgate is advisory. It can miss scams and flag legitimate actions; a human should make the final call on anything flagged.
`decision`	Yes
`warnings`	No	Notes about the check itself, e.g. a stale feed cache
`risk_score`	Yes
`checked_host`	No	For links: the host scamgate judged, the one a browser would open. If it isn't where you expected the link to go, treat that as a warning. Empty for payments and unreadable links.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Oct 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds important context: the result shape, the advisory limitation, and what the agent should do for 'ask' and 'deny'. It also explains checked_host, which is useful behavioral detail.

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

Conciseness5/5

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

The description is compact and front-loaded: it states the action first, then the verdict fields, then the required decision handling. Every sentence adds operational value.

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

Completeness5/5

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

Although an output schema exists, the description still gives enough context to use the tool correctly: what it returns, how to interpret 'ask' and 'deny', and its advisory limitation. Combined with rich annotations and full schema coverage, nothing important is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so both the required url parameter and optional intent parameter are already well documented. The description does not add parameter-level meaning beyond the schema, 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.

Purpose5/5

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

The description uses a specific verb and resource: 'Check a link before opening it.' It also states the verdict fields returned, making the tool's purpose unambiguous and distinguishable from siblings like check_payment and update_feeds.

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

Usage Guidelines4/5

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

It clearly says to check a link before opening it and gives explicit downstream behavior for 'ask' and 'deny' verdicts. It does not name alternatives or state when not to use the tool, which keeps it just below a 5.

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

Deploy Server