port_activityGet recent attack/probe activity for a TCP/UDP port from SANS ISC — daily counts of report records, distinct target IPs, and distinct source IPs hitting the port. Useful for spotting scanning surges against services like SSH (22), RDP (3389), SMB (445), or Telnet (23). Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| port | Yes | A port number, e.g. 22 (SSH), 3389 (RDP), 445 (SMB), 23 (Telnet). |
Changes observed during successful MCP inspections.
Input schema / examplesAdded value: +[
+ {
+ "port": 22
+ },
+ {
+ "port": 3389
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructiveness. The description adds the key behavioral trait 'Keyless' (no API key required) and identifies the data source (SANS ISC), which is valuable beyond annotations. No contradictions.
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 no extra words, front-loading the core purpose, then adding usage guidance and keyless status. 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 zero output schema, the description explicitly lists what the tool returns (daily counts, distinct target IPs, distinct source IPs). Combined with annotations and usage guidance, it fully covers the tool's behavior for its simple 1-parameter interface.
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 100% schema coverage for the single 'port' parameter, the description adds examples (22, 3389, 445, 23) and links them to services, enhancing the schema's basic 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 clearly states it 'Get recent attack/probe activity for a TCP/UDP port from SANS ISC' with specific outputs: daily counts of report records, target IPs, and source IPs. This distinguishes it from siblings like ip_reputation or threat_level.
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 concrete usage examples ('spotting scanning surges against services like SSH, RDP, SMB, or Telnet') and mentions common port numbers. It does not explicitly exclude conditions or mention alternatives, but context is clear.
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.