Setting Up Metadata for Indirect Prompting.

Indirect prompting is the ability for your app to appear automatically when a user describes what they need without them typing your app's name. If you skip this step, your app only shows up when users explicitly call it.

The fix is in how you configure tool metadata.

Understand which user requests your app should handle

Before writing anything, define:

• 3-5 prompts where users should trigger your app (without naming it)
• 1-3 prompts where your app should stay out of the way

For example, if your app helps users find auto parts by VIN code, the indirect trigger might be "Which brake pads fit a BMW 3 Series?" - the user isn't asking for your app by name, but your app is the right tool.

Write tool descriptions that help the model choose your app

Add 1-3 sentences to each tool description explaining what the app does, who it's for, and why it's better than the model answering alone. Example: "This app generates a meal plan for the user based on a selected calorie target and macronutrient ratio."

Then structure your tool descriptions to include three types of prompts:

Direct prompts - examples where the user explicitly names your product or data source.

Indirect prompts - examples where the user describes the outcome they want without naming your tool.

Negative prompts - cases where built-in tools or other connectors should handle the request. These prevent your app from firing unnecessarily.

12 Recommendations for Tuning Metadata

These are based on both official guidelines and real testing:

1. One job per tool. Keep each tool focused on a single read or write action. This helps the model choose between alternatives correctly.
2. Explicit inputs. Define the full inputSchema including parameter names, data types, and enums. Document defaults and nullable fields so the model knows what is optional.
3. Predictable outputs. Enumerate the structured fields you'll return, including machine-readable identifiers the model can reuse in follow-up calls.
4. Separate read and write. If you need both read and write behavior, create separate tools so ChatGPT can respect confirmation flows for write actions.
5. Custom connector priority. For indirect prompts, give the model enough context in tool descriptions to select your connector instead of a built-in alternative.
6. Precision hinting. Use words like "exact," "precise," or "explicit" wherever possible. These highlight your tool's accuracy and its ability to produce better results than the model alone.
7. Name describes the action. Tool names must be a verb describing an action: search_products, create_invoice, get_order_status.
8. Unique and explicit names. Even if methods are functionally similar, their names should be clearly distinguishable: search_by_name vs. search_by_id.
9. Include edge cases. If a tool might crash or produce an empty result, define what it should do next.
10. Don't push changes too frequently. The LLM may need time to adapt. During tuning, up to 2 commits per day before testing is a reasonable pace.
11. Start with simple inputSchema. Use the most LLM-friendly parameter names possible. A simpler schema means fewer errors and faster model adaptation.
12. Track changes in a table. To avoid flying blind during tuning, log how results change after each update. Define your key prompts, then fill in results after each commit.