APIVerve

Nobel Prizes

NobelPrizes

Read-only

Nobel Prizes: Nobel Prizes searches laureate records by first name, last name, and award category. Each result includes the winner's full name, award year, and category, while paid plans add year filtering, motivations, and biographical details. (Cost: 2 credits)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "NobelPrizes"
  }
}

Input Schema

Name	Required	Description
`year`	No	The year of the Nobel Prize to get information about
`category`	No	The category of the Nobel Prize to get information about
`lastname`	No	The last name of the Nobel Prize winner to get information about
`firstname`	No	The first name of the Nobel Prize winner to get information about

Output Schema

Name	Required	Description
`data`	No
`error`	No	Error message, null on success
`status`	No	"ok" on success

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, and the description goes beyond them by disclosing a 2-credit cost and that year filtering, motivations and biographical details are gated behind paid plans — a constraint an agent must know before relying on the year parameter. It stops short of describing result limits or pagination behavior.

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?

Two compact sentences plus a cost tag; the key capability and the paywall caveat are front-loaded. The opening 'Nobel Prizes: Nobel Prizes searches...' partially restates the tool name, which is minor redundancy rather than bloat.

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?

An output schema exists, so return-value explanation is not strictly required, and the description still sketches the result shape and the commercial constraint. What is missing is how free-tier results differ in volume and what happens when year is supplied on a free plan — a real ambiguity given the schema exposes year unconditionally.

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%, so every parameter is already documented with type and example, giving a baseline of 3. The description reinforces which fields are searched and flags that year filtering is plan-dependent, but adds no syntax, matching rules, or partial-name behavior beyond the schema.

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?

The description states a specific verb and resource ('searches laureate records') and names the filterable fields (first name, last name, category), so the tool's function is unambiguous. It does not differentiate against any named sibling, but no close sibling exists in the list, so the practical risk of mis-selection is low.

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?

Usage context is implied rather than stated: the reader infers this is a lookup tool for Nobel laureate/award queries. The paid-plan note hints at capability boundaries, but there is no explicit when-to-use/when-not-to-use guidance or comparison to alternatives such as HistoricalEvents.

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

All APIVerve tools Inspect

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.