Skip to main content
Glama

Alert preview

preview_alert

A free sample of procurements by terms and filters, or editable suggestions by CNPJ. It does not create alerts.

Input Schema

NameRequiredDescriptionDefault
ufNoState (UF) abbreviation; empty means all.
cnpjNoCNPJ to suggest up to 8 families of terms, without turning them on.
termosNoObject terms; a space requires all words, | accepts alternatives.
filtrosNoExtra filter: modalities, municipalities, exclusions, values, open proposals and CNAEs. PATCH replaces the whole filter; {} clears it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedInput schema / properties / filtros / properties / abertas / description
      Added value: +"Require the proposal deadline to be open at collection time."
    • addedInput schema / properties / filtros / properties / cnaes / description
      Added value: +"Up to 8 CNAE subclasses, such as 4644301 or 4644-3/01. Matches one of the purchase's three most likely CNAEs."
    • addedInput schema / properties / filtros / properties / disputa / description
      Added value: +"Only purchases with competitive bidding. Excludes PNCP's not-applicable bidding mode."
    • addedInput schema / properties / filtros / properties / esferas / description
      Added value: +"Government spheres: F federal, E state, D district and M municipal. Records without a sphere are excluded."
    • addedInput schema / properties / filtros / properties / excluir / description
      Added value: +"Up to 10 literal phrases, each 3–80 characters, to exclude from the purchase subject."
    • addedInput schema / properties / filtros / properties / modalidades / description
      Added value: +"Up to 10 PNCP procedure codes, from 1 to 19."
    • addedInput schema / properties / filtros / properties / municipios / description
      Added value: +"Up to 10 exact municipality names or IBGE codes. Use UF to distinguish names."
    • addedInput schema / properties / filtros / properties / srp / description
      Added value: +"Only purchases marked as price registration (srp) by PNCP."
    • addedInput schema / properties / filtros / properties / valor_max / description
      Added value: +"Maximum estimated value in Brazilian reais."
    • addedInput schema / properties / filtros / properties / valor_min / description
      Added value: +"Minimum estimated value in Brazilian reais."
  2. Changed3 schema fields changed
    • addedInput schema / properties / filtros / properties / disputa
      Added value: +{
      +  "type": "boolean"
      +}
    • addedInput schema / properties / filtros / properties / esferas
      Added value: +{
      +  "items": {
      +    "enum": [
      +      "F",
      +      "E",
      +      "D",
      +      "M"
      +    ],
      +    "type": "string"
      +  },
      +  "maxItems": 10,
      +  "type": "array"
      +}
    • addedInput schema / properties / filtros / properties / srp
      Added value: +{
      +  "type": "boolean"
      +}
  3. Added

TDQS

A3.5/5.0
Behavior3/5

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

The description adds genuine context beyond the annotations: the call is free (no credit consumption) and is non-persistent ('does not create alerts', suggestions are returned 'without turning them on'). It does not disclose how many sample procurements come back, whether the call is rate-limited, or whether preview state is cached, which matters for a tool annotated readOnlyHint=false.

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?

Two short sentences, front-loaded with the primary behavior and closed with the key exclusion. No filler, though the phrasing 'A free sample of procurements by terms and filters' is slightly compressed at the cost of readability.

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

Completeness4/5

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

A two-mode preview tool with a deeply nested filter object and no output schema needs the description to at least flag both modes and the non-persistence guarantee, which it does. What is missing is any indication of result shape or sample size, which an agent would need to decide whether to call it before create_alert.

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 description coverage is 100% and every nested filter field is documented in the schema itself, so the baseline is 3. The description only alludes to 'terms and filters' and the CNPJ mode without adding syntax or precedence rules (e.g., how cnpj interacts with termos/filtros) beyond what the schema states.

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

Purpose4/5

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

The description states a specific verb+resource ('a free sample of procurements by terms and filters') and names a second mode ('editable suggestions by CNPJ'). It also explicitly distinguishes itself from the alert-creating siblings with 'It does not create alerts', though the phrase 'editable suggestions' is vague about what exactly is returned.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the 'does not create alerts' clause hints that create_alert or create_alerts_by_cnpj is the tool for actual alert creation, and 'free sample' implies a trial-before-commit flow. But no sibling is named and there is no explicit 'use this when X, use create_alert when Y' routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.