Skip to main content
Glama

URL parse

url_parse
Read-onlyIdempotent

Parse a URL into its components and query parameters, flag tracking parameters, and optionally return a cleaned URL with tracking removed.

Instructions

Split a URL into protocol, user, host, port, path, query, fragment and origin (with decoded forms), list its query parameters in order (duplicates and bare flags kept, + as space) and flag tracking parameters (utm_*, fbclid, gclid, msclkid, mc_cid, _ga, _hsenc…). Optionally returns the URL with tracking removed. A missing scheme means https://. Passwords are never echoed. Web version: https://s3eidat.github.io/url-toolkit/

Input Schema

NameRequiredDescriptionDefault
urlYesThe URL to parse.
stripTrackingNoAlso return "cleanUrl" with tracking parameters removed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, closed-world), and the description adds real substance beyond them: a scheme-less input is coerced to https://, passwords are never echoed, duplicate and bare query params are preserved and '+' is treated as space. It does not state behavior on malformed URLs, which is the main remaining gap.

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 the core action and output shape, then defaults, then privacy behavior; nearly every clause carries information. The tracking-parameter enumeration with an ellipsis and the web-version link are mildly expendable but not wasteful.

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?

With no output schema, the description carries return-value disclosure and does it well, enumerating fields and the optional cleanUrl. It falls just short of complete by omitting error behavior for unparseable input, which matters for a parser.

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 baseline is 3, but the description genuinely adds semantics for both parameters: it explains the implicit 'https://' default for a scheme-less url and clarifies that stripTracking yields a cleanUrl with the listed tracking parameters removed. That goes beyond the terse schema text.

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?

Uses a specific verb ('split') on a specific resource ('a URL') and enumerates the exact output components (protocol, user, host, port, path, query, fragment, origin, decoded forms), plus a query-parameter listing and tracking-flag pass. This makes it trivially distinguishable from the encoding-oriented siblings url_encode/url_decode and from useragent_parse.

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

Usage Guidelines3/5

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

Usage is implied by the purpose (call it when you need a URL dissected or tracking stripped), and the stripTracking behavior is described. However, no sibling is named and there is no explicit when-not guidance, so the agent must infer the boundary against url_decode/url_encode on its own.

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