Skip to main content
Glama
romantcig

Brave Jev MCP

by romantcig
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

brave_llm_context

brave_llm_context

Search the web and return relevance-ranked content chunks for direct answers, with source links for citation; fetch full pages only when context or verification is needed.

Instructions

Search the web with Brave and return pre-extracted, relevance-ranked content chunks (prose, tables, code blocks, structured data). Use the returned content directly when it answers the question; fetch the page only when you need the full context or must verify.

For routine calls, omit the four search budget parameters; the server applies the defaults
shown in their descriptions. Increase a budget only when previous results show that more
source coverage or passage detail is needed. `query` supports site:.

Search rules:
    - Unfamiliar subject: first search the subject name plus the core question for an overview,
      then verify details as needed; do not search for a given detail directly — check whether
      it surfaces naturally in the sources.
    - Keep only keywords directly relevant to the current question in `query`; do not pack
      context and qualifiers into one query.
    - Set `freshness` (pd / pw / pm / py) when recency matters; never hardcode a year in `query`.
    - Two consecutive searches with heavily overlapping results mean the direction is exhausted:
      change the keyword strategy.
    - Search serially; go parallel only when confident of each query.

When relaying results, cite the URL returned with each content item.
Source age, when available, is included with that item; it is not a verified publication date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoCandidate search results to consider. Omit to use the default of 10.
queryYesSearch keywords; supports site:. At most 400 characters and 50 words.
countryNoTwo-letter result region code, e.g. "US"; usually omitted.
gogglesNoRe-ranking rules: a Goggle URL, rule text, or an array of them.
freshnessNoRecency filter: pd = 1 day, pw = 7 days, pm = 31 days, py = 365 days, or YYYY-MM-DDtoYYYY-MM-DD.
search_langNoResult language code, e.g. "en" or "zh-hans"; usually omitted.
maximum_number_of_urlsNoReturned source budget. Omit to use the default of 5.
maximum_number_of_tokensNoApproximate total token budget for returned content. Omit to use the default of 4000.
maximum_number_of_tokens_per_urlNoToken budget per source. Omit to use the default of 800.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.6/5.0
Behavior5/5

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

The annotations only declare openWorldHint=true, so the description carries most behavioral disclosure. It explains the return shape (prose, tables, code blocks, structured data), the budget controls, source-age caveats, and that citations should use returned URLs. This is rich context beyond the annotation.

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?

The description is front-loaded with purpose and output characteristics, then moves to usage guidance and search rules. It is longer than average, but the length is largely justified by the tool's complexity and the absence of an output schema. Formatting is a bit dense, but sentences generally earn their place.

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?

For a complex search tool with nine parameters, no output schema, and only an openWorldHint annotation, the description is complete enough. It explains what is returned, how to use the results, how budgets behave, and cites URL/source-age caveats. An agent has the context needed to call and interpret this tool correctly.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful semantics by telling the agent to omit the four budget parameters for routine calls, that defaults are applied server-side, and to increase budgets only when more coverage or detail is needed. It also notes that query supports site:, though it does not add meaning for every parameter beyond the schema.

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?

The description states a specific verb and resource: searches the web with Brave and returns pre-extracted, relevance-ranked content chunks. It also distinguishes the output from a normal web result set by naming the content types and explaining when to fetch the full page instead. This lets an agent differentiate it from sibling search tools without opening the schema.

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

Usage Guidelines4/5

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

It gives strong when-to-use guidance: use returned chunks directly when sufficient, fetch the page only for full context or verification, omit budget parameters for routine calls, and increase budgets only when more coverage is needed. It also provides detailed search strategy rules. However, it does not explicitly name or compare against sibling alternatives such as brave_web_search or brave_news_search, so it falls short of full alternative routing.

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

Deploy Server

Other Tools