As Marc mentioned, the primary key is a logical construct and doesn't by itself indicate the clustering key. I won't repeat that info in my answer here, but if you want a deeper explanation of the differences between the structures behind clustered and non-clustered indexes, I have a video here which may be helpful for you.
Now, it's entirely possible for the missing index DMVs to (correctly) tell you that an additional index on the primary key column alone is something that could have helped a query. Why?
If a query needs to scan all the PK column values in the table (and only that), it's more (perhaps much more) expensive to scan either the clustered index or another non-clustered index to get that information. A narrow index that only contains the PK column would be more efficient than that, particularly if there's a merge join involved where the key order is being exploited.
And so the missing index algorithm kicks in and suggests that the narrower index on only the column(s) it needs would be helpful.
The course of action to resolve the suggestion is dependent on the queries that are running and what other indexes you have, and getting into that is beyond the scope of this question, so I'll leave it there.
Where the missing index DMVs aren't so helpful is when it suggests slightly narrower indexes that match indexes you already have. It's also known in some cases to incorrectly suggest exact duplicates of indexes that already exist. For these reasons, you're right to filter the DMV output through your own brain and judgement instead of automatically creating the indexes it suggests.