Skip to main content
Glama
ffraud
by FFraud-com

IP abuse reports

ip_reports
Read-onlyIdempotent

Read community abuse reports for an IPv4 or IPv6 address to see what it was reported for, when, and by how many distinct reporters—evidence behind a fraud score.

Instructions

The community abuse reports filed against an IP: what it was reported for, when, and by how many distinct reporters. Use it when you want the evidence behind a score rather than the score alone.

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": {
      "ip": "<ip>"
    },
    "name": "ip_reports"
  }
}

Input Schema

NameRequiredDescriptionDefault
ipYesThe IPv4 or IPv6 address to read reports for.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds value beyond that by disclosing what the response contains — report reasons, timestamps, and the count of distinct reporters, which signals an aggregated read rather than a raw dump. It does not mention pagination, result caps, or behavior when no reports exist.

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?

Two tight sentences: the first front-loads what the tool returns, the second gives the usage decision. No filler, no restatement of the title, and nothing that could be cut without losing information.

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

Completeness4/5

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

For a one-parameter read tool with rich annotations and no output schema, the description covers purpose, return content, and selection guidance adequately. The remaining gaps — pagination, volume limits, and empty-result behavior — are minor for a lookup of this simplicity.

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?

There is a single required parameter and the schema already documents it fully as an IPv4 or IPv6 address. The description adds no format, normalization, or edge-case detail about the address beyond the schema, so the baseline 3 for full schema coverage 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?

States a specific resource (community abuse reports filed against an IP) plus the exact content returned (reason, timestamp, distinct reporter count). The clause contrasting 'the evidence behind a score rather than the score alone' implicitly separates it from the score-oriented siblings such as ip_check, so an agent can pick between them without opening a schema.

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 a clear selection rule: use this when you want the underlying reports rather than the score, which also implies the when-not case (just want the score → use the score tool). It stops short of naming the alternative tool explicitly or covering cases like an IP with no reports, so it is strong but not exhaustive.

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

Deploy Server

Other Tools