Skip to main content
Glama
Sign In

Primavera

by com.primaverapp
OverviewDiscussionsAdmin

Estimate a job

estimate_list_job
Read-onlyIdempotent

Estimate a job on a list before starting it: places eligible and the most credits it can spend. Jobs: executives (company executives, France and the United States only), summary (a 3-sentence summary of each website), question (a yes/no question asked to each website), filter (a criterion judged on the data we hold, no website read).

Free.

Same call as POST /api/v1/lists/{id}/jobs/estimate of the REST API.

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": {
      "listId": "<listId>",
      "tool": "<tool>"
    },
    "name": "estimate_list_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
toolYesexecutives: company executives (France and the United States only); summary: 3-sentence summary of the website; question: a yes/no question asked to the website; filter: a criterion judged on the data we hold (no website read).
scopeNoPlaces the job runs on: the whole list (default), the places a finished qualification judged conforming, or those it could not decide.
listIdYesId of a list of the account (from create_list or list_lists).
questionNotool "question" only.
criterionNotool "filter" only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, closed-world, non-destructive. The description adds value beyond them by disclosing cost behavior ('Free') and the nature of the result (eligibility plus a credit ceiling), and by clarifying that 'filter' reads no website while the others do.

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?

Front-loaded with the core action and outcome, followed by compact job-type glosses and a one-word cost note. The REST endpoint mapping is filler for an agent but is a single short line, so waste is minimal.

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?

There is no output schema, and the description compensates by saying what the estimate returns (eligible places, credit ceiling). Combined with a fully documented input schema, an agent has enough to invoke it correctly; only the exact response shape and cost semantics of the credit figure remain unstated.

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 the job-type semantics are already spelled out in the enum descriptions, so the description largely restates them. It adds no meaning for listId, scope, question, or criterion, leaving scope's conforming/undetermined behavior entirely to the schema. Baseline 3 is appropriate.

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 ('Estimate a job on a list') and immediately names the two outputs: places eligible and the maximum credits it can spend. The phrase 'before starting it' positions it against the start_list_job sibling, so an agent can pick it 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?

Usage context is clear and explicit: call this before starting a job, and 'Free' tells the agent it is a safe pre-flight check. It also enumerates the four job types, which is the main decision an agent faces; it does not however state exclusions or name an alternative estimator such as estimate_list.

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

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