Skip to main content
Glama

get_latest_value

Retrieve the current retained official processing-time record for a government service, optionally filtered by applicant country; check source status before relying on it.

Instructions

Get the latest retained official processing-time record for a service, optionally for a specific applicant country. Check source_collection_status before treating it as current. New Zealand services return both 50% and 80% records.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
service_keyYese.g. ca-visitor-visa, nz-visitor-visa, or any key from search results
applicant_countryNoISO 3166-1 alpha-2 of the applicant's country (omit for global service metrics)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose non-obvious traits: 'latest retained' implies data may be stale, the source_collection_status precondition warns the value may not be current, and the NZ note pre-empts a surprising dual-record return. It omits auth/permission needs and error or empty-result behavior, so not a 5.

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

Conciseness5/5

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

Three tight sentences with zero padding: the core purpose first, then the freshness caveat, then the NZ return-shape exception. Every sentence carries distinct, actionable information.

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?

For a 2-parameter getter with no output schema and no annotations, the description supplies the freshness caveat and a return-shape quirk, which are the two things an agent most needs. It does not describe the general shape of the returned record or what happens when no record exists, leaving a small gap.

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 coverage is 100% and both parameters carry their own descriptions (including examples for service_key and ISO format for applicant_country), so the schema does the heavy lifting. The description only restates that applicant_country is optional; it adds no syntax or format detail beyond the schema. Baseline 3 applies.

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?

States a specific verb+resource: 'Get the latest retained official processing-time record for a service', with scope narrowed by the optional applicant country. It is clearly a single-record getter, which implicitly separates it from compare_values, but it never names or contrasts a sibling tool.

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?

Provides a concrete precondition ('Check source_collection_status before treating it as current') and explains that applicant_country is optional and what omitting it means (global metrics). It stops short of explicit when-to-use-vs-alternative routing against compare_values or search_entities.

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