Marketingburos

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

With no annotations, the description carries the full burden and does most of it: it discloses the result cardinality (up to 10 candidates), the returned fields (name, legal_name, city, domain), and the exact error contract (isError with {error:'invalid_input'} when neither name nor domain is given). It omits any note on auth, rate limits, or fuzziness threshold, so it stops short of a 5.

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-loads the core action and examples, then layers the return shape, error case, and sibling routing in descending priority. Dense but every sentence carries distinct, actionable information with no 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?

No output schema exists, yet the description enumerates the returned fields and cardinality, and it documents the failure mode and the alternative tool. For a 4-parameter lookup with zero required params, nothing an agent needs to call 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, and the description adds real value beyond it: inline usage examples for name and domain and the at-least-one-of constraint that drives the error path. It never mentions city or limit semantics, which the schema handles, so it does not fully compensate but does exceed 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?

States a specific verb and resource ('Look up one specific agency') plus the exact identifiers accepted (trade name, statutory name, domain) and the concrete outcome (slug for get_agency_profile). It also explicitly separates itself from search_agencies, so an agent can pick correctly without opening schemas.

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 the positive condition (you have a name or domain and want the slug), the downstream tool to use it with (get_agency_profile), and the exclusion plus named alternative ('For ranked agency recommendations by criteria use search_agencies'). When-not guidance is explicit.

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

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

With no annotations, the description carries the burden and does well: it scopes the returned content (specialisms, cultural-fit axes, up to 3 cases), flags cultural-fit and cases as read-only canonical data, and documents the not_found error shape including the opt-out case. Auth requirements and rate limits are not covered, keeping it from a 5.

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 tight clauses: purpose, returned fields with read-only status, then error behavior. Everything is front-loaded and no sentence is 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 no output schema or annotations, the description still conveys the payload contents and the failure mode, which is what an agent needs to call and interpret this tool. It stops short of a full return-shape description, so not 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?

Schema coverage is 100% and the schema already documents slug as coming from search_agencies or find_agency. The description restates that origin and adds the 120-char constraint context only implicitly, so it adds little 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 and resource ('Fetch the full public profile of one marketing agency by slug') and makes clear it operates on a single agency identified by slug, which separates it from the list-oriented search_agencies and find_agency siblings.

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?

Points to search_agencies and find_agency as the source of the slug, which implies the correct call sequence. It does not explicitly say when to prefer this over those siblings, but the prerequisite chain is clear enough for an agent to act on.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full burden and does so well: it discloses the relaxation mechanism (relaxed: ['target_industry'], first strictMatched results are strict), that budget_band only excludes known conflicting rates, that unmatched specialisms produce 0 results with a hint, that ranking is never pay-to-rank, and that results cap at 20 with totalMatched before the limit. These are non-obvious behaviors an agent could not infer from the schema.

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 purpose before the filter mechanics, and almost every clause carries information (relaxation, ranking, result shape). It is dense and long for a tool description, with some parenthetical nesting that slows reading, but there is little filler to cut.

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 must describe returns — and it does: up to 20 ranked agencies with slug, trade name, optional legal_name, Dutch rationale, and totalMatched. Combined with the disclosed relaxation and fallback behaviors, an agent has everything needed to call this correctly and interpret the response.

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 the baseline is 3; the description goes beyond it by explaining the specialism interpretation pipeline (interpreted_as vs unmatched), that target_industry is the client vertical rather than the agency's own sector, and that radius inputs are only meaningful combined with within_km. These add real semantic value, though some points restate what the schema already says.

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?

Opens with a specific verb and resource ('Search Dutch marketing agencies') and enumerates the filter dimensions in the same sentence, so an agent immediately knows this is the multi-criteria discovery tool. It is clearly distinct from get_agency_profile (named as the follow-up consumer of `slug`) and from the other siblings, which are not search 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?

Establishes clear usage context: filtering by specialism/industry/city/B2B-B2C/size/budget/radius, with a pointer to categories://list for valid values and to get_agency_profile for per-agency detail. It never explicitly states when to prefer this over find_agency, so the routing to the closest sibling is left to inference.

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

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

With no annotations, the description carries the full burden and does so well: the key non-obvious trait is disclosed ('Nothing is sent to agencies automatically: the RFQ is queued and a human operator releases it'), along with skip-vs-error semantics and a named error taxonomy including IP/e-mail rate limits with resetAt. Remaining gaps are idempotency/duplicate-submission behavior and what happens to the buyer's contact data, which matter for a 17-param mutation.

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?

One dense paragraph, correctly front-loaded with purpose and the crucial 'not sent automatically' caveat before the return shape and error list. The trailing error-code enumeration is long and includes a slightly loose '...' in the profile listing, but each element conveys actionable information.

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 17-parameter mutation with no output schema and no annotations, the description supplies the missing pieces: the success payload shape ({rfqId, queuedAgencySlugs, notMatchableSlugs}), the partial-success rule, and enumerated failure modes. An agent can call it and interpret the result without further context.

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%, so the schema already documents all 17 parameters, establishing a baseline of 3. The description adds only the wizard-profile grouping and the source of selectedAgencySlugs, plus the cross-field rule that an out-of-pool slug is skipped rather than failing — useful but marginal on top of a fully documented 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 ('Submit a Request For Quote') plus the target (1-3 selected marketing agencies) and the channel (marketingburos.nl). It also implicitly distinguishes itself from the search siblings by naming search_agencies/find_agency as the source of the slugs, so an agent knows this is the terminal action in that workflow.

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?

Clear context: requires slugs produced by search_agencies or find_agency, 1-3 agencies, and it explains the not-matchable fallback ('unless none remain'). It does not, however, say when to prefer this over the sibling match_brief or what to do after success, so there is no explicit exclusion set.

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