Okay - let's see if I can re-state the problem to make sure I understand it.
There are three routers ISP, R1, and R2, and they are all connected into a /29 network.
You want ISP to prefer R1 for all traffic they send to you.
When they say this is something you need to do on your end, I'd say they're wrong (but they may be referring you to one of the following "automatic" methods). At the end of the day, you're trying to influence your INGRESS traffic, and as such, this can only be done by influencing the EGRESS policy of the ISP. Hopefully they're not expecting you to use AS_PREPEND to do this, because while that would work, it will have unwanted side effects.
Your situation is exactly what MED is for - "multi-exit discriminators" but local_pref is the defacto standard for this behavior in today's world.... BGP communities can be much more flexible than MEDs. To do this with MEDs - you would need to make sure that the OSPF cost to reach destinations from R2 should be at least one point higher than as seen from R1. (basically, the MED is based on whatever the IGP's metric is - so if RIP, then the number of hops gets imported, or if OSPF, then the cost gets imported, if static, then the distance gets imported)
eBGP must be configured to accept MED from the neighbor, so your ISP may or may not allow this.....
(TL;DR for LocalPref: You need to be able to send a community which means "don't prefer this so much" on everything that R2 sends to ISP, so that ISP will always prefer R1 over R2. The ISP must be configured to support this.)
LocalPREF is a value that has global meaning within a single ASN. It doesn't transit over eBGP to other ASNs. Local_pref affects OUTBOUND traffic, though - so it's the ISP who needs to set LocalPREF in THEIR router based on which of your routers a path was learned from. (basically, set local_pref to 99 for everything from R2 would be sufficient)
Note that this decreased local_pref shouldn't be so reduced that it falls below the preference of the ISPs other peers/transit providers. In this case, the ISP would consider R2 to be worse than going all the way around the Internet to reach you....
The common way that BGP providers allow their customers to have self-service LocalPREF is through the use of communities.
If your ISP accepts communities, then they can tell you what communities they accept, and how the communities affect their policy. Commonly-available community actions include such behaviors as "do not advertise to other peers", "prepend X times to other peers", "raise local_pref", "lower local_pref" and "blackhole"
Each carrier makes their own "menu" of services, though - in my case, AT&T only offers very basic ones as above, but Level3's list is pages and pages long, and you can get very detailed in what you want to do....
If they're using Cisco or Mikrotik, you might be able to ask them nicely to set the weight higher on all routes learned from R1.....
The problem with AS-PREPEND is that this affects the global view of your advertisements. If you have some other ISP2 out there, then any AS-PREPEND you send to ISP1 may affect the global balance of traffic being sent to you via ISP1/ISP2.... In other words, if R1 goes down, suddenly the prepended route via R2 will be the only one available to ISP1, who will now show a "longer" path to reach you... so the world may simply choose to avoid ISP1 entirely, when all you wanted was to tweak the balance between two specific links. If they want you to use AS-Prepend, tell them they're being silly and that they should use one of the above methods I mentioned.
When given a spoon,
you should not cling to your fork.
The soup will get cold.