An Airnode operation’s summary should help a caller choose the operation. Its longer description should explain how to make the call and interpret the answer. Airnode’s provider documentation, checked on November 4, 2026, puts these fields at different stages of discovery.
Write for the decision being made
The summary belongs beside the other available operations. It should identify the facts returned, the inputs needed and the operation’s reach, such as how recent or how far back its data goes. The documentation gives this writing pattern: “Turn a place name into the coordinate every other operation takes.” That helps a caller choose a lookup before attempting the next operation.
Details about the answer’s shape, empty results or units belong in the longer description. A constraint affecting one parameter belongs in that parameter’s description, beside the value it constrains. Repeating the summary in every field adds reading without explaining the call.
Check where each field appears
The Airnode’s HTTP discovery document represents operations as variants of its operation request. Each variant’s description uses the operation summary, falling back to the operation description when no summary exists. When both fields exist, the longer description appears on the variant’s operation field.
AirnodeHub’s MCP interface follows the same distinction. Search and listing details provide an operation overview. get-operation-details adds the longer description where present, parameter descriptions and their schemas. A caller therefore needs the operation details before supplying values that the overview alone does not explain.
This is a documented configuration pattern, rather than a tested integration or a newly announced capability. Clear wording does not establish that an upstream response is accurate or current. The provider instructions explain how to place the fields in an API description.