Changin approach for estimates - from ManDays to Story Point

but as a PM I also need to consider the total MD I can allocate in a sprint (considering people, vacations etc). 

Why would a PM allocate anything to anyone in Scrum?

The only purpose of estimation is for the Developers to get their arms around how much work they can take on in a Sprint. Everything else reduces to value delivery and empirical process control. That's what stakeholders, including clients, should care about if they wish to get on top of complexity.

Originally, story points were used to compute implementation time. The team would estimate the work in the ideal time to complete the work - that is, how long it would take them to finish if they were to sit down and focus exclusively on the work without interruptions. Then, they would multiple that estimate by a load factor. For the particular team, it took 3 calendar/real days to get 1 ideal day's work done, so they multiplied their estimates by 3. At first, they called these estimates "days". However, stakeholders were confused, so they started calling them "points". Somewhere along the line, the process got lost and story points became a generic relative estimation for "effort" or "complexity".

It's very confusing to me that you are equating story points to man-days. You're effectively just changing the name of the estimation unit, which doesn't do anything for people's understanding. At least the original team was transforming the data from estimated ideal time to estimated calendar time.

I'm also not clear why the client cares about your estimation approach at all. Like Ian says, the purpose of estimation, if you perform it at all, is to help the Developers understand the work and make sure that it is reasonable for a Sprint. Estimation, complexity, and velocity should be of no concern to your stakeholder. Instead, they should be concerned with the outcomes enabled by the team. A client should be asking if the team is meeting their commitments, which come in the form of Sprint Goals, Sprint-over-Sprint. If the team is achieving their Sprint Goals, they should be asking if the value of the Sprint Goal is worth the cost of the team for the Sprint. If the team isn't achieving their goals or if the goals being achieved aren't worth the cost, those are specific conversations that can be held and Sprint Reviews and Sprint Retrospectives are good opportunities

I'd also suggest that no one should be allocating work for a Sprint. The Developers should be pulling in work based on what they believe this can be accomplished. This could be based on estimates or it could be based on historical throughput. The team can make decisions about evaluating the impact of vacations, holidays, and leaving an appropriate buffer for the unexpected like sick leave.

From the way you describe this, it sounds to me like you are a outsourcing company working for another software company and the one paying the bills wants some more insights into the work.  Otherwise, I don't understand why they would care about the complexity and velocity.  Those are terms that people involved in agile practices would recognize and use.  That being the case, seems like you have a situation where your level of transparency with your stakeholder is not high enough and they are asking for more. While what @Ian and @Thomas say about delivered value being what the stakeholders should care about is true and I usually agree, if my assumptions are accurate, you have a higher level of transparency needed. 

...but as a PM I also need to consider the total MD I can allocate in a sprint (considering people, vacations etc). 

In that sentence I read PM as Project Manager, not Product Manager.  A Product Manager doesn't allocate anything.  A Product Manager ensures that everyone, on or outside the Scrum Team, understands the Product Goal, how the items in the Product Backlog support that goal, and that the Product Backlog is ordered in a way that will ensure the Scrum Team is focusing on the items that deliver the most value. A Sprint is a set timebox that is a month or less in duration. The work that is done in the Sprint is determined by the Developers based upon the Product Goal, the Sprint Goal created for that Sprint, the ordering of the items in the Product Backlog and their estimates of what can be completed during the Sprint timebox.  I am having a real hard time understanding where your allocation comes into play.