oriiion

Add News Source

add_news_source

Add a news source to the user's account, so its articles show up in list_news and feed news posts. Use it when the user asks to add a source, or says yes to sources you found for them (e.g. with web_search) — add them one call each instead of asking the user to copy the addresses into settings. source can be an RSS/Atom feed URL, a website or news page address (the feed is found automatically; a site without one is scanned), a YouTube channel, a subreddit (r/name), a Substack/Medium address or a podcast. Only add sources the user asked for or agreed to. status 'scanning' means it is NOT added yet — say so and try again in a few minutes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "source": "<source>"
    },
    "name": "add_news_source"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	Optional display name; defaults to the feed's own title
`source`	Yes	Feed URL, site address, YouTube channel, subreddit or podcast

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare this is a mutating, open-world, non-idempotent operation, and the description is consistent with that. It adds useful behavioral context beyond annotations: what adding a source causes (articles appear in list_news and feed posts), automatic feed discovery/scanning for websites, and the asynchronous 'scanning' state meaning the source is not yet added. It could do slightly more on expected permissions or full return statuses, but the key operational behavior is disclosed.

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?

The description is front-loaded with purpose and usage, then moves into accepted source formats and the key status caveat. It is dense but every sentence carries relevant information, including the important 'scanning' warning at the end.

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 two-parameter mutation tool with no output schema, the description covers purpose, consent constraints, accepted input formats, and one critical return-state caveat ('scanning'). It could be slightly more complete by describing other possible statuses or the shape of a successful return, but it is sufficient to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description earns an upgrade by enriching the 'source' parameter far beyond the schema: RSS/Atom URLs, website/news page addresses with automatic feed discovery or scanning, YouTube channels, subreddits, Substack/Medium addresses, and podcasts. It does not add meaning for 'name', but the schema already documents that it defaults to the feed's own title.

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 ('Add a news source to the user's account') plus the downstream effect ('articles show up in list_news and feed news posts'). This clearly distinguishes it from siblings like list_news_sources, remove_news_source, and generate_from_news.

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?

Explicitly covers when to use it: user asks to add a source or agrees to sources found via web_search, with the instruction to add sources one call each rather than ask the user to copy addresses. It also states a clear exclusion ('Only add sources the user asked for or agreed to'), which is strong guardrail guidance.

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

All oriiion 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.

Resources

Need Help?