Skip to main content
Glama

Company news coverage

company_news
Read-onlyIdempotent

Global news coverage of the companies the workspace holds in its book or watches, and of the natural persons it watches where person data is switched on (node_type person), read from the GDELT Project's 15 minute files in English and machine translated from about 65 languages. Without node_id it lists the companies, each with its newest reading of a day read in full (the day in progress is never read in full and reads feed_gap), or latest null while no reading is stored, which says nothing about coverage. With node_id it returns that company's daily readings, newest first (days, default 30), and the newest 100 articles behind the newest one together with every article its events list: article_key, url, publisher_host, published_at, language, gdelt_tone and the matched_organization name. A reading's state is reading (tone_mean is the mean GDELT document tone of the articles in the 30 day window, article_keys cite the newest 100 of them and articles_window counts them all), too_little_coverage (fewer than three articles in a fully read window, no tone) or feed_gap (the day or a thin window not fully read, no tone). Tone is context beside the credit view and never part of the risk score. With node_id it also returns events, the company's serious news events of the same days: event_type (insolvency, sanctions, fraud, cyberattack, accident, legal_action, executive_exit, layoffs, strike or environment_rights, from GDELT's own theme codes under a reviewed mapping, never a model), severity, opened_at, detected_at, closes_at, the articles, independent sources and languages behind it, whether it raised an alert, the article_keys of its newest 20 articles, and its check: before any alert a model reads the event's articles and a deterministic gate keeps its verdict only when the cited article is one of the event's own and the quote is found in it verbatim; status is confirmed (only such an event alerts), not_confirmed (news to read, not a finding), pending, unchecked (the check could not run, no alert went out) or covered, with verdict, the checked event_type, the cited article_key, reason, model, prompt_version, checked_at and second_source_articles, the NewsAPI.ai articles the check read beside the event's own (article_key, url, publisher_host, published_at, language, provider), empty while that source is off. No headline, article text or quote is kept, and no person name beyond the matched name of a followed person. A watched person is read for the due diligence the bank runs on that person, its tone context and never a score of the person. A sole trader (sole_trader true, a natural person's business) carries no tone, so latest is null, readings are empty and gdelt_tone is null, while its articles and events are served. Neither is ever scored. Every answer carries the GDELT attribution to show with the data. A company outside the workspace's book and watch list answers 404.

Input Schema

NameRequiredDescriptionDefault
daysNoDaily readings to return with node_id, default 30.
limitNoPage size, default 50, maximum 100.
offsetNoRows to skip, default 0.
node_idNoThe company's graph node id; omit to list companies.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond readOnly/idempotent/closed-world annotations, the description discloses a wealth of behavior: the day in progress is never read in full and reads feed_gap, reading states (reading/too_little_coverage/feed_gap) with their tone and article-key semantics, the deterministic verbatim-quote gate and its status enum, that no headline/text/quote or person name is retained, that sole traders carry no tone, and the required GDELT attribution. This is genuinely additive context an agent could not get from annotations alone.

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

Conciseness3/5

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

Almost every clause carries substantive information, and the coverage statement is front-loaded, but the body is one enormous run-on paragraph with nested parentheticals that is hard for an agent to parse. Length is defensible given the tool's complexity, yet structure (headings or bullets for list vs detail vs events) would make it far more usable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly bears the full burden of describing returns and does so exhaustively — reading fields, tone_mean window, article_keys vs articles_window, event fields, check verdict fields, and status meanings. Nothing an agent needs to interpret a response appears missing.

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%, so all four parameters including defaults and ranges are already documented, making 3 the baseline. The description restates days (default 30) and node_id's list-vs-detail behavior without adding syntax or format detail beyond the schema, so it adds little new parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource stack — GDELT-sourced global news coverage of book/watchlist companies and watched persons, returning daily readings, articles, and serious news events with verdict checks. An agent can tell exactly what data comes back. It does not name siblings, but the resource and output shape are unambiguous.

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 draws a clear behavioral fork on node_id (omit to list companies, supply to get readings/articles/events) and notes the 404 boundary for out-of-scope companies. However it never says when to reach for this tool versus overlapping siblings such as company_events or company_social, which also surface company news and events. Usage is implied through parameter branching rather than stated as when/when-not guidance.

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