Skip to main content
Glama
Sign In

editalmd

by com.editalmd
OverviewDiscussionsAdmin

Awarded prices

awarded_prices
Read-onlyIdempotent

The price that wins for a similar item, as a free summary: how many prices, the median and the range (p25/p75) of the same catalog product in the same unit, without the extremes; the volume bought; the price for your quantity; and the other groups that the search found (ask for the product and the unit of one of them to switch). It searches awarded results by item description: PNCP results and the items that Ceará cities report to TCE-CE (fonte on each item). It also accepts POST, PUT or PATCH with the same parameters in JSON or a form; query, termo, busca and search count as q, estado as uf, and limit as limite. Every 400 has exemplo and doc.

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": {
      "q": "<q>"
    },
    "name": "awarded_prices"
  }
}

Input Schema

NameRequiredDescriptionDefault
qYesItem description, at least 3 letters.
ufNoState (UF) of the agency (optional).
mesesNoAward window in months, 1 to 36 (default 12).
catmatNoItem code in the government catalog (optional).
limiteNo1 to 100 (default 50).
produtoNoCatalog product, as in `grupos` (optional).
unidadeNoUnit, as in `grupos`: 500 FL, 1 UN (optional).
quantidadeNoHow much you will sell: the value for the range of that quantity (optional).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent and non-destructive, so the description's job is to add what the annotations cannot: it discloses that the summary is free, excludes extremes, computes the value for the requested quantity, lists the alternative product/unit groups found, documents the accepted POST/PUT/PATCH aliases (query/termo/busca/search → q, estado → uf, limit → limite), and states that 400 responses include `exemplo` and `doc`. That is substantive behavioral context beyond the annotations.

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

Conciseness3/5

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

Every sentence carries information, but the whole thing is one undifferentiated run-on block that leads with return-value detail instead of the tool's purpose, and mixes output description, data sources, HTTP method aliases and error format without structure. Front-loading is weak.

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?

With no output schema and 8 parameters, the description does the heavy lifting by describing what comes back (count, median, p25/p75, volume, quantity-specific price, sibling groups) and the error shape. It is close to complete; only the absence of any guidance on result freshness/coverage limits for the two data sources leaves a small gap.

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 coverage is 100%, so baseline is 3, but the description adds real meaning: `produto` and `unidade` are explained as coming from the `grupos` in the response ('500 FL, 1 UN'), `quantidade` is tied to the returned quantity range, and the alias mapping clarifies how POST/GET parameter names correspond. It adds value rather than restating the schema.

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 names the resource precisely: awarded prices (PNCP results plus Ceará TCE-CE items) searched by item description, returned as median/p25/p75 statistics. It is a clear verb+resource statement, though the rambling opening sentence buries the 'what it does' behind a description of the output, and it never contrasts itself with siblings like search_tenders or open_tenders_in_field.

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 'price for your quantity' and the drill-down hint ('ask for the product and the unit of one of them to switch') tell an agent how to iterate, but there is no explicit when-to-use versus alternatives and no prerequisites or exclusions.

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

All editalmd 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