Skip to main content
Glama
IPGeolocation

IPGeolocation MCP Server

User-Agent Parser

parse_user_agent
Read-only

Read-only custom user-agent parsing via POST /v3/user-agent. Paid only for POST payload parsing. Cost: 1 credit per successful string. Parses only the explicit uaString value; it cannot read caller headers or transport metadata.

Instructions

Read-only custom user-agent parsing via POST /v3/user-agent. Paid only for POST payload parsing. Cost: 1 credit per successful string. Parses only the explicit uaString value; it cannot read caller headers or transport metadata.

Returns { user_agent_string, name, type, version, version_major, device, engine, operating_system }. Type fields can identify desktop/mobile clients, robots, malformed or scripted strings, anonymized strings, or unknown values. uaString must be the exact non-empty user-agent string; empty/null strings are rejected locally before any API call. force_refresh bypasses cached data, makes a new upstream request, and can consume credits. bulk_parse_user_agent handles multiple strings.

Input Schema

NameRequiredDescriptionDefault
uaStringYesThe user-agent string to parse (e.g. Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36).
force_refreshNoDefault false. When true, bypasses cached user-agent parsing data; a successful refresh makes a new upstream request and can consume credits.

Output Schema

NameRequiredDescriptionDefault
dataNoPresent on success: API result after field selection, redaction, and transport limits.
pageNo
errorNoPresent on failure, with isError: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.0.3
    • removedOutput schema / properties / data / additionalProperties / anyOf
      Removed value: -[
      -  {
      -    "type": "null"
      -  },
      -  {
      -    "type": "boolean"
      -  },
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "array"
      -  },
      -  {
      -    "type": "object"
      -  }
      -]
    • addedOutput schema / properties / data / additionalProperties / type
      Added value: +[
      +  "null",
      +  "boolean",
      +  "number",
      +  "string",
      +  "array",
      +  "object"
      +]
  2. Addedv2.0.1
  3. Removedv2.0.0
  4. Changed1 schema field changedv1.0.16
    • addedInput schema / properties / uaString / minLength
      Added value: +1
  5. Changed1 schema field changedv1.0.15
    • changedInput schema / properties / force_refresh / description
      Previous value: -"Default false. Leave unset unless the user asks to refresh or rerun."New value: +"Default false. Set true only when the user asks to refresh cached user-agent parsing data; a successful refresh makes a new upstream request and can consume credits."
  6. First observedv1.0.10

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare read-only and open-world, but the description adds the material business behavior: 1 credit per successful string, credits only charged for POST payload parsing, force_refresh triggers a new upstream request that can consume credits, and empty/null input is rejected locally before any API call. Cost and validation semantics are non-obvious and would otherwise cause surprise charges.

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?

Front-loaded with purpose, scope, and cost, then return shape, then edge cases. Dense but mostly earned; a couple of clauses (e.g. the type-field enumeration) sit on the edge of what an agent needs before invoking, keeping it just below top marks.

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?

Despite an output schema existing, the description names the return fields and their interpretive use (type can flag robots, malformed, anonymized, unknown), plus validation, cost, and sibling routing. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: uaString must be the exact non-empty string and is validated locally before any call, and force_refresh is tied to credit consumption and cache bypass. These are reinforcing operational constraints rather than new syntax, so 4 rather than 5.

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+resource (parses a user-agent string via POST /v3/user-agent) and immediately scopes it against the bulk sibling. An agent can distinguish it from bulk_parse_user_agent without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly limits scope ("Parses only the explicit uaString value; it cannot read caller headers or transport metadata") and routes multi-string use to bulk_parse_user_agent. This is exactly the when-to-use / when-not guidance an agent needs to avoid misuse.

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