Skip to main content
Glama

Ipqualityscore

by io.github.pipeworx-io

Check Ip

check_ip
Read-onlyIdempotent

Fraud detection & risk scoring for an IP address. Answers "is this IP a proxy, VPN, or Tor exit node?", flags bots/crawlers and recent abuse, and returns a 0-100 fraud score plus geolocation (country, region, city, ISP, connection type). Example: check_ip({ ip: "8.8.8.8", strictness: 1 }) Requires your own IPQualityScore API key, passed as _apiKey.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipYesIPv4 or IPv6 address to check, e.g. "8.8.8.8"
_apiKeyYesYour own IPQualityScore API key (BYO — Pipeworx does not supply one). Free tier at ipqualityscore.com; the key is on the account dashboard.
strictnessNoDetection strictness 0, 1, or 2. Higher = more aggressive proxy/VPN detection (more false positives). Default 1.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context by revealing an external API dependency and the need for a bring-your-own key, plus the specific output content (fraud score, geolocation fields). No contradiction with annotations.

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: purpose first, then a concrete example, then the key requirement. Every sentence contributes useful information, and there is no redundant restating of schema fields.

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?

The description explains the tool's purpose, input, external key requirement, and output characteristics despite lacking an output schema. An agent has enough context to call it correctly and interpret the result at a high level.

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 all three parameters are already documented in the input schema. The description reinforces the _apiKey requirement and shows an example call but does not add meaning beyond what the schema provides, so a baseline 3 is appropriate.

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 verb and resource: fraud detection and risk scoring for an IP address. The description answers concrete questions (proxy/VPN/Tor, bots/crawlers, abuse) and lists output fields, making it unambiguous and distinct from sibling tools like check_email or check_phone.

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?

Clearly defines the use case as IP risk assessment and provides the important prerequisite of a user-supplied IPQualityScore API key. It does not explicitly name alternatives or exclusion criteria, but the domain is clear enough for an agent to select it appropriately among siblings.

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

All Ipqualityscore toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation2/5

Multiple natural-language query tools (ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, validate_claim, discover_tools, suggest_questions) have heavily overlapping purposes, and the descriptions rely on subtle caveats to differentiate them. Similarly, entity_profile vs compare_entities vs recent_changes and ai_visibility_check vs scan_competitor_ai_presence blur boundaries. Only the four check_* tools (email/ip/phone/url) are cleanly distinct.

Naming Consistency2/5

There are some consistent prefixes (check_*, polymarket_*, ask_pipeworx_*, pipeworx_*) but the overall set mixes verb_noun, noun_verb, and standalone adjectival names (deep_research, entity_profile, bet_research, validate_claim, recent_changes). The pattern is readable within families but chaotic across the whole surface, with no unified convention.

Tool Count2/5

35 tools is excessive for a server branded 'Ipqualityscore', especially since only 4 tools actually serve that fraud-checking domain. The rest sprawls into general data research, prediction-market analysis, memory management, subscriptions, and npm dependency scanning — a far larger scope than the name implies. This is a scattershot collection rather than a coherent offering.

Completeness2/5

The IPQS core domain is thin (only email, IP, phone, URL checks) and missing common fraud-screening operations like transaction scoring or domain reputation. Conversely, the Pipeworx side is over-complete with redundant query paths, while unrelated subsystems (memory, subscriptions, feedback) create dead ends that don't serve the server's apparent purpose. The lack of a clear domain makes genuine completeness impossible to assess or claim.

Resources