Skip to main content
Glama
TruckerFetch MCP

TruckerFetch MCP

Official
by truckerfetch

search_renewals

Read-only

Find approved policy evidence for upcoming insurance renewals using a selected date basis and 30-, 45-, or 60-day window; filter results by carrier, fleet, cargo, or state.

Instructions

Search approved policy evidence by the requested date basis.

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": {
      "date_basis": "<date_basis>",
      "window_days": "<window_days>"
    },
    "name": "search_renewals"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
cursorNo
filtersNo
date_basisYes
window_daysYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.1/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the description's only job is added context, and it supplies almost none. It says nothing about pagination, result ordering, what 'approved' means as a state filter, or that the seemingly flexible window_days is actually restricted to three values.

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?

It is a single front-loaded sentence with no filler, which is structurally clean. But brevity here is under-specification rather than economy, given the tool's nested filter surface and required parameters.

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

Completeness1/5

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

This is a high-complexity search tool with a nested filters object, an enum date basis, a constrained window, and no output schema to explain returns. Against that complexity the one-sentence description is wholly inadequate; an agent cannot tell what gets returned or how to construct a meaningful filter.

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

Parameters1/5

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

Schema description coverage is 0% across five top-level parameters and a nested filters object with more than a dozen undocumented fields. The description mentions only the date-basis concept and never explains the enum values (e.g. filing_anniversary vs verified_expiration), the 30/45/60 constraint on the required window_days, or what limit, cursor, and each filter key do.

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

Purpose3/5

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

The verb 'search' is specific and 'approved policy evidence' names a resource, but the phrase is opaque and the modifier 'by the requested date basis' is circular rather than clarifying. The description never mentions renewals despite the tool name search_renewals, and gives no way to distinguish it from sibling search tools like search_carriers or search_edition.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool, when to prefer a sibling search, or what preconditions apply. The reference to 'the requested date basis' hints that a date-basis choice drives the query, but the agent is left to infer that from the schema's required parameter rather than being told.

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