As you describe it, things go the following way: your Web site needs to forward a request to another Web site, and the latter will accept only if the request comes with an "authentication blob" which happens to be the hash of a user identifier and his password. This blob (the MD5 result) is then "the password" since showing it is sufficient to grant access; this is very weak with regards to eavesdroppers, since spying on the line would be sufficient to recover the blob, at which point the attacker could attach it to whatever requests he would like to send.
If the protocol is not as described above, but ties the hash to the requested data (e.g. the hash is not computed over the user ID and passphrase alone, but also on the path of the requested data), then the authentication is a bit less weak, but still not good; It would exhibit the two classic sins:
Eavesdropping reveals a hash value computed over the passphrase and some known data, allowing for an offline dictionary attack: the attacker just "tries" some potential passwords until a match is found with the observed hash. Since a 150$ GPU can compute billions of MD5 instances par second, even medium-strength passwords won't resist the onslaught for long.
The whole communication is unprotected, so eavesdroppers will observe the data itself (the data for which access authentication was used, so presumably sensitive data). Active attackers will be able to manipulate request and response in arbitrary ways.
Redemption is achieved with the use of SSL, which fixes both issues.