Vind en vergelijk 2.000+ Nederlandse marketingbureaus op specialisme, stad en cases. Vier MCP-tools geven agents toegang tot profielen, zoekresultaten en de RFQ-flow.
Scored across 5 tools
find_agency (single lookup by name/domain), search_agencies (ranked search by explicit filters), and match_brief (infer specialisms from a free-text brief) all return agency lists, creating potential overlap. However, the descriptions explicitly state when to prefer each other (e.g. 'For ranked agency recommendations by criteria use search_agencies'), which effectively resolves the boundary. get_agency_profile and submit_rfq are clearly distinct.
Names mostly follow a verb_noun pattern (find_agency, search_agencies, match_brief, submit_rfq). get_agency_profile is verb_noun_noun, a minor deviation, but the convention is still predictable and readable across the set. No mixed casing or style chaos.
Five tools is well-scoped for a directory+matching+RFQ server: discovery (find, search, match), detail retrieval (get_agency_profile), and action (submit_rfq). Each tool earns its place with no redundancy or obvious filler.
Covers the full buyer journey: locate an agency, fetch its profile, search/match by criteria, and submit an RFQ. Minor gap: no tool to check RFQ status or retrieve submitted RFQs, and no agency-side operations, but core workflows are well covered. Reasonable for the stated purpose.
Look up one specific agency by trade name, statutory name or domain (e.g. name='Yourcrew' or domain='yourcrew.online') to get its slug for get_agency_profile. Returns up to 10 candidates with public trade name (name), legal_name when the statutory name differs, city and domain. Returns isError with {error:'invalid_input'} when neither name nor domain is given. For ranked agency recommendations by criteria use search_agencies.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city to narrow candidates. | |
| name | No | Trade or statutory name (fuzzy), e.g. 'Yourcrew'. Provide name and/or domain. | |
| limit | No | Max candidates (1-10, default 5). | |
| domain | No | Website domain, e.g. 'yourcrew.online'. Provide name and/or domain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden. It discloses the output shape (up to 10 candidates with name, legal_name, city, domain), the error response format, and the purpose of the return (slug consumption). It does not mention permissions, rate limits, or side effects, but this is a lookup tool and those details are not critical.
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 uses three sentences that all earn their place: purpose, output, error condition, sibling pointer. It is denser than necessary but not padded, and avoids repeating parameter descriptions already in 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?
No output schema exists, so the description must cover the return contract and it does. It covers error cases, candidate fields, the relationship to get_agency_profile, and reminds of the alternative. Missing bits are minor (e.g., default limit/value range is schema-covered, not description-critical).
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 description adds meaning beyond the schema: it clarifies the name/domain mutual requirement (neither given -> error), that 'name' accepts either trade or statutory name, and the domain format. Even with a baseline of 3, the additional context nudges it to 4.
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 (find/look up) and a specific resource (one agency) with concrete identifiers (trade name, statutory name, domain). It explicitly contrasts with search_agencies (ranked recommendations) and get_agency_profile (consumer of the slug), so an agent can instantly tell it apart.
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?
Directs when to use: when you need a specific agency's slug, and when not to (search_agencies for ranked recommendations). It also states the requirement that name or domain must be provided, and the condition that triggers an invalid_input error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full public profile of one marketing agency by slug (from search_agencies or find_agency). Includes specialisms, cultural-fit axes and up to 3 cases; cultural-fit and cases are read-only (Knowledge-OS canonical). Returns isError with {error:'not_found'} when the slug does not exist or the agency opted out of MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Agency slug as returned by search_agencies or find_agency. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the error case (returns isError with {error:'not_found'} when slug is invalid or agency opted out) and notes that cultural-fit and cases are read-only (Knowledge-OS canonical). This provides useful behavioral context beyond the simple 'fetch' action, though it stops short of describing success response structure in detail.
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?
Two sentences, front-loaded with the primary purpose and key source of input, followed by the error behavior and read-only note. No extraneous words; every sentence earns its place. This is a model of brevity.
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?
Given there is no output schema, the description sufficiently communicates the expected content (specialisms, cultural-fit axes, up to 3 cases) and error behavior. It does not explicitly state the shape of the success response (e.g., an object with those fields), but for a single-parameter read operation this is a reasonable level of completeness. Slightly more detail on the return structure would push it to a 5.
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?
The schema already describes the single parameter (slug) with its source and constraints (100% coverage). The description adds no novel information about the slug itself beyond repeating the source of the slug. Since the schema does the heavy lifting, a baseline score of 3 is appropriate; the description's mention of what the profile includes is relevant to output, not the parameter's meaning.
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 clearly states the action ('Fetch the full public profile') and the resource ('one marketing agency by slug'), and it distinguishes itself from siblings by specifying the source of the slug (from search_agencies or find_agency). This makes it unambiguous which tool to use when a slug is already known.
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 the appropriate usage: obtain a slug via search_agencies or find_agency, then call this tool to get the full profile. It does not explicitly state when not to use it or mention alternatives like submit_rfq, but the context is sufficient for an agent to understand the intended workflow. A clear 'use this after you have a slug' signal would be stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match a buyer's own question to Dutch marketing agencies. When the buyer already knows the required specialisms, prefer search_agencies with those specialisms; use match_brief when they need to be inferred from the brief. Pass the brief in the buyer's words (NL or EN, 20-2000 chars), optionally with the same hard filters as search_agencies (city, near_city + within_km, target_industry, client_orientation, company_size_band, budget_band). The brief is redacted for personal data first and never stored; a call takes a few seconds. Returns up to 20 ranked agencies (slug, name, 1-line Dutch rationale, via: specialism | brief | both) and interpreted: the specialisms and working style read from the brief, plus a follow-up question when the brief is unclear. Show interpreted to the buyer; if it is wrong, call search_agencies with explicit specialisms. Ranking ignores what an agency pays (never pay-to-rank).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Exact office city of the agency. For 'near a city' use near_city + within_km instead. | |
| brief | Yes | The buyer's own words (NL or EN, 20-2000 chars). Pass the question, not a summary. | |
| limit | No | Max results (1-20, default 10). | |
| near_lat | No | Center latitude of a radius search (alternative to near_city). Requires near_lon + within_km. | |
| near_lon | No | Center longitude of a radius search (alternative to near_city). Requires near_lat + within_km. | |
| near_city | No | Center of a radius search: any Dutch city name. Requires within_km. | |
| within_km | No | Radius in kilometres around near_city or near_lat/near_lon (max 250). Ignored without an origin; near_* is ignored without within_km. | |
| budget_band | No | Buyer's budget in EUR. Only excludes agencies whose known rates conflict; most agencies have no known rate. | |
| target_industry | No | Client vertical the agency serves (e.g. the buyer's own industry). Not the agency's own sector. | |
| company_size_band | No | Size of the buyer's company (employees); matches agencies that target that segment. | |
| client_orientation | No | b2b or b2c focus of the agency. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so: brief is redacted for personal data before use, never stored, a call takes a few seconds, and ranking is never pay-to-rank. It also discloses output shape (up to 20 ranked agencies with slug, name, Dutch rationale, via) and the `interpreted` field plus its follow-up question, which are non-obvious behaviors.
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 purpose and the sibling routing rule, then the parameter contract, then behavior and output. Five dense sentences with no filler or repetition; nothing could be dropped without losing an agent-relevant fact.
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 an 11-parameter, no-output-schema tool, the description still conveys return contents (ranked list, its fields, the `interpreted` object) and instructs the agent to surface `interpreted` to the buyer. All filters are enumerated and the required `brief` contract is clear, so an agent has everything needed to call it and act on the result.
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 100%, so per-parameter documentation is handled structurally; the description's added value is framing city/near_city+within_km/target_industry/client_orientation/company_size_band/budget_band as the same 'hard filters as search_agencies' and restating the brief's NL/EN 20-2000 char contract. That cross-tool equivalence is genuinely useful, though it adds little on the individual filter semantics.
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 — matching a buyer's own question to Dutch marketing agencies — and immediately positions itself against the sibling search_agencies ('prefer search_agencies ... use match_brief when they need to be inferred'). An agent can distinguish the two tools without opening either schema.
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 an explicit decision rule: use search_agencies when specialisms are known, match_brief when they must be inferred from the brief. It also covers the recovery path ('if it is wrong, call search_agencies with explicit specialisms'), so both directions of the choice are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Dutch marketing agencies by specialisms, target_industry (the client vertical the agency serves), city, B2B/B2C, company size, budget band and an optional radius (near_city = any Dutch city, or near_lat/near_lon, always combined with within_km in kilometres). specialisms filters against the taxonomy; a term outside it is mapped to the nearest specialism when the match is clear (shown in filters.specialisms.interpreted_as), otherwise echoed in filters.specialisms.unmatched (all unknown → 0 results + hint). budget_band only excludes agencies with a known conflicting rate (see filters.budget_band.note). target_industry matches the sectors an agency is known to serve; when fewer than 5 agencies match it, the list is filled with agencies that meet the other filters, the response says relaxed: ['target_industry'], and the first strictMatched results match every filter. Returns up to 20 ranked agencies with slug (use in get_agency_profile), public trade name (name, plus legal_name when the statutory name differs), a 1-line rationale in Dutch, and totalMatched (hits before the limit). Ranking ignores what an agency pays (never pay-to-rank). Read the categories://list resource for valid values.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Exact office city of the agency. For 'near a city' use near_city + within_km instead. | |
| limit | No | Max results (1-20, default 10). | |
| near_lat | No | Center latitude of a radius search (alternative to near_city). Requires near_lon + within_km. | |
| near_lon | No | Center longitude of a radius search (alternative to near_city). Requires near_lat + within_km. | |
| near_city | No | Center of a radius search: any Dutch city name. Requires within_km. | |
| within_km | No | Radius in kilometres around near_city or near_lat/near_lon (max 250). Ignored without an origin; near_* is ignored without within_km. | |
| budget_band | No | Buyer's budget in EUR. Only excludes agencies whose known rates conflict; most agencies have no known rate. | |
| specialisms | No | Up to 5 specialism slugs from categories://list (e.g. 'seo', 'branding'). A term outside the taxonomy is mapped to the nearest specialism when the match is clear (filters.specialisms.interpreted_as), otherwise echoed back in filters.specialisms.unmatched. | |
| target_industry | No | Client vertical the agency serves (e.g. the buyer's own industry). Not the agency's own sector. | |
| company_size_band | No | Size of the buyer's company (employees); matches agencies that target that segment. | |
| client_orientation | No | b2b or b2c focus of the agency. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses specialism taxonomy matching/interpretation/unmatched behavior, target_industry relaxation when fewer than 5 match, budget_band's non-exclusion semantics, the never-pay-to-rank ranking policy, and response fields including totalMatched.
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 long but front-loaded with the core purpose, then systematically covers edge cases and response guarantees. Every sentence contributes necessary semantic detail; there is no filler or repetition of obvious schema facts.
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?
There is no output schema, so the description wisely explains return contents: ranked agencies, slug, name, legal_name, rationale in Dutch, totalMatched, and filter-interpretation signals like interpreted_as, unmatched, note, and relaxed. Combined with 100% schema coverage and no required parameters, an agent has everything needed to call and interpret the tool.
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?
Although the schema already documents all parameters, the description adds significant behavioral meaning: budget_band only excludes agencies with known conflicting rates, near_* must be combined with within_km and is ignored otherwise, specialisms are taxonomy-mapped, and target_industry relaxes under low match counts. This goes well beyond the schema descriptions.
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 opens with a specific action and resource: 'Search Dutch marketing agencies', then enumerates the exact filter dimensions. It also differentiates itself from get_agency_profile by noting returned slugs are for use there, so an agent can distinguish this search tool from profile retrieval.
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 intended use is clear: search agencies by filters and get ranked results. It explicitly points to categories://list for valid values and to get_agency_profile as the follow-up step. It does not explicitly contrast with find_agency, but the search-vs-profile distinction and the filter-rich context leave little ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a Request For Quote (RFQ) on behalf of a buyer to 1-3 selected marketing agencies via marketingburos.nl. Input is the v1 wizard profile (specialisms, industry, company size, budget, timeline, ...) plus contact details and selectedAgencySlugs (slugs from search_agencies or find_agency). Nothing is sent to agencies automatically: the RFQ is queued and a human operator releases it. Success returns {rfqId, queuedAgencySlugs, notMatchableSlugs}: a selected agency that is not in the match pool for this buyer profile is skipped (listed in notMatchableSlugs), not an error, unless none remain. Failures return isError with one of: invalid_input (with issues[]), unknown_agency (with slugs[] that do not exist or cannot be contacted), rate_limit_ip / rate_limit_email (resetAt included when raised by this server), invalid / invalid_email / disposable_email (upstream validation), no_selection (no selected agency is in the match pool), upstream_failure.
| Name | Required | Description | Default |
|---|---|---|---|
| website | No | Leave empty. Anti-spam honeypot field. | |
| industry | Yes | Buyer's industry (a value from categories://list doelgroep_options, or 'Anders'). | |
| timeline | Yes | When the work should start. | |
| agencySize | Yes | Preferred agency size in employees. | |
| budgetBand | Yes | Buyer's budget in EUR. | |
| companySize | Yes | Buyer's company size in employees. | |
| contactName | Yes | Buyer's full name. | |
| culturalFit | Yes | Three 0-10 sliders: [data-driven, specialist, hands-on]. Use [5,5,5] when unknown. | |
| specialisms | Yes | 1-5 specialism slugs the buyer needs (see the categories://list resource). | |
| toelichting | No | Optional free-text brief for the agencies (Dutch or English). | |
| contactEmail | Yes | Buyer's business e-mail (no disposable domains). | |
| contactPhone | No | Optional phone number (digits, spaces, +, (), -). | |
| contactCompany | Yes | Buyer's company name. | |
| industryFreetext | No | Required only when industry is 'Anders': the buyer's industry in their own words. | |
| clientOrientation | No | Optional: does the buyer sell b2b, b2c or both. | |
| selectedAgencySlugs | Yes | 1-3 agency slugs (as returned by search_agencies or find_agency) the buyer wants to receive this RFQ. | |
| specialistFullServiceSlider | Yes | 0 = full-service agency, 10 = niche specialist. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It openly states that nothing is sent automatically and that the RFQ is queued for a human operator. It details the success return structure ({rfqId, queuedAgencySlugs, notMatchableSlugs}) and explains that not-matching agencies are skipped rather than causing errors, unless none remain. It enumerates all failure modes with specific payloads (issues[], slugs[], resetAt) and even clarifies the honeypot field via the schema (though not in description—but the behavior is fully covered). This is exceptionally transparent about side effects and error conditions.
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 a single dense paragraph but is exceptionally well-structured. It front-loads the core purpose, then explains queuing behavior, success returns, and failure modes in a logical order. Every sentence adds critical information — there is no fluff or repetition. The use of semicolons and lists keeps it readable despite its length.
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?
Given 17 parameters (12 required), no output schema, and no annotations, the description covers what an agent needs to know: the success return shape, the not-matchable behavior, and all error paths with their associated payloads. It also ties in the prerequisite of agency slugs from sibling tools. It does not duplicate schema details, and it explains the queued/human-release nature which is critical for expectation setting. Nothing essential is missing for correct invocation and interpretation of results.
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?
The schema has 100% description coverage, so the baseline is 3. The description adds a high-level grouping ('v1 wizard profile') and references that selectedAgencySlugs come from sibling tools, but it does not add new meaning beyond what each parameter's schema description already provides. It does not clarify any nuanced formats or interactions beyond the schema, so it stays at the baseline.
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 ('Submit a Request For Quote'), a clear resource (RFQ to 1-3 agencies via marketingburos.nl), and defines the scope (on behalf of a buyer). It also distinguishes from siblings by noting the input is the wizard profile plus slugs from search_agencies or find_agency, making clear this is the submission step, not discovery. The queuing behavior is also stated, which reinforces the purpose.
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?
It explains that input requires selectedAgencySlugs from search_agencies or find_agency, implicitly instructing the agent to use those tools first. It also states that nothing is sent automatically and a human operator releases it, giving context on when this is appropriate. However, it does not explicitly say 'use this only when...' or name alternative tools for other actions, so it falls short of explicit when-not guidance, but the indirect routing is clear.
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.
match_briefsearch_agencies1 field changedInput schema / properties / specialisms / descriptionPrevious value: -"Up to 5 specialism slugs from categories://list (e.g. 'seo', 'branding'). Unknown terms are echoed back in filters.specialisms.unmatched."New value: +"Up to 5 specialism slugs from categories://list (e.g. 'seo', 'branding'). A term outside the taxonomy is mapped to the nearest specialism when the match is clear (filters.specialisms.interpreted_as), otherwise echoed back in filters.specialisms.unmatched."find_agency5 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / city / descriptionAdded value: +"Optional city to narrow candidates."Input schema / properties / domain / descriptionAdded value: +"Website domain, e.g. 'yourcrew.online'. Provide name and/or domain."Input schema / properties / limit / descriptionAdded value: +"Max candidates (1-10, default 5)."Input schema / properties / name / descriptionAdded value: +"Trade or statutory name (fuzzy), e.g. 'Yourcrew'. Provide name and/or domain."get_agency_profile2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / slug / descriptionAdded value: +"Agency slug as returned by search_agencies or find_agency."search_agencies12 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / budget_band / descriptionAdded value: +"Buyer's budget in EUR. Only excludes agencies whose known rates conflict; most agencies have no known rate."Input schema / properties / city / descriptionAdded value: +"Exact office city of the agency. For 'near a city' use near_city + within_km instead."Input schema / properties / client_orientation / descriptionAdded value: +"b2b or b2c focus of the agency."Input schema / properties / company_size_band / descriptionAdded value: +"Size of the buyer's company (employees); matches agencies that target that segment."Input schema / properties / limit / descriptionAdded value: +"Max results (1-20, default 10)."Input schema / properties / near_city / descriptionAdded value: +"Center of a radius search: any Dutch city name. Requires within_km."Input schema / properties / near_lat / descriptionAdded value: +"Center latitude of a radius search (alternative to near_city). Requires near_lon + within_km."Input schema / properties / near_lon / descriptionAdded value: +"Center longitude of a radius search (alternative to near_city). Requires near_lat + within_km."Input schema / properties / specialisms / descriptionAdded value: +"Up to 5 specialism slugs from categories://list (e.g. 'seo', 'branding'). Unknown terms are echoed back in filters.specialisms.unmatched."Input schema / properties / target_industry / descriptionAdded value: +"Client vertical the agency serves (e.g. the buyer's own industry). Not the agency's own sector."Input schema / properties / within_km / descriptionAdded value: +"Radius in kilometres around near_city or near_lat/near_lon (max 250). Ignored without an origin; near_* is ignored without within_km."submit_rfq20 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / agencySize / descriptionAdded value: +"Preferred agency size in employees."Input schema / properties / budgetBand / descriptionAdded value: +"Buyer's budget in EUR."Input schema / properties / clientOrientation / descriptionAdded value: +"Optional: does the buyer sell b2b, b2c or both."Input schema / properties / companySize / descriptionAdded value: +"Buyer's company size in employees."Input schema / properties / contactCompany / descriptionAdded value: +"Buyer's company name."Input schema / properties / contactEmail / descriptionAdded value: +"Buyer's business e-mail (no disposable domains)."Input schema / properties / contactName / descriptionAdded value: +"Buyer's full name."Input schema / properties / contactPhone / descriptionAdded value: +"Optional phone number (digits, spaces, +, (), -)."Input schema / properties / culturalFit / descriptionAdded value: +"Three 0-10 sliders: [data-driven, specialist, hands-on]. Use [5,5,5] when unknown."Input schema / properties / industry / descriptionAdded value: +"Buyer's industry (a value from categories://list doelgroep_options, or 'Anders')."Input schema / properties / industryFreetext / descriptionAdded value: +"Required only when industry is 'Anders': the buyer's industry in their own words."Input schema / properties / selectedAgencyIdsRemoved value: -{
- "items": {
- "format": "uuid",
- "type": "string"
- },
- "maxItems": 3,
- "minItems": 1,
- "type": "array"
-}Input schema / properties / selectedAgencySlugsAdded value: +{
+ "description": "1-3 agency slugs (as returned by search_agencies or find_agency) the buyer wants to receive this RFQ.",
+ "items": {
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / specialisms / descriptionAdded value: +"1-5 specialism slugs the buyer needs (see the categories://list resource)."Input schema / properties / specialistFullServiceSlider / descriptionAdded value: +"0 = full-service agency, 10 = niche specialist."Input schema / properties / timeline / descriptionAdded value: +"When the work should start."Input schema / properties / toelichting / descriptionAdded value: +"Optional free-text brief for the agencies (Dutch or English)."Input schema / properties / website / descriptionAdded value: +"Leave empty. Anti-spam honeypot field."Input schema / requiredPrevious value: -[
- "specialisms",
- "industry",
- "companySize",
- "agencySize",
- "specialistFullServiceSlider",
- "culturalFit",
- "budgetBand",
- "timeline",
- "contactEmail",
- "contactName",
- "contactCompany",
- "selectedAgencyIds"
-]New value: +[
+ "specialisms",
+ "industry",
+ "companySize",
+ "agencySize",
+ "specialistFullServiceSlider",
+ "culturalFit",
+ "budgetBand",
+ "timeline",
+ "contactEmail",
+ "contactName",
+ "contactCompany",
+ "selectedAgencySlugs"
+]find_agencyget_agency_profilesearch_agenciessubmit_rfq
Add one secure layer between your agents and this server.