Skip to main content
Glama

Polymath News

Search Polymath News

search_news

Search current news for a specific reader. Covers technology, AI, business, policy, and media and entertainment (about 500 curated sources, not all news). Returns one list of stories, best match first: events, each grouped across the outlets covering it, with every article (publisher, date, link), the lead article's excerpt, the names in it, and which of your terms it matches and how well (0 to 1). Then Polymath reports, with title, insight and link. Put topics in "interests": 3 to 8 specific topics, named the way a news desk would ("AI regulation", "data centers"). The name of a person or a company works as an interest too ("Nvidia"). Each interest gets its fair share of the list, and the reply says what each one found, including nothing. "query" is for keywords. "profile" says who you work for: it tailors reports and rarely selects stories by itself. "since" returns only what is new or updated after a time; every reply gives next_since, the value to pass next time. With no arguments it returns the top stories right now. No API key was sent, so this is a trial: 1 searches a day, up to 3 stories per search, report titles and links only.

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": "search_news"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNoKeywords or a short question, for example "EU AI Act enforcement" or "who is buying data centers".
sinceNoOnly what is new since this time (ISO 8601, for example "2026-11-09T07:00:00Z"). Pass the next_since value from your previous search_news reply. Overrides since_days. Stories are marked new or updated.
detailNoLess or more text. brief (default): every story with every article (publisher, date, link), the lead article's excerpt and the names in it. full: the same, plus every article's excerpt and a summary of each Polymath report.
profileNoWho you are working for, in one or two sentences, for example "a mid-size US law firm with a technology practice". The profile tailors reports. It rarely selects stories by itself, so put the topics in "interests".
interestsNoThree to eight specific topics this reader cares about, which you infer from the profile, for example ["AI regulation", "data centers", "Nvidia"]. Name each topic the way a news desk would. The name of a person or a company works as an interest too. Each interest gets its fair share of the results, and every story says which interests it matches and how well, so specific topics work far better than a profile alone.
since_daysNoHow many days back to look. Default 7 for stories and 30 for reports. Stories go back at most 30 days, reports 90.
max_resultsNoMost stories and most reports to return, each. Default 8.

Output Schema

NameRequiredDescriptionDefault
notesYes
sinceNo
termsNoEach of your terms that selected results, with what it returned.
detailYes
includeNoOlder replies only.
matcherNoPresent when the results come from Polymath's own search (the default).
reportsYes
storiesYes
coverageNoOlder replies only.
next_sinceYesPass as "since" on the next call to get only what is new.
signup_urlNo
balance_usdNo
charged_usdNo
top_storiesNoTrue when the list is the top stories: nothing was asked for, or only a profile that matched nothing.
window_daysYes
used_free_searchNo
trial_searches_leftNo
free_searches_remainingNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing quota and trial constraints (1 search per day, up to 3 stories, report titles and links only), the incremental-polling contract via next_since, and how each interest's coverage is reported back. The annotations' readOnlyHint=false is not contradicted, since the description never claims a pure read and the quota consumption explains a non-read-only classification.

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?

Front-loaded with purpose, scope, then return shape, then parameter guidance and trial limits in a logical order. Some of the return-shape enumeration duplicates the output schema and could be trimmed without loss.

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?

For a seven-parameter, open-ended search tool this covers the corpus boundary, defaults, incremental polling, quota limits, and output ordering. With an output schema present, no further return-value detail is required.

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 the schema already documents all seven parameters including examples and defaults. The description reinforces the intent of "interests" vs "query" vs "profile" and the fair-share allocation, but adds little syntax or format detail the schema lacks.

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?

States a specific verb and resource ("Search current news for a specific reader") and immediately bounds the corpus ("about 500 curated sources, not all news") plus the topic areas covered. An agent knows exactly what this retrieves and what it does not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing rules between the parameters: topics belong in "interests" (3-8, named like a news desk), "query" is for keywords, "profile" tailors reports but rarely selects stories, "since" returns only new/updated items. It also defines the no-argument behavior ("top stories right now"), so the agent knows the default path.

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