Run a free one-time external-perimeter scan on a domain.
Args: domain: the domain to scan (e.g. example.com) authority: MUST be true — attests you or your principal own/manage this domain. Scanning third-party domains without authority is prohibited. Scan takes 20-60s. Rate limit: 3/IP/24h.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| authority | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses scan duration (20-60s), a rate limit (3/IP/24h), and an important authorization requirement with a prohibition on scanning third-party domains. This is substantial behavioral context beyond what the schema provides.
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 well-structured with a short purpose line followed by an Args section. Each sentence provides necessary information: purpose, domain format, authority requirement, expected duration, and rate limit. It is slightly dense but every part 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, required inputs, authority constraints, timing, and rate limits. The main gap is that there is no output schema and no description of what the scan result looks like, so an agent must infer the return format. Still, the tool is simple and all invocation-critical information is present.
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 fully explain the parameters. It does: 'domain' is illustrated with an example.com format, and 'authority' is explained as a required attestation of ownership or management, including the prohibition against unauthorized scanning. This fully compensates for the schema's lack of parameter descriptions.
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 a specific verb and resource: 'Run a free one-time external-perimeter scan on a domain.' This clearly states what the tool does. It does not explicitly differentiate from sibling tools like pw_health or pw_watch_status, though 'one-time' hints at a distinction from ongoing monitoring 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 provides clear operational constraints: the domain must be specified, authority must be true, and third-party scanning is prohibited. However, it does not state when to choose this tool over siblings such as pw_health, pw_stats, or pw_watch_status. Usage context is implied but not explicitly contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool covers a distinct concern: API health, running a scan, aggregate stats, and watch-plan status. There is no meaningful overlap or risk of selecting the wrong tool for a task.
All tools share the consistent pw_ prefix and use snake_case with noun-like names. The pattern is predictable and uniform across the server.
Four tools is well-scoped for a focused perimeter-scanning API. Each tool has a clear purpose and none feel redundant or unnecessary.
The core workflow of running a free external scan and checking watch-plan status is covered, with health and stats as useful support. However, the paid watch-plan surface is read-only; there is no way to create, update, or cancel a watch plan through the server.