Skip to main content
Glama
Sign In

isIPsafe

by com.isipsafe
OverviewDiscussionsAdmin

Analyze log traffic

analyze_logs
Read-only

Find malicious traffic in logs. Pass raw log lines from any source (nginx/Apache/IIS access logs, sshd/auth.log, syslog, firewall such as iptables/UFW/pfSense/ASA, mail servers, Windows events as text, CEF, JSON lines from a SIEM or cloud, CSV); every IPv4/IPv6 address is extracted wherever it appears and each non-blank line is one event. Returns how many events came from malicious (score 75+), suspicious (25-74) and unreported addresses, the top offenders with score and attack categories, the busiest addresses, countries, networks, attack categories, detected log formats, HTTP status classes, failed logins and the time range. Each distinct address looked up counts as one lookup against the daily allowance, busiest first. Per analysis: without a key 256 KB and 100 addresses, free key 2 MB and 1,000, Enterprise 5 MB and 10,000. The log is not stored. Remove secrets (passwords, tokens) before sending.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "logs": "<logs>"
    },
    "name": "analyze_logs"
  }
}

Input Schema

NameRequiredDescriptionDefault
logsYesThe raw log text, one event per line, in any format

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: it discloses quota mechanics (each distinct address = one lookup, busiest first), per-tier payload and address caps (256 KB/100, 2 MB/1,000, 5 MB/10,000), and a privacy guarantee ("The log is not stored"). That is exactly the operational context annotations cannot express.

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

Conciseness4/5

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

Purpose and input contract are front-loaded, followed by return shape, then quotas and the privacy/secret warning — a sensible ordering. The long parenthetical catalog of log sources is dense but each item earns its place by preempting format questions.

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?

With no output schema, the description compensates by enumerating the return payload (score-band counts, top offenders, countries, networks, categories, formats, status classes, failed logins, time range). Combined with quota, size limits and non-retention, an agent has everything needed to call this once correctly.

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

Parameters2/5

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

Schema coverage is 100% and the single parameter is already described as "raw log text, one event per line, in any format." The description restates the same idea and adds only indirect meaning (format list, size ceilings) without naming the parameter or clarifying edge cases like blank lines beyond "each non-blank line is one event."

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?

Opens with a specific verb+resource ("Find malicious traffic in logs") and immediately bounds the scope: raw log lines from any source, every IP address extracted, one line = one event. It is clearly distinguishable from single-IP siblings like check_ip or check_network because it operates on whole log payloads and returns aggregate breakdowns.

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?

Gives strong invocation context — accepted log formats, that the input is raw unparsed text, and a pre-send precaution ("Remove secrets... before sending"). It stops short of explicitly naming when to route to check_ip/check_network for a single address, so the when-not guidance is implied rather than stated.

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

All isIPsafe toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources