Tool store placement tuned to how models pick tools

These stores rank on retained conversations, not installs, and one lever moves both discovery and retention: whether the host model picks your tool when a user phrases the need in their own words. On the last three placements, one in the ChatGPT apps directory and two in the Microsoft 365 agent store, rewriting the invocation surface moved successful invocations per install further than any change to store copy, in one case from under a third of installs to just over two thirds. Invocation testing: The work opens with a phrasing set: 150 to 300 real user requests taken from your support inbox, sales calls and in-product search, written the way people actually type them, misspellings kept. Each is run against the host model with your tool installed alongside the competing tools a user would plausibly also have, and selection is recorded. That baseline is usually uncomfortable, and it is the only honest place to start from. What changes: Tool name, the description the model reads, parameter names, the examples in the listing, and the order in which capabilities are declared. Parameters take the user's vocabulary rather than your database's. Capabilities that overlap with a store-native feature are removed rather than defended, because the host model will pick its own. The phrasing set is then re-run and the difference reported per intent cluster, so you can see which intents you won and which you still lose. First run: Permissions are requested at the moment they are needed, not at install. The first turn returns something real without configuration, even if it is a reduced version of the full answer. Most retention loss in these stores happens inside the first exchange, which makes it a product decision rather than a marketing one. I raise it with your product lead directly and expect to be argued with. What gets measured: Selection rate against the phrasing set, install to first successful use, conversations per installed user in week four, and the stated reasons at uninstall where the store exposes them. Store impressions are recorded and deliberately not optimised against. Not included: Application development, backend work, review solicitation in any form, install-count campaigns, or submission handling for stores where your legal entity is not already approved. I do not write your privacy policy or run the store review appeal, though I will tell you which line triggered the rejection. Who this is not for: Teams whose product does not yet answer the question better than the assistant answers it unaided. Store placement makes that comparison happen sooner, not later. Buyers who treat installs as the outcome. Anyone who needs the listing live next week, because the phrasing set takes several days to build properly and building it badly makes every number after it meaningless. How it runs: Baseline test, rewrite, re-test, submission, then a read at week four against the same phrasing set to catch drift after a host model update. Model updates change selection behaviour without notice, so the phrasing set is written to be re-run by your own team on a schedule long after the engagement ends. Working language is English. Ecommerce and education products are where I have run this most often; other categories are taken case by case.