Skip to main content
Glama
Sign In

Marketingburos

by nl.marketingburos
OverviewDiscussionsAdmin

match_brief

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).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "brief": "<brief>"
    },
    "name": "match_brief"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityNoExact office city of the agency. For 'near a city' use near_city + within_km instead.
briefYesThe buyer's own words (NL or EN, 20-2000 chars). Pass the question, not a summary.
limitNoMax results (1-20, default 10).
near_latNoCenter latitude of a radius search (alternative to near_city). Requires near_lon + within_km.
near_lonNoCenter longitude of a radius search (alternative to near_city). Requires near_lat + within_km.
near_cityNoCenter of a radius search: any Dutch city name. Requires within_km.
within_kmNoRadius in kilometres around near_city or near_lat/near_lon (max 250). Ignored without an origin; near_* is ignored without within_km.
budget_bandNoBuyer's budget in EUR. Only excludes agencies whose known rates conflict; most agencies have no known rate.
target_industryNoClient vertical the agency serves (e.g. the buyer's own industry). Not the agency's own sector.
company_size_bandNoSize of the buyer's company (employees); matches agencies that target that segment.
client_orientationNob2b or b2c focus of the agency.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  2. Added

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and delivers: brief is redacted for personal data before processing, never stored, latency of a few seconds, ranking is non-pay-to-rank. It also discloses the return shape and the `interpreted` field, exceeding typical disclosure for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: purpose first, then the routing rule, then input constraints, then behavior and return format. Slightly long, but nearly every clause adds actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description fully covers returns (up to 20 ranked agencies with slug, name, Dutch rationale, via) plus the important `interpreted` field and how to surface it to the buyer. Nothing material for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 and the schema already documents every parameter. The description adds framing (brief in buyer's words, NL/EN, 20-2000 chars; the optional hard filters as a group) but no syntax or semantics beyond what the schema states. It omits near_lat/near_lon and limit entirely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Match a buyer's own question to Dutch marketing agencies') with clear scope. It also explicitly differentiates from the sibling search_agencies, so an agent can tell them apart without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit rule: prefer search_agencies when specialisms are known, use match_brief when they must be inferred from the brief. It also gives a recovery path ('if it is wrong, call search_agencies with explicit specialisms'), covering when-to-use, when-not, and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Marketingburos toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources