People will queue up to tell you that shrinking files is discouraged, but apparently I'm saying it first. If the log file wants to be big then you should let it be big. But let's assume that you do have to shrink the file.
I don't see why you couldn't put in a Shrinkfile command in SQL Agent to run like that, if the Agent user has the rights. "Every two days" is tricky, but you could easily set it to run on 3 week-nights out of 7. Or, run the job, but it only does the shrink when DATEPART(dayofyear, GETDATE()) is an even number. If you do 3 out of 7 in the schedule, then you can also run the job manually whenever you want to.
Now, why is your log growing? Do you know? If you are already using Simple Recovery, then each completed transaction should release space in the log file to be used again. So, either there is one transaction that is monstrously large - which might be rewritten to use less log (for instance: truncate table, all rows, instead of delete) - or a transaction that isn't completed and isn't rolled back, for a long time, so that log space isn't released and every other operation needs to use new log space. Or... what else?
I think I calculated that 63 megabytes was a suitable increment for log growth because it would add 4 virtual log files (compartments inside the actual file) of the largest possible size and therefore avoid creating too many of them (which is non-optimal). But I don't have my notes right now. It isn't a universal rule, or a rule for all databases. I think that for smaller databases I used 16 MB log increment and 1 MB starting size.