Skip to main content
Glama

Optional: Valio Aimo's suggestions (sponsored)

get_suggestions
Read-only

Fetch Valio Aimo's commercial product suggestions—better-value alternatives, seasonal items, and new listings—for a buyer's mandate, each pre-checked with a live offer and mandate tier. Nothing is ordered.

Instructions

Valio Aimo's own COMMERCIAL suggestions for your buyer: the seller promoting products, not neutral advice.

Better-value alternatives to what the buyer usually orders (cheaper per L/KG, a certification label, more reliable delivery or a lower CO2 estimate), seasonal products for delivery_date, and recently listed ones. basis: optional product ids (e.g. the current cart) to find alternatives for, besides order history. Everything was pre-checked against the mandate (nothing it would block is shown) and has a live offer and mandate_check (the tier it would get at the usual quantity). Nothing is ordered. Present each one to the buyer as "Valio Aimo suggests...", with its reason and disclosure; never as your own recommendation, and never order one unless the buyer asks: then request_quote as how_to_accept says. Read-scoped like get_mandate: send your Authorization: Bearer header (or agent_token) unless the mandate is a public demo; without one the error is agent_auth_required.

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": {
      "mandate_id": "<mandate_id>",
      "agent_id": "<agent_id>",
      "delivery_date": "<delivery_date>"
    },
    "name": "get_suggestions"
  }
}

Input Schema

NameRequiredDescriptionDefault
basisNo
limitNo
agent_idYes
mandate_idYes
agent_tokenNo
delivery_dateYes

Output Schema

NameRequiredDescriptionDefault
noteNo
buyerYes
agent_idYes
disclosureYes
mandate_idYes
suggestionsYes
sponsored_byYes
delivery_dateYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the readOnly/idempotent annotations, it discloses that results are pre-checked against the mandate (nothing blocked is shown), each has a live offer and a mandate_check tier at the usual quantity, and that nothing is ordered. It also covers auth: Bearer/agent_token required except public demos, with error agent_auth_required. The only gap is that pagination/limit behavior and result ordering are not described.

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 key framing — commercial/sponsored, not neutral — is front-loaded in the first sentence, and mandatory presentation rules ('Valio Aimo suggests...' with reason and disclosure, never your own recommendation) are stated compactly. It is dense and slightly repetitive: the 'not neutral advice' point is restated as 'never as your own recommendation', and the closing auth sentence could be trimmed.

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 tool with an output schema, this covers the remaining agent-critical ground: mandate safety pre-filtering, the offer/mandate_check fields returned, that no order is placed, auth requirements and the specific auth error, and the required buyer-facing framing. Little an agent needs in order to call and present results is missing.

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 0%, so the description must carry the load: it explains basis (optional product ids such as the current cart, used alongside order history), delivery_date (seasonal filtering), and agent_token (Authorization: Bearer unless public demo). It leaves limit and agent_id unexplained, which keeps it short of full compensation for six undocumented parameters.

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 opens with a specific verb-and-resource framing — 'Valio Aimo's own COMMERCIAL suggestions for your buyer: the seller promoting products, not neutral advice' — and then enumerates what kind of items come back (cheaper per L/KG, certification label, better delivery or CO2, seasonal for delivery_date, recently listed). The 'not neutral advice / sponsored' framing is exactly what separates it from a neutral substitute-finder sibling, so an agent can pick correctly without reading 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 Guidelines5/5

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

It states when to call (find better-value alternatives to usual orders, seasonal picks for a delivery date, new listings) and how to drive it via 'basis: optional product ids (e.g. the current cart) to find alternatives for, besides order history'. It also names the required follow-up path explicitly: never order unless the buyer asks, then use request_quote as how_to_accept says — a clear alternative-tool handoff.

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