Velocity is not something that is calculated, it is measured. Velocity is the amount of work that is completed in a Sprint. In this particular case, since you estimate work in Story Points, you will have a Velocity in Story Points. At the end of a Sprint, you can look at all of the work that is Done (per the Definition of Done), sum up the Story Points and that is your Velocity for the previous Sprint.
Capacity is how much work a team can take on. In Scrum, I prefer to represent this as a percentage and only consider the members of the Development Team. If all members of the team are working for the entire Sprint, the capacity is 100%. In a 2 week Sprint with a Development Team of 5 people, if there is a company holiday and no other time off, the Capacity of the team would be 90%. I keep Capacity very high level and approximate keeping it at full days (someone taking the morning off is computed as them taking a full day off), but there are people who prefer more fine-grained capacity. When thinking about Capacity, it's also useful to consider any specialized skills that individuals have.
The concept of Yesterday's Weather can be helpful to you for forecasting and planning a Sprint. Yesterday's Weather says that your next Sprint's forecast is very likely to be closely related to the actual results of your most recently completed Sprints.
In your example, you have completed one Sprint and have a known Velocity of 13. You should plan on a Velocity of close to 13 for your next Sprint. Once you have a few Sprints completed, you can take a look at the Velocity of the previous few Sprints and use a sliding-window average. A common recommendation is to use the 3 most recent completed Sprints. However, you should also adjust for capacity.
Note that Velocity, Capacity, and Yesterday's Weather are not a part of Scrum as defined in the Scrum Guide. Scrum is silent on the methods used to plan a Sprint.
I would also recommend that you try to have more Product Backlog Items refined and ready for development work than you can bring into the Sprint. Should your team increase their performance (or perhaps the work was over estimated), you probably don't want people to be idle. They should have something to do, such as investigating and defining upcoming work or being able to get a start on the next highest priority item in the Product Backlog.
