Price creator brand deals, look up a brand's public creator program, read niche rate benchmarks.
Scored across 3 tools
The three tools have mostly distinct purposes: one looks up a brand program, one prices a specific deal, and one returns niche rate benchmarks. The main overlap is between price_deal and rate_benchmarks, since both surface pricing figures, but the descriptions distinguish deal-specific calculation from a general published rate table. An agent can likely select correctly with careful reading, though the boundary is not completely sharp.
All names use snake_case and mostly follow a verb_noun structure: lookup_brand_program, price_deal, rate_benchmarks. The only minor deviation is rate_benchmarks, which reads more like a noun phrase than an action, but the set remains predictable and readable.
Three tools is a reasonable, tightly scoped set for a pricing and brand-program lookup server. It is on the thin side but each tool has a clear role, and there is no obvious tool bloat.
The surface covers brand program lookup, deal pricing, and niche rate benchmarks, but it lacks discovery-oriented operations such as listing or searching brands, categories, or programs. Agents can only use the tools if they already know a brand name, slug, or niche key, which creates a notable dead end. Coverage of the pricing lifecycle is decent but not full.
Look up one brand's public creator program: how creators apply or pitch, the program summary, what the brand sells, and the link to its BravoDM program page. Covers only the brands with public program pages at bravodm.com/brands, from the same catalog records those pages render. Pass a brand name or its BravoDM slug.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand name (for example Caraway) or slug (caraway). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful context beyond that: data comes from the same catalog records the BravoDM pages render, and coverage is restricted to brands with public program pages. It could go further on failure behavior (e.g., what happens for an unlisted brand), but the read-only, public-data nature is clear.
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?
Three sentences, front-loaded with the purpose, then scope, then input instruction. Every clause contributes something specific; no filler or repetition of the title.
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 one-parameter read-only lookup with no output schema, the description supplies what the schema and annotations cannot: the returned fields, the source catalog, and the coverage limitation. An agent has everything needed to decide to call it and what to expect back.
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 100% and the single parameter already documents 'Brand name (for example Caraway) or slug (caraway).' The description's 'Pass a brand name or its BravoDM slug' merely restates that, adding no format or normalization guidance beyond the schema. Baseline 3 is appropriate.
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 ('look up') and resource ('one brand's public creator program'), then enumerates the exact content returned: application/pitch process, summary, product category, and program page link. The scope is narrow and unmistakable, and nothing overlaps with the sibling tools price_deal or rate_benchmarks.
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?
Explicitly states the valid population ('only the brands with public program pages at bravodm.com/brands'), which tells the agent when this tool will and will not return data, and instructs what input to pass. It doesn't name a fallback for brands outside that set, but no sibling offers an alternative lookup, so the gap is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price a creator brand deal with BravoDM's published pricing model, the same model the free calculator at bravodm.com/tools/pricing-calculator runs. Two deal kinds: a posted deal (the creator posts on their own account; pass the follower band, niche, deliverable quantities, and the usage and exclusivity terms), and a content-only UGC deal (pass mode "ugc" and a ugc_tier; the creator films and the brand posts, so the price follows the creator's experience tier and never a follower count, and only the ugcVideo quantity prices). Returns the line-by-line price and the three numbers BravoDM publishes for a package: the floor, your number, and the strong ask, in USD.
| Name | Required | Description | Default |
|---|---|---|---|
| live | No | Quantity of live deliverables. | |
| mode | No | Deal kind. "posted" (the default) prices a deal the creator posts, off the follower band. "ugc" prices a content-only deal the brand posts, off the ugc_tier experience tier. Passing ugc_tier without a mode also selects the UGC path. | |
| niche | Yes | Pricing model niche key: beauty (Beauty and skincare), fashion (Fashion), fitness (Health and fitness), food (Food and drink), travel (Travel), parenting (Parenting and family), finance (Finance and business), tech (Tech and software), lifestyle (Lifestyle), entertainment (Comedy and entertainment), gaming (Gaming), other (Other). | |
| usage | No | Usage rights term key: none (No usage rights), 30d (30 days), 90d (90 days), 180d (180 days), 12mo (12 months), forever (Forever). Defaults to none. | |
| carousel | No | Quantity of carousel deliverables. | |
| feedPost | No | Quantity of feedPost deliverables. | |
| platform | Yes | Platform the deal runs on: instagram, tiktok, or youtube. | |
| storySet | No | Quantity of storySet deliverables. | |
| ugcVideo | No | Quantity of ugcVideo deliverables. | |
| ugc_tier | No | UGC experience tier key (pricing model v1.1): first-deals (First deals: New to paid UGC work, building a portfolio), steady (Steady brand work: Regular paid UGC work for brands), proven (Proven performer: A track record brands ask for by name). Only read for a content-only UGC deal (mode "ugc"); defaults to first-deals, the calculator's own default. | |
| engagement | No | Engagement level key: lower (Lower than most), average (About average), above (Above average), way-above (Way above average). Defaults to average. | |
| shortVideo | No | Quantity of shortVideo deliverables. | |
| storyFrame | No | Quantity of storyFrame deliverables. | |
| exclusivity | No | Exclusivity term key: none (No exclusivity), 30d (30 days), 90d (90 days). Defaults to none. | |
| ytDedicated | No | Quantity of ytDedicated deliverables. | |
| whitelisting | No | True when the brand may run the content from its own handle (whitelisting, also called Spark or partnership ads). Raises the usage line. | |
| follower_band | No | Follower band key from the pricing model: under-5k (Under 5k), 5k-10k (5k to 10k), 10k-25k (10k to 25k), 25k-50k (25k to 50k), 50k-100k (50k to 100k), 100k-250k (100k to 250k), 250k-500k (250k to 500k), 500k-1m (500k to 1M), 1m-plus (1M+). Required for a posted deal. A content-only UGC deal (mode "ugc") prices on ugc_tier instead and ignores it. | |
| typical_views | No | Typical views per video. Only used for YouTube pricing, where it can raise the dedicated video rate above the band base. | |
| ytIntegration | No | Quantity of ytIntegration deliverables. | |
| package_discount | No | True to apply the model's 10 percent package discount on the content subtotal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true is consistent with a pure calculation tool, so no contradiction. The description adds genuine value beyond the annotation by disclosing the return shape: line-by-line price plus the three published numbers (floor, your number, strong ask) in USD, and by noting that UGC pricing never uses follower count.
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?
Purpose and the two-mode split are front-loaded, and every clause carries information. The middle sentence is dense and run-on, which makes it slightly harder to scan than an ideally structured description.
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 20-parameter pricing tool with no output schema, the description covers what it computes, how the two modes differ, which inputs matter per mode, and what the response contains including currency. Nothing an agent needs to invoke it 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%, so baseline is 3, but the description adds cross-parameter meaning the schema only repeats per-field: which parameters are read in each mode (follower_band ignored for UGC, only ugcVideo priced for content-only deals) and the mode-selection interaction with ugc_tier.
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 ("price a creator brand deal") plus the exact model it runs and the two deal kinds it supports, so the operation is unambiguous. It does not explicitly differentiate from the siblings rate_benchmarks or lookup_brand_program, which an agent could plausibly confuse with pricing, keeping it below a 5.
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?
Explains the two modes and what to pass for each: posted deals take follower band, niche, deliverable quantities, usage and exclusivity, while UGC deals take mode "ugc" plus ugc_tier. That is clear routing between the tool's two paths, but there is no guidance on when to choose this over the sibling benchmark or brand-program tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the published rate table for one niche: for a creator at 25,000 followers, the floor, your number, and strong ask for one Reel, one feed post, and one Story set, plus what 90 days of usage adds on one Reel. The UGC video is priced differently: the brand posts it, so its rate follows the creator's experience tier, not followers. Its row carries the steady brand work tier and the response includes all three tiers, the figures the UGC rates guide leads with. Figures come from the same tables published at bravodm.com/rates. Pass a niche or category key such as beauty, kitchen, fitness, or tech_gadgets.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | Niche or category key: a published table key (fashion, food, kitchen, cleaning, home, diy, tech_gadgets, apps_software, beauty, fitness, pets, family, wellness, travel, general_products) or a pricing model niche key (finance, tech, parenting, entertainment, gaming, lifestyle, other). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint already establishes this as a safe read operation, and the description adds useful behavioral context about returned benchmark content, including floor/number/strong ask figures and usage tiers. It also discloses that UGC pricing uses experience tier rather than followers, which is important non-obvious 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 main action is front-loaded, but the description is verbose for a one-parameter read tool. Sentences about UGC tiers and source tables contain useful nuance, yet some phrasing is convoluted and the final invocation note largely repeats the schema.
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 no output schema, the description does a solid job explaining what the response will contain and the special UGC-tier nuance. It remains slightly incomplete on exact response field structure and invalid-niche behavior, but it is sufficient for an agent to call the tool 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% and the single niche parameter is fully described in the schema, including valid category keys. The description repeats a few examples and says to pass a niche key, but adds no parameter semantics beyond what the schema already provides.
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 read operation: retrieving the published rate table for one niche. It clearly describes what benchmarks are returned, but it does not explicitly distinguish this purpose from siblings like lookup_brand_program or price_deal.
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 description implies this is for reference rate benchmarks and gives an example niche key, but it does not explicitly say when to use this tool versus price_deal or lookup_brand_program. There are no exclusions or alternative-routing instructions.
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.
lookup_brand_programprice_dealrate_benchmarksFree creator rate benchmarks and brand-offer checks, with sources. No login, no API key.
Creator discovery & analytics across YouTube, Instagram, TikTok (30M+) + brand/sponsor intel.
YouTube sponsorship data: which brands sponsor which creators, and who to contact. Read only.
Instagram analytics, media kits, bio link and brand deals for creators, from your AI assistant.
Add one secure layer between your agents and this server.
