morningconsult_active_tenant
ChatGPTReturns the active tenant for the current user. If this conversation has prior calls to Morning Consult tools that returned active_tenant_id, consider the most recent active_tenant_id the active tenant. Otherwise, call this tool to determine the active tenant. The active tenant determines which data and resources are available in subsequent tool calls.
morningconsult_data
ChatGPTResolves a natural language query to Morning Consult public opinion data: custom commissioned research, brand perception, consumer and economic sentiment, political polling, and more. Data returned is either the response breakdown for a specific survey question, which every source supports, or a computed metric or score, which only some sources define (e.g. net favorability, NPS, reputation score, an index of consumer sentiment). Returns a reference to data sets. The query tool requires a reference returned by this tool. Optionally accepts a data_source to scope the resolution to a single data source. Call the datasources tool first to list available IDs. When data_source is omitted, the default data source (Daily Tracker) is used. If this conversation has prior tool calls that have returned an active_tenant_id, pass that tenant id as the active_tenant_id in calls to this tool. Otherwise, omit active_tenant_id to use the server default. What a source supports varies along three independent lines, and this determines how to phrase your query. Do not infer one from another: - Is it trendable? The datasources listing gives coverage start and end dates per country. A window spanning months or years can be trended and accepts a time frame; a single narrow window is a study fielded once, where a time frame is meaningless. - Does it define computed metrics? The Daily Tracker does, and so do economic and other trackers, each with its own indices and scores. Custom research studies define none, so a result there is the breakdown of respondents across one survey question's response options. Use search_metrics scoped to the source to find out — an empty result means the source has no computed metrics, which is a valid answer. Note that this is about computed metrics only: any source, including one with a full metric taxonomy, can also return a question's raw response breakdown — ask for a distribution, or a proportion of specific responses. - Are its questions predictable? Trackers ask a consistent set. A custom research study is bespoke, so use search_questions scoped to that data_source to see what it actually asked before querying it. Note that defining metrics does not imply supporting calculations or rankings. A tracker may carry indices and scores and still not support net calculations or top/bottom rankings. Where a source does not define one, ask for the underlying question and compute the figure yourself from the returned distribution with the query tool, rather than treating the request as unsupported. Structure your query using one of these patterns: {metric or attitude} of/toward/in {target} - "net favorability of Nike" - "index of consumer sentiment in Brazil" - "trust in Frontier Airlines" - "distribution of trust responses for Nike" - "support for restricting credit union acquisitions of community banks" {metric or attitude} of {target} among {population} - "buzz of Tesla among Democrats and Republicans" - "reaction to the McCormick-Unilever deal among suburban women" {metric or attitude} of {target} broken out by {dimension} - "approval of the president by political party" - "agreement that AI will take over parts of my job by generation" which {category} {attitude or behavior} - "which streaming services Gen Z uses" - "reasons people switched or cancelled their provider" share of {population} who {response} - "share of parents who find frequent-rider discounts believable" {dimension} profile/distribution of/among {population} - "demographic profile of Netflix users" - "distribution of income among Republicans" - A demographic profile already returns the full standard demographic breakdown (age, gender, income, race, region, education, etc.). Do NOT enumerate the facets you want — write "demographic profile of frequent Yelp users vs the general population", not "...by age, gender, income, race, region". top/bottom {N} {category} by {metric} (requires a source that defines rankings) - "top 5 senators by net approval" - "bottom 10 apparel brands by net trust" top {dimension} for {targ…
morningconsult_datasources
ChatGPTLists the Morning Consult data sources the caller has access to. Each data source includes an ID, a name, a description of what it covers, and its supported countries. Each supported country includes start and end dates denoting the corresponding coverage timeframe. If this conversation has prior tool calls that have returned an active_tenant_id, pass that tenant id as the active_tenant_id in calls to this tool. Otherwise, omit active_tenant_id to use the server default. Use a data source ID with the data tool's data_source parameter to scope natural-language queries to a specific source. When data_source is omitted, the default data source (Daily Tracker) is used. Read each source's description and coverage dates before querying it — they tell you how to phrase the query: - A coverage window spanning months or years indicates a continuously-fielded tracker. These carry pre-computed metrics (e.g. net favorability, NPS, ICS), and can be trended over time. - A single narrow coverage window indicates a custom research study, commissioned and fielded once. These have no pre-computed metrics — a result is the breakdown of respondents across one survey question's response options — and do not support calculations, rankings, or trending. Their questions are bespoke, so use the search_questions tool scoped to that data source to see what it asked before querying it. Data sources the caller does not have access to are not returned.
morningconsult_list_tenants
ChatGPTReturns the tenants the current user is a member of, each with an id and a name. A tenant scopes which data and resources are available in subsequent tool calls. Only one tenant is active at a time. Call the active tenant tool to see which one is active.
morningconsult_query
ChatGPTRuns a SQL query against a Morning Consult data resource URI returned by the data tool. Use SQL to perform aggregations, filtering, and subsetting of the data. The resource is exposed as a view — always reference it as FROM input (e.g. SELECT FROM input LIMIT 5). Use the `columns` metadata for the specific dataset URI being queried; datasets returned by the same data call can have different schemas. Only reference columns present in that dataset, including in ORDER BY. If the schema is unavailable, inspect it with `SELECT FROM input LIMIT 0 before querying. If a column is missing, correct the SQL using that resource’s columns rather than repeating the same query. If this conversation has prior tool calls that have returned an active_tenant_id, pass that tenant id as the active_tenant_id in calls to this tool. Otherwise, omit active_tenant_id to use the server default. When analyzing results: - Always include country, date range, and sample size (total_weighted_n) as part of the source information when presenting findings, and use the verbatim definitions in the audiences array when describing a population rather than paraphrasing its label. - Ground every conclusion in specific values from the response. Do not make inferences beyond the data (e.g. do not use high income as a proxy for urban). - Read each metric's description in the dataset's metrics array before interpreting its numbers. For composite metrics and index scores these carry methodology and interpretation guidance — what the metric is composed of, whether it is meant to be read as a level or as a change over time, which components explain a movement, and which breakouts are diagnostic. A technically correct query interpreted against the wrong reading of the metric is the most common way to reach a wrong conclusion, and the guidance is already in the response, so there is no need to look it up separately. - Percentage columns (data_type of percent or percentage_point) are on a 0 to 100 scale, not 0 to 1. Do not multiply them by 100 when reporting them. - Check the dataset's caveats before drawing conclusions. A resolution caveat means the query only partly resolved, so the data may not answer exactly what was asked — read what it says, report the gap alongside the findings, and re-query only where it points at something a different question or phrasing would fix. A low_sample_size caveat means check total_weighted_n row by row and flag the cells below the threshold. - If additional data is needed, call the data tool again with a refined query rather than inferring from the current result. - Where a source does not define a metric the request needs, derive it here rather than calling the request unsupported. Prefer a source's own metric whenever one exists, since its definition is documented and yours is not. When you do derive a figure, say so, state whether "don't know" and no-opinion responses are in the base — including or excluding them changes a net materially. - The question column in results holds each question's unique label, not its full text. Labels are stable keys within a data source + country pair — to recover verbatim question wording or answer-option text, pass the label to search_questions scoped to the same data source. - Significance is precomputed from the full response distribution, which is not in the dataset. Read sig_vs_prior_period and p_value_vs_prior_period instead of computing your own test. A test built from the net score and n alone cannot reproduce it. If asked to run a test, say the precomputed result is the answer and report it. - N/A means the comparison was not tested and na_reason says why (e.g. first period). When a period-over-period comparisons dataset is returned, each row is one test. Read direction (higher, lower, no difference), significant, confidence (e.g. 95%), and note which explains why a row was not tested. - The significance columns (sig_vs_prior_period, p_value_vs_prior_period, significant, p_value, confidence`) are strings, not numbers or booleans, becau…
morningconsult_search_metrics
ChatGPTReturns methodological documentation for Morning Consult's computed metrics and scores: how a metric is defined, what it is composed of, how to interpret it, and the label to use when asking for it. Results are ranked and carry a label, metric_id, description, and relevance score. The description is the payload — for a composite score it covers the methodology, the collection cadence, guidance on reading movements, and the formula. If this conversation has prior tool calls that have returned an active_tenant_id, pass that tenant id as the active_tenant_id in calls to this tool. Otherwise, omit active_tenant_id to use the server default. Use this when the user is asking about a metric rather than about data — "how is your Index of Consumer Sentiment defined", "what goes into it", "how should I read a two-point drop". The point of the tool is answering those without committing to a data fetch. To find out which metrics exist, use search_questions — it lists the metrics available for each question it matches, by label and identifier. Come here when a label alone does not tell you which of them you want, because that is a question about what the metric measures. Do not come here after fetching data, though: the same documentation rides along in each dataset's metrics array. If a methodological question does turn into a data request, use the metric's label as the {metric} phrase, since the data tool takes natural language and has no metric parameter. Searches exactly one data source, defaulting to the Daily Tracker only. Economic and other trackers define their own indices and scores, so call datasources and pass data_source when the request concerns another source. Every response echoes back the source it searched. An empty result set is a valid answer. Against a tracker it usually means you searched the wrong source, so find the right one and search again. Against a custom research study it means there is nothing to find: these define no computed metrics, which is expected and not an error. For those, the question wording and its response options are the methodology — use search_questions. Matches are ranked by relevance. The Daily Tracker drops weak matches; other trackers keep a longer ranked list up to limit. Read each description rather than trusting a high score. Optional filters: - country: restrict to metrics available for a specific country. - data_source: the data source to search. - limit: ceiling on how many results to return (default 20, maximum 100). Raise it to pull every component of a composite score, which explaining the composite usually requires. On trackers other than the Daily Tracker, raising it also returns more of the catalog.
morningconsult_search_questions
ChatGPTSearches the Morning Consult question catalog for survey questions matching a natural-language search term. Returns matching questions with their available metrics, response options, and a relevance score so you can inspect what is actually available for a topic. If this conversation has prior tool calls that have returned an active_tenant_id, pass that tenant id as the active_tenant_id in calls to this tool. Otherwise, omit active_tenant_id to use the server default. Whether to search first depends on how predictable the source's questions are: - Trackers — the Daily Tracker, and the economic and other trackers — ask a consistent set. The data tool is the primary path: when the user's intent maps cleanly onto that source, go straight to it and do not search first. - Custom research studies are one-off surveys whose questions are bespoke, so there is no way to know what was asked without looking. Search scoped to that data_source first. Raise limit (maximum 100) to see more of a small catalog; 100 will not dump a large study, so tighten the search text and search again rather than expecting a full inventory. Do not pass type on these sources — that filter is Daily Tracker-only and the call fails if it is set elsewhere. Use the datasources tool to tell them apart. Use search_metrics instead when you need what a computed metric means rather than which questions exist. Custom research studies define no computed metrics, so for those this is the only catalog worth searching. Also reach for it when the request does not cleanly map to an available source and you need to check whether a relevant question exists, or when a data result comes back empty, unexpected, or flagged with a resolution caveat and you need nearby questions to course correct. Matches are ranked by relevance. The Daily Tracker drops weak matches; smaller catalogs keep a longer ranked list up to limit. Turning these results into a data query Results are catalog metadata, not query text. Do not pass `label` values into the `data` tool verbatim. A question label is a compressed index key that often drops the concept being measured, so it resolves poorly. Use it only to confirm you found the right question, and compose the query from text. (Metric labels from search_metrics are the opposite case — those are query vocabulary, meant to be reused verbatim.) - label: "Priority on no payment fees" - text: "What matters most to you when receiving payment for work you have done? Select up to 2. -- There are no fees taken out of my payment" - ask for: "proportion who say having no fees taken out matters most when receiving payment for work" Phrase it as the `data` tool expects. That tool documents several patterns; the ones that fit question results best are {metric or attitude} of/toward {target}, which {category} {attitude or behavior} for a select-all battery, and share of {population} who {response} for a single response option. Add "among {population}" or "broken out by {dimension}" as needed, and check that tool's full pattern list rather than defaulting to {metric} of {target} for everything. With nothing better to go on, at least lead with a metric: "distribution of priority on no payment fees" beats the bare label. Question labels are unique per data source + country: within a given data source and country, each label maps to exactly one question, and the mapping is stable and bidirectional. Labels are therefore reliable keys — any question value returned by query or data can be passed back here, scoped to the same data source, to retrieve that question's verbatim text and answer options. These results describe questions, not audiences. The absence of a population field is not a constraint. Any question can be requested among a population or broken out by a dimension, and any question can also be a population — a usage, exposure or fandom question is population material as much as it is a target. Describe the population in plain language rather than building it from a label or a response optio…
morningconsult_set_active_tenant
ChatGPTSets the active tenant for the current user. If you need to view the list of available tenants for the user, call the list_tenants tool. The user must belong to the tenant specified by id. The response includes active_tenant_id. Keep track of this value, it supersedes any previous value for active_tenant_id, and consider it the user's active tenant for the remainder of the conversation.
morningconsult_active_tenant
Claudemorningconsult_data
Claudemorningconsult_datasources
Claudemorningconsult_list_tenants
Claudemorningconsult_query
Claudemorningconsult_search_metrics
Claudemorningconsult_search_questions
Claudemorningconsult_set_active_tenant
Claude
