Skip to main content
Glama
Sign In

PensionHunter

by ai.pensionhunter
OverviewDiscussionsAdmin

GPFR: status, with a one-time code

gpfr_status

The status of a GPFR registration. Without a code it emails a one-time code to the registered address, with the code it returns one status word. At most 3 emails a day per address.

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": {
      "reference": "<reference>"
    },
    "name": "gpfr_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeNoOptional. The six-digit code from our email to the registered address.
languageNoOptional. Default en. GPFR is live in 24 languages: en, ar, da, de, es, fa, fr, hi, id, it, ja, ko, nb, nl, pl, pt, pt-BR, ro, ru, sv, th, tl, tr, zh. bg, uk, vi are answered in English.
referenceYesThe reference gpfr_register returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / language / description
      Previous value: -"Optional. ISO 639-1 code for our sentences and the consent text: en, ar, da, de, es, fa, fr, hi, id, it, ja, ko, nb, nl, pl, pt, pt-BR, ro, ru, sv, th, tl, tr, zh. Default en. Any other language is answered in English, with languageNote saying so."New value: +"Optional. Default en. GPFR is live in 24 languages: en, ar, da, de, es, fa, fr, hi, id, it, ja, ko, nb, nl, pl, pt, pt-BR, ro, ru, sv, th, tl, tr, zh. bg, uk, vi are answered in English."
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": false,
-  "properties": {
-    "codeSent": {
-      "type": "boolean"
-    },
-    "language": {
-      "type": "string"
-    },
-    "languageNote": {
-      "description": "Present only when the language asked for is not a GPFR language: why the answer and the consent text are in English.",
-      "type": "string"
-    },
-    "note": {
-      "type": "string"
-    },
-    "status": {
-      "enum": [
-        "pending_email_confirmation",
-        "registered",
-        "possible_match_awaiting_your_yes",
-        "confirmed_by_fund"
-      ],
-      "type": "string"
-    }
-  },
-  "required": [
-    "note"
-  ],
-  "type": "object"
-}New value: +null
  2. Added

TDQS

A3.9/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing a real side effect (an email containing a one-time code is sent) and a hard rate limit (at most 3 emails per day per address), plus the return shape ('one status word'). The readOnlyHint=false and idempotentHint=false annotations are consistent with a tool that sends mail and varies by code state; the rate limit in particular is context the agent cannot get from structured fields.

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 short sentences, zero filler, with the resource and the two operating modes front-loaded. Every clause carries information an agent needs before calling.

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?

No output schema exists, so the description compensates by stating the return is a single status word, and it covers the email side effect and rate limit. It omits error behavior (invalid or expired code, unknown reference) and what the status word values can be, which would matter for a tool returning an untyped single token.

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 the baseline is 3, but the description adds functional meaning the schema does not: the presence or absence of 'code' changes the tool's entire behavior from emailing a code to returning a status word. The reference and language parameters are left to their schema descriptions.

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 and resource ('The status of a GPFR registration') and splits the tool's two operating modes clearly. It is distinguishable from gpfr_register and gpfr_info by name, but the description never explicitly contrasts itself with those siblings, leaving differentiation to inference.

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?

The description implies the usage condition: call without a code to trigger the email, call with the code to get the status. That is useful implied guidance, but it never says when to prefer this over gpfr_info or what to do if the code has expired, so there are no explicit alternatives or exclusions.

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

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