The retrieval of this data would require the use of sockets. You'd need to be familiar with HTTP protocols, specifically reading, and sending valid headers, and how to parse the data that follows after a header.

Here is a VERY primitive example using the URL in your first post. This is far from a complete solution to requests, it doesn't account for possible location redirects, nor does it account for the potential of multiple SOCKREAD event fires. Depending on the amount of data you're getting back, it may be impossible to fit it all within an entire buffer.
Code:
alias httpr.example {
  var %socket = httpr.example
  if ($sock(%socket)) { echo -a * Error: Socket already open... }
  else {
    echo -a * Establishing a secure connection to api.scorpstuff.com on port 443
    sockopen -e %socket api.scorpstuff.com 443
  }
}
on *:SOCKOPEN:httpr.example: {
  echo -a * Connection Success, building header and sending request.
  bset -t &Header 1 $+(GET /daysuntil.php?mydate=2019-12-25 HTTP/1.0,$crlf,User-Agent: mIRC,/,$version,$crlf,Host: api.scorpstuff.com,$crlf,Accept */*,$crlf,Connection: close,$crlf,$crlf)
  sockwrite $sockname &Header
}
on *:SOCKREAD:httpr.example: {
  var %temp
  echo -a * Attempting to retrieve return headers seperated by newlines.
  while (1) {
    sockread -n %temp
    if (!$sockbr) { break }
    else { 
      if (%temp != $null) { echo -a %temp }
    }
  }
  echo -a * Attempting to retrieve any leftover data on the socket that may not have a new line character.
  while (1) {
    sockread -f %temp
    if (!$sockbr) { break }
    if (%temp != $null) { echo -a %temp } 
  }
}


And here's the return:
Code:
* Establishing a secure connection to api.scorpstuff.com on port 443
* Connection Success, building header and sending request.
* Attempting to retrieve return headers seperated by newlines.
HTTP/1.1 200 OK
Server: nginx/1.14.1
Date: Sat, 09 Feb 2019 21:51:49 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
* Attempting to retrieve any leftover data on the socket that may not have a new line character.
319


As for your question about links within mIRC, there's certain characters which aren't allowed within any given URI, you'll notice these characters get packed if you look in your browsers URL bar after doing a search on google or something. these forbidden characters are converted to a hex representation of it's ascii value in the form of %XX with the exception of a literal space, which becomes a plus "+". An example would be the "&" symbol, which would become "%26".

mIRC's URL catcher follows these rules and breaks upon detecting a character within a URI that it knows not to be valid, and stops processing here, assuming that anything beyond that illegal character most likely isn't part of the link.

here's another quick couple of aliases to help in formatting a properly escaped URI:

Code:
alias URI.Sub { var %dontpack = ~ ! @ $ * ( ) - _ = : ' , . / ? | return $iif($istok(%dontpack,$1,32),$1,$+(%,$base($asc($1),10,16,2))) }
alias URI.encode { return $replace($regsubex($1-,/(\W)/g,$URI.Sub(\t)),$+(%,20),+) }


Example usage:
//echo -a $URI.encode(this is a @#&*%^#@ test)

Example Output:
this+is+a+@%23%26*%25%5E%23@+test

Each argument passed as part of a query string's value SHOULD be encoded in this manner, browsers tend to do this for you on the fly if you just did this in the URL bar, but this isn't your browser.

What is an argument? it's some "item=" following after the ? of a given URL, they're separated by the "&" symbol.

Some Pseudo code of using this alias in conjunction with constructing your own proper URI:

//echo -a https:// $+ some.url.here $+ /?caster= $+ $URI.encode(#Joe Bob) $+ & $+ follower= $+ $URI.encode(Some dude)


Which results in the following return:
https://some.url.here/?caster=%23Joe+Bob&follower=Some+dude

of which the entire link is properly captured by mIRC.

Your GET/POST request which contains a query-string (get method, it's the "?..." stuff following the URL, post it's just the encoded stuff as a new line after the header, unless you're encoding in another method such as multipart/form-data) in a valid HTTP header MUST also be encoded in this manner for almost ALL http daemons to properly process your request, if mal-formed you may wind up getting a error code 400, Bad Request as a return.

I'd strongly recommend reading up on HTTP/1.0 and HTTP/1.1 protocols and learn the inner workings of communicating with a http server.