Skip to main content
Glama

Geotone — Global News Signals

Story timeline

get_story_chain
Read-only

A story timeline: the threaded developments of one multi-day event chain, oldest first (e.g. attack → casualties confirmed → international reaction). Use the chain_id values returned by get_wire. Each development is a headline + link + outlet count + tone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chain_idYesChain id from get_wire

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
metaNo
pageNo
countryNo
firstSeenNo
developmentsYes
lastDevelopmentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedOutput schema / properties / developments / items / properties / meta / properties / asOf
      Added value: +{
      +  "description": "Date of the latest datapoint (UTC)",
      +  "type": "string"
      +}
    • addedOutput schema / properties / developments / items / properties / meta / properties / citation
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / developments / items / properties / meta / properties / page
      Added value: +{
      +  "description": "Canonical geotone.news page for this result — link it when citing",
      +  "type": "string"
      +}
    • addedOutput schema / properties / developments / items / properties / meta / properties / retrievedAt
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / meta / properties / asOf
      Added value: +{
      +  "description": "Date of the latest datapoint (UTC)",
      +  "type": "string"
      +}
    • addedOutput schema / properties / meta / properties / citation
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / meta / properties / page
      Added value: +{
      +  "description": "Canonical geotone.news page for this result — link it when citing",
      +  "type": "string"
      +}
    • addedOutput schema / properties / meta / properties / retrievedAt
      Added value: +{
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "country": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "developments": {
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "domain": {
      +            "type": "string"
      +          },
      +          "firstSeen": {
      +            "type": "string"
      +          },
      +          "meta": {
      +            "properties": {
      +              "attribution": {
      +                "type": "string"
      +              },
      +              "license": {
      +                "type": "string"
      +              },
      +              "source": {
      +                "type": "string"
      +              }
      +            },
      +            "type": "object"
      +          },
      +          "outlets": {
      +            "type": "number"
      +          },
      +          "title": {
      +            "type": "string"
      +          },
      +          "toneAvg": {
      +            "type": "number"
      +          },
      +          "topic": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "url": {
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "firstSeen": {
      +      "type": "string"
      +    },
      +    "id": {
      +      "type": "number"
      +    },
      +    "lastDevelopment": {
      +      "type": "string"
      +    },
      +    "meta": {
      +      "properties": {
      +        "attribution": {
      +          "type": "string"
      +        },
      +        "license": {
      +          "type": "string"
      +        },
      +        "source": {
      +          "type": "string"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "page": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "id",
      +    "developments"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the read-only behavior is known. The description adds the ordering behavior (oldest first) and the structure of each development (headline + link + outlet count + tone), which are meaningful behavioral details beyond the annotation. No side effects or contradictions are present.

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?

Two sentences with no filler. The purpose is front-loaded, followed by the usage prerequisite and output content. Every sentence adds value, making it concise and well-structured.

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 simple one-parameter read tool with an output schema present, the description covers the essential context: what the tool returns, the ordering, and where the parameter comes from. It does not discuss edge cases like invalid chain_id, but the output schema likely covers return structure, so the description is sufficiently complete.

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?

The schema already describes chain_id as 'Chain id from get_wire' with 100% coverage. The description reinforces this source but does not add new meaning such as format, valid range, or examples. According to the rubric, baseline 3 is appropriate when the schema carries the parameter documentation.

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 defines the tool as a story timeline of a multi-day event chain, oldest first, with concrete examples (attack → casualties confirmed → international reaction). It clearly identifies the resource and scope, and the reference to chain_id returned by get_wire helps distinguish it from the wire list. It lacks an explicit action verb, relying on the tool name, which prevents a 5.

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?

The description gives a direct usage prerequisite: use the chain_id values returned by get_wire. This tells the agent how to obtain the required parameter and implies a workflow (call get_wire first, then get_story_chain). It does not explicitly mention when not to use the tool or alternatives, but the context is clear enough for a single-parameter read tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources