"Graph" is an ambigous term, refering to different kinds of mathematical objects.
But whatever kind of graph you have in mind, each of these objects is an abstraction on its own, with certain operations which are essential to define the abstraction. For example, if you think of a graph in the sense of a line chart, the typical operations could be to
add some new points which are automatically inserted in a way to keep the points ordered according to their X coordinates
get out the points in X coordinate order
maybe delete or replace some points
maybe operations to calculate the intermediate lines between two neighboured points.
These are the public operations which should be part of the
Graph class itself - a graph which is just a container for a list of points, as shown in your example, without a public API which forms the abstraction, is quite pointless. On the other hand, every operation which is not part of that abstraction is better placed elsewhere.
Where exactly, depends. It depends on how the graph will be used in your system, which other places in your system are or could be available, and on the individual operation. Sometimes a class on its own is fine. Sometimes a static function is ok. Sometimes a function inside another class is sufficient, if that other class is the one-and-only place in the system where the operation is needed. And sometimes it is ok to make an exception from the rule, stay pragmatic and place the function directly in the
Graph class, just because you currently don't have a better place.
Note there is no hard-and-fast rule saying "this or that place is better", this is to some degree opinionated. Try to follow the SOLID principle, try to create coherent abstractions with disjoint responsibilities, and refactor as the program evolves. Often, a very simple operation, simple enough to be just one functions, starts to become more complex over time, which makes it necessary to refactor the logic of the function into many smaller functions which will then become refactored to a class on their own.