AYA MCP Docs

Connect AI assistants to Ask Your Audience through its remote MCP server at https://mcp.askyouraudience.ai/mcp, with OAuth sign-in and explicit approval before any paid study.

Who this is for

Claude, Claude Code and ChatGPT users, agent developers, and teams adding AYA research tools to MCP-capable assistants.

What this page covers

Explain the AYA MCP server, its tools, and which assistants can connect.

Server

AYA runs a remote MCP server at https://mcp.askyouraudience.ai/mcp using Streamable HTTP. Users sign in with their own AYA account through OAuth and approve access once. Supported assistants are ChatGPT, Claude on the web, desktop and mobile, and Claude Code. Other MCP clients are not supported yet.

Tools

search_audiences and get_audience_details find and review existing audiences. prepare_concept_test returns the exact brief, selected digital twins and AYA-token cost without charging, and run_concept_test runs only an approved quote. Image Ad Evaluator, Focus Group and Interview have matching prepare and run tools where enabled for the account. get_study_status and get_study_results follow a run and return its findings; search_studies and get_saved_study read saved research with optional consent.

Approval and results

Preparation is free and every quote expires after fifteen minutes. Nothing runs or charges tokens without the user's explicit approval. Results are simulated digital-twin research, not a representative survey.

Developer evaluation path

Technical buyers should use the developer pages to understand the public integration surface, authentication model, connector routes, API concepts, and documentation map before building against AYA. Private consoles and account-specific tools remain outside the crawlable marketing surface.

AI agent context

These pages are written so coding assistants and retrieval agents can distinguish AYA APIs, MCP connectors, ChatGPT Actions, install guides, and reference material from the general product marketing pages.

Implementation boundary

A useful developer journey starts with the public docs, then moves into authenticated workspace setup only when the buyer is ready. Public documentation should explain what an integration can do, which workflows are available, how authentication is approached, how job status is handled, and where examples or reference material sit. It should not expose private customer data, secret tokens, or account-specific console routes to search engines.