Which brands sponsor Spanish-language podcasts and YouTube channels in Spain and Latin America.
Scored across 7 tools
Several tools overlap substantially: search_podcast_sponsorships accepts brand and show filters, making it a near-superset of get_brand_podcast_sponsorships and get_podcast_sponsors, and check_brand_on_show is essentially a scoped variant of the same brand×show lookup. Descriptions distinguish granularity (raw placements vs. aggregates vs. yes/no), which helps, but an agent must read carefully to pick correctly.
All names are snake_case and follow a verb_noun pattern (get_, list_, find_, search_, check_). Minor inconsistency in the verb vocabulary and length (get_brand_podcast_sponsorships vs get_podcast_sponsors) slightly obscures the symmetric brand↔show pairing.
Seven tools for a focused sponsorship-intelligence domain is well-scoped; each tool covers a distinct query shape (lookup, ranking, discovery, free search). No filler tools.
The surface covers brand→shows, show→brands, category and country rankings, lead discovery, and filtered search, which is solid coverage for the domain. Minor gaps: no explicit listing of available shows or brands, and no time-trend comparison beyond the fixed 30-day window.
Check whether a given brand has a written sponsorship mention on a given Spanish-language podcast or YouTube channel in the last 30 days. Comprueba si una marca tiene mención de patrocinio escrita en un programa. Returns status (mention_found, no_mention_found, brand_unknown, show_unknown), the matching episodes with date, promo code and link, and how many other shows the brand sponsors. no_mention_found does not prove an ad did not air: read-aloud ads that are not written in the description are not visible. Data comes from written episode descriptions, not audio. / Los datos salen de descripciones escritas, no de audio.
| Name | Required | Description | Default |
|---|---|---|---|
| show | Yes | Podcast or channel name, e.g. 'Spicy4tuna' | |
| brand | Yes | Brand name, e.g. 'Hostinger' |
| Name | Required | Description |
|---|---|---|
| show | Yes | |
| brand | Yes | |
| status | Yes | |
| mentions | Yes | |
| last_date | Yes | |
| next_step | Yes | |
| show_page | Yes | |
| brand_page | Yes | |
| first_date | Yes | |
| mention_count | Yes | |
| show_candidates | Yes | |
| brand_candidates | Yes | |
| brand_other_shows | Yes | |
| show_has_other_sponsors | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantive behavior beyond them: the data source is written episode descriptions rather than audio, so read-aloud ads are invisible and no_mention_found is not proof. That is exactly the kind of limitation an agent needs to avoid over-claiming a negative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core check, then the enumerated status values, then the limitation and data-source caveat — a sensible order with no wasted sentences. The bilingual Spanish duplication adds length without adding information, which is the only thing keeping it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, yet the description still names the status outcomes and payload (episodes with date, promo code, link, plus other shows sponsored). Combined with the 30-day window and the audio-vs-written caveat, nothing an agent needs to interpret a result correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters carry examples, so the baseline is a 3; the description adds meaning by scoping 'show' to a Spanish-language podcast or YouTube channel and defining the match condition as a written sponsorship mention, plus the 30-day window that governs the query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: check whether a given brand has a written sponsorship mention on a given Spanish-language podcast or YouTube channel within the last 30 days. It is clearly distinguishable from the sponsor-discovery siblings (find_sponsor_leads_for_podcast, list_top_podcast_sponsors) because it resolves a single brand-show pair rather than enumerating sponsors, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context — a 30-day lookback, Spanish-language shows only, and written (not audio) evidence — and warns what a negative result means before the agent acts on it. It does not explicitly name alternatives or say when to prefer the discovery siblings over this check, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which brands could a podcaster, network or agency pitch for sponsorship? ¿A qué marcas proponer un patrocinio? Takes a Spanish-language show and returns brands that sponsored similar shows in the last 30 days but did not sponsor this show. Similar means same category and country; if that finds nothing it widens to same category, then same country, and says which in basis. Data comes from written episode descriptions, not audio. / Los datos salen de descripciones escritas, no de audio.
| Name | Required | Description | Default |
|---|---|---|---|
| show | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| show | Yes | |
| basis | Yes | |
| found | Yes | |
| leads | Yes | |
| next_step | Yes | |
| candidates | Yes | |
| similar_shows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real behavioral context the annotations cannot: a 30-day lookback window, the widening fallback logic surfaced via 'basis', and the caveat that data comes from written episode descriptions rather than audio. It does not, however, state result ordering, coverage limits, or what happens on an unrecognized show.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and front-loaded: the core question, then the selection rule, then the fallback, then the data-source caveat. The bilingual duplication doubles the token count, but each mirrored sentence carries equivalent substantive content rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-shape explanation is unnecessary, and the description still volunteers that a 'basis' field indicates which similarity rule fired. The main gap is the unresolved 'show' identifier format, which the schema also leaves at a bare minLength-2 string.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for two parameters. It contributes one meaningful constraint — the show must be Spanish-language — but never says whether 'show' is a name, slug, or ID, or that matching requires exact identifiers. The 'limit' parameter (default 10, max 25) is not mentioned at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb-and-resource framing ('which brands could a podcaster pitch') and states the exact result set: brands that sponsored similar shows in the last 30 days but did NOT sponsor this one. The negative-sponsorship filter and 'similar means same category and country' rule make it distinguishable from siblings like get_podcast_sponsors at the definition level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies when to use it (prospecting sponsor leads for a show) and explains the fallback cascade: same category + country, then same category, then same country, reporting which in 'basis'. It stops short of explicitly excluding siblings or naming an alternative for the case where you want existing sponsors of the show instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where does a brand advertise in Spanish-language podcasts and YouTube channels? ¿En qué podcasts se anuncia una marca? Returns every show the brand sponsored in the last 30 days with episode counts, last date, promo codes and offers. If the name is ambiguous it returns candidate brand names instead. Data comes from written episode descriptions, not audio. / Los datos salen de descripciones escritas, no de audio.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand name, e.g. 'Trade Republic' |
| Name | Required | Description |
|---|---|---|
| brand | Yes | |
| found | Yes | |
| shows | Yes | |
| next_step | Yes | |
| brand_page | Yes | |
| candidates | Yes | |
| total_episodes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the 30-day time window, returned fields such as episode counts and promo codes, the ambiguous-name fallback, and the important limitation that data comes from written episode descriptions rather than audio. This adds substantial behavioral context without contradicting the read-only annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key question and return behavior. However, the bilingual repetition of the opening question and the duplicated data-source sentence add redundancy that does not help an agent select or invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers scope, time window, return contents, ambiguity handling, and data provenance. With an output schema for return details and annotations for safety/idempotency, an agent has enough information to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the brand parameter is already documented with an example. The description adds meaningful semantics by explaining that an ambiguous brand name returns candidate brand names instead of shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns every show a brand sponsored in Spanish-language podcasts and YouTube channels. The 30-day scope, episode counts, promo codes/offers, and ambiguous-name fallback make the purpose concrete and distinguishable from podcast-centric sponsor tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening question establishes clear usage context: this tool is for finding where a brand advertises. It also explains the ambiguous-name fallback and the data source, but it does not name sibling alternatives or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who sponsors a given Spanish-language podcast or YouTube channel, and which promo codes does it read? ¿Quién patrocina este podcast? Returns each sponsoring brand in the last 30 days with episode counts, last date, codes and offers. If the name is ambiguous it returns candidate show names instead. Data comes from written episode descriptions, not audio. / Los datos salen de descripciones escritas, no de audio.
| Name | Required | Description | Default |
|---|---|---|---|
| show | Yes | Podcast or channel name, e.g. 'Tengo un Plan' |
| Name | Required | Description |
|---|---|---|
| show | Yes | |
| found | Yes | |
| country | Yes | |
| sponsors | Yes | |
| next_step | Yes | |
| show_page | Yes | |
| candidates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered; the description adds genuinely new context beyond that: a 30-day lookback window, the exact fields returned per brand, an ambiguity fallback, and the important limitation that data comes from written episode descriptions rather than audio. It stops short of discussing coverage gaps (shows that never write sponsor credits) or freshness beyond the 30-day window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core answer ('who sponsors this show, with codes') is front-loaded, and the caveat about written descriptions is placed at the end where it belongs. The text is doubled in Spanish and English, which is defensible for a bilingual/Spanish-market tool but roughly halves the information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full annotation coverage, the description need not explain return values, yet it summarizes them anyway and adds the data-source caveat and ambiguity path — enough for an agent to call it correctly. Minor gaps: no mention of what happens for shows with no sponsors in the window, or of result limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema description coverage, so the schema already documents it and the baseline is 3. The description does add scope information the schema lacks — the name refers to a Spanish-language podcast or YouTube channel, and ambiguity triggers candidate names — but no formatting or matching rules beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and the question it answers: which brands sponsor a given Spanish-language podcast or YouTube channel, with promo codes. It is clear what the tool returns (brands in the last 30 days with episode counts, last date, codes) but never names a sibling such as check_brand_on_show (which asks the inverse question) or search_podcast_sponsorships, so sibling differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrasing ('who sponsors a given podcast'), and there is one useful behavioral cue — if the name is ambiguous, candidate show names come back instead. There is, however, no explicit guidance about when to prefer this over check_brand_on_show or find_sponsor_leads_for_podcast, nor any stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which brands advertise in a podcast category (finance, technology, sports, news, comedy, education...), optionally within one country? ¿Qué marcas se anuncian en podcasts de una categoría? Category names follow Apple Podcasts in Spanish; accents optional. Returns brands ranked by number of shows sponsored in that category over the last 30 days, with example shows and codes. If the category is not recognised it returns available_categories. Data comes from written episode descriptions, not audio. / Los datos salen de descripciones escritas, no de audio.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| country | No | Country of the show; accents optional / País del programa; tildes opcionales | |
| category | Yes | Category, e.g. 'Negocios y finanzas', 'Tecnología', 'Deportes' |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| category | Yes | |
| sponsors | Yes | |
| next_step | Yes | |
| candidates | Yes | |
| category_page | Yes | |
| total_placements | Yes | |
| available_categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description still adds real context: the 30-day ranking basis, the sample shows and codes in the response, the available_categories fallback, and the provenance caveat that data comes from written descriptions rather than audio.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and well structured, but every sentence appears twice (Spanish then English), roughly doubling length without adding information. The bilingual format may be intentional, but it costs density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return shape, ranking logic, fallback behaviour and the Spanish-category naming convention are all covered; an output schema exists, so further return-value explanation is unnecessary. The unmentioned limit parameter is fully documented in the schema, leaving no real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 67% schema coverage, the description meaningfully supplements the schema by specifying that category names follow Apple Podcasts in Spanish with optional accents — detail not present in the schema's example strings. Country's optionality is stated in the description and limit is left entirely to the schema, which is adequate given its default and bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb-and-resource statement: brands advertising within a podcast category, with scope defined by a category and optional country. It doesn't name the closest-sounding sibling (list_top_podcast_sponsors), so the agent must infer the distinction from the category scoping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is clearly implied ('Which brands advertise in a podcast category... optionally within one country') and a fallback is described for unrecognised categories. But there is no explicit when-not guidance and no routing to alternatives such as get_podcast_sponsors or list_top_podcast_sponsors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which brands sponsor the most Spanish-language podcasts and YouTube channels, overall or in one country? ¿Qué marcas patrocinan más podcasts? Returns brands ranked by number of different shows sponsored in the last 30 days. Data comes from written episode descriptions, not audio. / Los datos salen de descripciones escritas, no de audio.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| country | No | Country of the show; accents optional / País del programa; tildes opcionales |
| Name | Required | Description |
|---|---|---|
| country | Yes | |
| sponsors | Yes | |
| next_step | Yes | |
| period_end | Yes | |
| period_start | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description rightly spends its words elsewhere: it discloses the ranking metric, the 30-day window, and critically that data comes from written episode descriptions rather than audio — an important coverage caveat for interpreting results. It stops short of stating result counts or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core content is front-loaded and useful, but the Spanish lines largely restate the English ones ('¿Qué marcas patrocinan más podcasts?' duplicates the opening question), roughly doubling length without adding information beyond the data-source caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value detail is not required, and annotations carry the safety profile. The description supplies what the structured fields cannot — ranking basis, time window, and the descriptions-not-audio provenance — leaving only the limit parameter's behavior unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: country is documented in-schema and the description reinforces its single-country scope, but limit (default 10, max 25) is never explained in the description. The added value over the schema is modest, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb and resource: it returns brands ranked by number of distinct shows sponsored over the last 30 days, across Spanish-language podcasts and YouTube channels. The ranking/aggregation framing implicitly separates it from per-show siblings like get_podcast_sponsors or check_brand_on_show, but no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Overall or in one country' tells the agent the country filter is optional and scoped to a single market, which is implied usage guidance. However, there is no explicit when-to-use-this-vs-alternatives statement and no note on when it would be better to use search_podcast_sponsorships or list_sponsors_by_category instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search which brands sponsor Spanish-language podcasts or YouTube channels, filtered by brand, show, country or only ads with a promo code. Busca qué marcas patrocinan podcasts y canales en español, por marca, programa, país o con código de descuento. Returns placements from the last 30 days: brand, show, country, episode date, promo code, offer and links. Not for shows outside Spain and Latin America. Data comes from written episode descriptions, not audio. / Los datos salen de descripciones escritas, no de audio.
| Name | Required | Description | Default |
|---|---|---|---|
| show | No | Podcast or YouTube channel name, partial is fine | |
| brand | No | Brand name, partial is fine, e.g. 'Hostinger' | |
| limit | No | ||
| country | No | Country of the show; accents optional / País del programa; tildes opcionales | |
| with_promo_code | No | Only placements that include a promo code |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| next_step | Yes | |
| period_end | Yes | |
| period_start | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds two facts annotations cannot carry: results are limited to placements from the last 30 days, and the data is extracted from written episode descriptions rather than audio. Those are exactly the coverage limits an agent needs before trusting or re-querying results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is front-loaded: purpose, filters, returns, exclusions, and data provenance each occupy one sentence with no filler. The cost is that every sentence is duplicated in Spanish, which roughly doubles length without adding information for any single reader.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter, zero-required search tool with an output schema, the description covers scope, exclusions, recency window, and data provenance. Nothing an agent needs to decide whether to call it or how to interpret weak results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 80%, so the baseline is 3; the description adds framing by presenting show/brand/country/with_promo_code as combinable filter axes rather than standalone fields. It says nothing about limit semantics or the partial-match behavior, leaving those entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search which brands sponsor Spanish-language podcasts or YouTube channels') plus the available filter axes, so the agent knows exactly what domain object is being queried. It never names a sibling such as get_brand_podcast_sponsorships or check_brand_on_show, so the boundary with those tools has to be inferred rather than read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use signals (filter by brand, show, country, or promo-code-only) and an explicit when-not ('Not for shows outside Spain and Latin America'). It stops short of pointing at the alternative sibling tool for the excluded case, so routing is only partly resolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_brand_on_showfind_sponsor_leads_for_podcast2 fields changedOutput schema / properties / next_stepAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data_limits": {
+ "type": "string"
+ },
+ "verify_on_air": {
+ "additionalProperties": false,
+ "properties": {
+ "free_check_url": {
+ "type": "string"
+ },
+ "order_url": {
+ "type": "string"
+ },
+ "text_en": {
+ "type": "string"
+ },
+ "text_es": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "free_check_url",
+ "order_url",
+ "text_en",
+ "text_es"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "data_limits",
+ "verify_on_air"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "show",
- "found",
- "candidates",
- "similar_shows",
- "basis",
- "leads"
-]New value: +[
+ "show",
+ "found",
+ "candidates",
+ "similar_shows",
+ "basis",
+ "leads",
+ "next_step"
+]get_brand_podcast_sponsorships2 fields changedOutput schema / properties / next_stepAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data_limits": {
+ "type": "string"
+ },
+ "verify_on_air": {
+ "additionalProperties": false,
+ "properties": {
+ "free_check_url": {
+ "type": "string"
+ },
+ "order_url": {
+ "type": "string"
+ },
+ "text_en": {
+ "type": "string"
+ },
+ "text_es": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "free_check_url",
+ "order_url",
+ "text_en",
+ "text_es"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "data_limits",
+ "verify_on_air"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "brand",
- "found",
- "candidates",
- "brand_page",
- "total_episodes",
- "shows"
-]New value: +[
+ "brand",
+ "found",
+ "candidates",
+ "brand_page",
+ "total_episodes",
+ "shows",
+ "next_step"
+]get_podcast_sponsors2 fields changedOutput schema / properties / next_stepAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data_limits": {
+ "type": "string"
+ },
+ "verify_on_air": {
+ "additionalProperties": false,
+ "properties": {
+ "free_check_url": {
+ "type": "string"
+ },
+ "order_url": {
+ "type": "string"
+ },
+ "text_en": {
+ "type": "string"
+ },
+ "text_es": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "free_check_url",
+ "order_url",
+ "text_en",
+ "text_es"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "data_limits",
+ "verify_on_air"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "show",
- "found",
- "candidates",
- "country",
- "show_page",
- "sponsors"
-]New value: +[
+ "show",
+ "found",
+ "candidates",
+ "country",
+ "show_page",
+ "sponsors",
+ "next_step"
+]list_sponsors_by_categorylist_top_podcast_sponsors3 fields changedInput schema / properties / country / descriptionPrevious value: -"Country of the show; accents optional"New value: +"Country of the show; accents optional / País del programa; tildes opcionales"Output schema / properties / next_stepAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data_limits": {
+ "type": "string"
+ },
+ "verify_on_air": {
+ "additionalProperties": false,
+ "properties": {
+ "free_check_url": {
+ "type": "string"
+ },
+ "order_url": {
+ "type": "string"
+ },
+ "text_en": {
+ "type": "string"
+ },
+ "text_es": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "free_check_url",
+ "order_url",
+ "text_en",
+ "text_es"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "data_limits",
+ "verify_on_air"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "country",
- "period_start",
- "period_end",
- "sponsors"
-]New value: +[
+ "country",
+ "period_start",
+ "period_end",
+ "sponsors",
+ "next_step"
+]search_podcast_sponsorships3 fields changedInput schema / properties / country / descriptionPrevious value: -"Country of the show; accents optional"New value: +"Country of the show; accents optional / País del programa; tildes opcionales"Output schema / properties / next_stepAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "data_limits": {
+ "type": "string"
+ },
+ "verify_on_air": {
+ "additionalProperties": false,
+ "properties": {
+ "free_check_url": {
+ "type": "string"
+ },
+ "order_url": {
+ "type": "string"
+ },
+ "text_en": {
+ "type": "string"
+ },
+ "text_es": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "free_check_url",
+ "order_url",
+ "text_en",
+ "text_es"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "data_limits",
+ "verify_on_air"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "period_start",
- "period_end",
- "total_matches",
- "results"
-]New value: +[
+ "period_start",
+ "period_end",
+ "total_matches",
+ "results",
+ "next_step"
+]find_sponsor_leads_for_podcastget_brand_podcast_sponsorshipsget_podcast_sponsorslist_top_podcast_sponsorssearch_podcast_sponsorshipsPublic index of YouTube sponsorships: which brands sponsor which creators, from sampled videos.
Podcast sponsorship data from transcribed audio: who sponsors which shows, brand ad history, trends.
Find brands that sponsor podcasts and newsletters like yours, with dated public ad reads.
Find brands that already sponsor podcasts like yours, then reveal the buyer to pitch.
Add one secure layer between your agents and this server.
