AI & TechnologyAgent Tool Optimization: How to Get Your App Picked in Google AI Mode, Gemini, ChatGPT and Claude

Agent Tool Optimization (ATO) is the work of getting an AI assistant to pick your app’s tools when someone asks it to do a job your app does, and then to call them correctly. Google opened its Connected Apps Platform preview on October 28, 2026, so apps can now reach the Gemini app and, as Google’s phased rollout continues, AI Mode in Search. ChatGPT and Claude have their own directories. The same remote MCP server can reach all of them, if its tools are clear enough for a model to choose.

I checked every store fact below against Google’s, OpenAI’s and Anthropic’s own documentation on November 1, 2026. These programs are changing fast, so re-check before you build.

What Agent Tool Optimization is (and isn’t)

An AI assistant that has your app connected sees a short text about your server, a list of your tools, each tool’s description and the shape of its inputs. From that, it decides whether to call you. ATO is everything that improves that decision: which tools you expose, how you name and describe them, what they ask for, what they return, and how your store listing reads to the person deciding whether to connect.

It is not AEO. Getting your SaaS cited by ChatGPT and Perplexity is about your web pages being quoted in an answer. ATO is about your product doing the work: building the cart, booking the class, sending the invoice. A user who connects your app has already chosen you once, and ATO is how you get chosen again on each request.

Google is clear that a connected app has to add something the assistant can’t do alone. Its quality page lists three foundations: “Live, relevant data”, “Their personal context, from your service” and “Taking action”. It also says a connected app is not “Generic, signed-out information”. If your tools only return what a web search would, fix the product idea before the metadata.

Where your app can be picked in 2026

In Search, Google’s July 16, 2026 post says you can “connect your favorite apps directly to AI Mode in Search”. In Gemini, Google’s MCP guide says an app can be called with “@” and its name, or by mentioning the app in a prompt, and then stays in context for the session.

How the model decides which tool to call

Every assistant reads the same four layers. Fix them in this order, because each one depends on the one before.

1. Server instructions. One short paragraph about what your service covers and for whom. Google says to assume this text “will be added directly to the model’s system prompt” and to describe what the server can do, not how the model should think.
2. Tool names. A verb and a noun, in plain words: create_invoice, not handleBilling.
3. Tool descriptions. When the tool applies, what it needs and what it returns. Google calls the description “the only context the model has” to decide if a tool fits.
4. Parameter schemas. Types, allowed values and formats, so the model can fill them from the conversation.

Here is the difference for a made-up invoicing app.

Weak
  name: invoices
  description: Invoice tool. Use this for anything about invoices.
  inputs: action (string), data (object)

Better
  name: create_invoice_draft
  description: Creates a draft invoice for an existing client. Use the
    client_id returned by search_clients; don't guess IDs. Amounts are in
    the account's currency, in cents. Returns the draft's number, total and
    a link to review it. The draft is not sent to the client.
  inputs: client_id (string, required), line_items (array of
    {description: string, amount_cents: integer}, required),
    due_date (string, YYYY-MM-DD, optional)

The weak version hides several jobs behind one action field. Google flags this pattern in review: it says servers “exposing dozens of tools or deeply nested ‘mega-tool’ schemas will be flagged during review for fixes”. Anthropic rejects a single tool that accepts both read and write methods.

What the stores reject

Most rejections are metadata that tries too hard. All three stores ban the same family of tricks.

• Steering the model. Google’s policy prohibits “overly broad or deceptive capability descriptions to influence the model into selecting the Connected App over another”. OpenAI bans fields that instruct “the model to prefer one plugin over others”. Anthropic rejects descriptions that “Interfere with Claude calling other tools”.
• Naming or attacking rivals. OpenAI asks you to describe your plugin “without comparing it with other products”.
• Selling inside the listing. OpenAI’s guidelines say not to advertise pricing, trials or discounts in descriptions, and Google bans third-party advertising inside connected apps.
• Hidden behavior. Google prohibits “hidden, dormant, or undocumented features”, and Anthropic rejects hidden or encoded instructions.
• Asking for more than you need. Google says an app “may not pass review if tools request more context than required”, for example precise location when a city would do.

Keyword stuffing doesn’t help either. A description padded with every synonym reads as broad, and broad descriptions are exactly what the policies above reject.

The ATO checklist

Run it in three passes: build, listing, then measure. Use it before you submit anywhere, and again each time you change a tool.

Build

1. Give each tool one job. Use the invoice example above as the pattern: separate tools to create, update and delete, read tools apart from write tools, and no action or method field that switches behavior.
2. Write what the model reads as one set. The server instructions say what your service covers, who it is for and that every call runs in the user’s own account, without relisting tools. Each description says when the tool applies, in the words a customer would use (“bill Dana for March”), how it differs from the tool next to it, what formats it expects and what it returns. Then read all of it together and cut anything that repeats.
3. Make every input fillable. Say where an ID comes from (“from search_clients”), give formats (“YYYY-MM-DD”), list fixed values as an enum and keep IDs as strings. Google warns that long numeric IDs can be truncated and then reused wrongly. Ask only for what the task needs, never precise location when a city would do.
4. Annotate every tool. A title, readOnlyHint: true on read tools and destructiveHint: true on tools that change or delete data. OpenAI wants readOnlyHint, destructiveHint and openWorldHint set as explicit true or false values.
5. Return results the model can use. Short, labelled JSON, filtered on your server, with codes paired with names and units. A write returns what changed, because Google notes that models “often get confused by empty responses”. An error says how to fix the call (“No client named Acme. Search clients first”), where a bare 500 ends the conversation.
6. Hide internal tools. Health checks, admin routines and debug helpers stay out of the tool list.

Listing

7. Build the listing from facts. A plain name, a description that says what a user can do, real capabilities and example prompts in customers’ words, and your privacy policy and terms at stable public URLs. Google sets the tightest limits: one sentence under 30 words, at least 3 capabilities and at least 3 prompts.
8. Have a reviewer account ready. Google and OpenAI ask for a test account with sample data, and Google asks for two-factor sign-in to be off on it. Keep the same account ready for Anthropic’s review, and use a demo workspace, never a customer’s data.
9. Version the endpoint. Google snapshots your tools and server instructions at registration and warns that changing the schema “may cause the application to be disabled”. Put changes on a new path, such as /mcp/v2.

Measure

10. Call each tool the way a model would. With only what a model has after a normal request, every tool should succeed or fail with a fixable error. Do this in the MCP Inspector first, then in each assistant.
11. Run a weekly prompt set. “Track your prompts every week” below explains how.

The free app handover checklist is worth a look too: the store accounts, OAuth client and domain verification files should be in your company’s name, not your developer’s.

Store details that catch teams out

Google. The connected app category “cannot be changed later”, and it sets the capabilities Google expects you to support, so choose it with care. The listing needs a single-sentence description “under 30 words”, at least 3 capabilities and at least 3 example prompts, with at least 2 of them starting with your app’s name. You prove domain ownership with a file at /.well-known/google-connected-apps. Google supports the MCP specification “up to version 2025-11-25”, only over Streamable HTTP, and doesn’t yet support structuredContent, so return JSON as text.

OpenAI. Submissions come from a verified individual or organization, and the directory shows that verified name. The guidelines also say not to add “MCP” or “Plugin” to your product name. After you are published, OpenAI scans your server daily and lets eligible updates go live once automated checks pass.

Anthropic. Every tool needs a title and the right read-only or destructive annotation, tool names must be 64 characters or fewer, and authenticated services use OAuth 2.0. New listings appear as Community connectors by default, and Anthropic may move a highly useful one to Verified review. Anthropic doesn’t accept connectors that transfer money.

Approval gets you into the store, not into the answer

Approval gets you into the store. Being picked on each request depends on how well your tools work once people use them. Google’s console includes usage analysis, and its policy prohibits apps that “consistently return errors, crash, timeout, or authentication fails”. OpenAI says plugins with “strong real-world utility and high user satisfaction” may be eligible for directory placement or proactive suggestions.

So treat the first call as the product. Test each tool in the MCP Inspector, then in Gemini Developer Mode, as a custom connector in Claude and in ChatGPT, with ordinary requests a customer would type. Watch which tool the model picks and what it passes in, and fix the description when it guesses.

Track your prompts every week

OpenAI’s metadata guide suggests a “golden prompt set” with three kinds of prompts, and it works for every assistant:

• Direct: the user names your app (“@YourApp, send the March invoice to Dana”).
• Indirect: the user describes the job without naming you (“bill Dana for March”).
• Negative: requests your app should not handle, so you can catch false triggers.

Write 10 to 15 of these for the jobs your customers care about most. Run them weekly in Gemini, ChatGPT and Claude, and log whether your tool ran, what it was given, and whether the result was right. Change one description at a time, so you know which change moved the result.

Get your app picked

App369 builds MCP servers over your existing API and prepares the listing work: the tool list, the descriptions and schemas, and a submission packet with listing copy and privacy notes. Simon Dziak, the developer behind App369 in Miami, built and runs the MCP server for Workspace369, his own production SaaS.

The fixed-price MCP Connector for your SaaS covers the server and a directory-submission packet, and OAuth sign-in, which ChatGPT needs, is an add-on. That fixed offer targets the Claude and ChatGPT directories. For a Google Connected Apps listing or a larger tool set, send the details through the contact page and you get a written scope. Approval in any store is up to that store. For the build itself, see how to add an MCP server to your SaaS and MCP authentication: API keys vs OAuth.