MCP server that wraps Brave Search and augments each result with a transparent quality vector (tier, editorial standards, commercial intent, authoritative weight) for downstream agent reasoning
Single tool 'search_vectorized' has a comprehensive, well-structured description (1,200+ chars) that explains WHAT it does, WHEN to use it, and how to interpret outputs. Input schema is fully defined with proper JSON Schema types, enums, regex patterns, and descriptions for all 7 parameters. Output structure is documented in the description (tier, recommended_action, aggregate_vector, summary_hints, safety_flag). Tool naming is clear and verb-forward. However, output schema is NOT formally documented in the tool registration, only described in prose. Error handling guidance is absent from the tool definition. No tool annotations (readOnlyHint, etc.) present. The description is exceptionally detailed but could be more concise for LLM consumption (current ~1,200 chars vs. baseline 194 chars average).
Search the web using Brave Search and return an augmented SERP: each result is classified into a 9-tier quality vector (regulated_primary / peer_reviewed / independent_editorial / vendor_primary / vendor_content_marketing / affiliate / content_farm / ugc / unknown), plus a computed `recommended_action` (keep | tag | block). The aggregate vector summarizes the SERP landscape (tier distribution, vendor dominance ratio, diversity entropy). sift does NOT pre-filter results; blocking is a downstream interpretation. Agents should read `recommended_action` as guidance and `summary_hints` for meta-observations on the SERP's overall bias. `safety_flag` is a separate axis from quality — populated by Google Safe Browsing (phishing/malware/unwanted-software) and always forces recommended_action=block when set. `summary_hints` must be incorporated verbatim by the calling agent when summarizing — they flag vendor dominance, affiliate saturation, primary-source presence, source diversity, parasite SEO, and safety threats. Use `verbosity` to trade off detail vs token cost. Default `concise` (tier + action + reason + confidence per result + aggregate + hints; ~33% smaller payload) is the sweet spot for agent consumption. `full` returns every quality_vector dimension including self_promoting / third_party / commercial_intent / domain_content_mismatch / authoritative_weight / editorial_standards / signals[] — use for audit, debugging, or learning-loop material collection. `summary` returns aggregate_vector + summary_hints only (no per-result quality metadata) — use for SERP landscape dashboards.
Output schema not formally documented. Description explains output fields (tier, recommended_action, aggregate_vector, summary_hints, safety_flag, signals[]) but no JSON Schema outputSchema is registered in the tool definition. LLMs cannot reliably parse or chain outputs without formal schema.
No error handling guidance in tool definition. Tool description does not explain what errors can occur (e.g., invalid country code, Brave API failure, LLM judge timeout) or how the agent should recover. Agents will not know whether to retry, ask the user, or abandon the call.
Tool description is 1,200+ characters, 6x the baseline average (194 chars). While comprehensive, this wastes tokens and buries key details. Recommend splitting into a concise summary (50-100 chars) plus a detailed explanation in a separate 'extended_description' or documentation link.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
No tool annotations present. Tool should declare readOnlyHint=true (search is read-only, safe to retry) to help agents reason about idempotency and side effects.
Parameter 'profile' has enum values 'academic', 'dev', 'no_affiliate' marked as 'reserved for future Google wiring' but no clear guidance on current behavior. LLMs may assume these work now and be confused when they don't. Recommend clarifying: 'Currently only 'default' is functional; academic/dev/no_affiliate are reserved and will be ignored.'