Pure Report — Neutral News
Server Details
Neutral, bias-scored news for AI agents: compare left/right media-bias framing, fact-check receipts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: about_pure_report explains methodology, compare_coverage shows cross-outlet framing, get_article retrieves a single article, get_event returns a neutral event writeup, search_news allows searching, and trending_events lists current events. No overlap in functionality.
All tool names follow a consistent snake_case verb_noun pattern: about_pure_report, compare_coverage, get_article, get_event, search_news, trending_events. The convention is uniform and predictable.
With 6 tools, the set covers the core workflows of a neutral news service: searching, retrieving articles, exploring events, comparing coverage, and learning about the methodology. The count is well-scoped for the domain.
The tool surface provides a complete lifecycle: search, retrieve individual articles and events, compare coverage across outlets, discover trending stories, and understand the service methodology. No obvious gaps for the stated purpose.
Available Tools
6 toolsabout_pure_reportAbout & methodologyARead-onlyInspect
How Pure Report works — the bias scale, neutralization method, the two-gate verification for event accounts, lean labeling, coverage scope (topic list), and the support contact. Call this to cite the source or explain its methodology to a user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | |
| support | Yes | |
| website | No | |
| freshness | No | |
| bias_scale | Yes | |
| what_it_is | No | |
| lean_labeling | No | |
| coverage_scope | No | |
| neutralization | No | |
| verification_gate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals no side effects, and the description adds useful behavioral context (e.g., coverage scope, support contact). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with key information, and every part adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description adequately explains what the tool returns and how it can be used. It fully meets the needs of a documentation/methodology tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the description fully covers the purpose without needing parameter documentation. Schema coverage is 100%, so no gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool explains how Pure Report works, including specific methodological topics like bias scale and two-gate verification. It distinguishes itself from sibling tools which are for searching or retrieving content, whereas this tool provides methodology information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Call this to cite the source or explain its methodology to a user.' This tells the agent exactly when to invoke this tool, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_coverageCompare outlet framingARead-onlyInspect
Show how outlets across the political spectrum framed one event: a per-outlet bias-score spectrum and, where they editorialized, the verbatim framing quotes grouped by left/center/right. The core 'compare the coverage' view — use it to detect slant and consensus.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Event slug from trending_events or a search_news result. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | No | |
| slug | Yes | |
| framing_spectrum | No | |
| how_each_side_framed_it | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds detail about output (bias spectrum and quotes), which is consistent and informative beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the key action and output; no filler. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and an output schema (implied), the description fully covers the tool's purpose, inputs, and outputs, leaving no gaps for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'slug'. Description adds context that slug comes from trending_events or search_news, which the schema description alone does not specify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Show how outlets framed') and resources ('bias-score spectrum', 'framing quotes'), clearly distinguishing from siblings like get_article (single article) or search_news (multiple events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'use it to detect slant and consensus', indicating when to apply, but does not explicitly mention when not to use or list alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_articleGet articleARead-onlyInspect
Fetch one article by id: neutral rewritten title + body, a bias_score for the ORIGINAL source (not the rewrite), source, extracted entities, and the events it belongs to.
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | Yes | Numeric article id (from search_news results). |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| title | No | |
| content | No | |
| summary | No | |
| entities | No | |
| bias_score | No | |
| narratives | No | |
| source_url | No | |
| source_name | No | |
| published_at | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; the description adds behavioral context by detailing the specific returned fields and noting that the title+body are 'neutral rewritten' and bias_score is for the original source, which goes beyond the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that efficiently conveys the tool's purpose and output, but could be slightly reorganized for clarity while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one integer parameter), the presence of an output schema, and read-only annotation, the description fully explains what the tool returns, making it complete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3; the description adds meaning by stating that article_id comes from search_news results, providing useful context beyond the schema's type and requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches one article by ID and enumerates the returned fields (neutral rewritten title+body, bias_score for original source, source, entities, events), effectively distinguishing it from sibling tools like search_news or get_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an article ID and need its details, but does not explicitly state when to avoid using it or mention alternatives, leaving room for clearer guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventNeutral event writeupARead-onlyInspect
Get the full neutral writeup of one news event by slug: a verification-gated account (lede, what-we-know bullets with verbatim source receipts, single-source attributed items) plus a coverage census (how many outlets by political lean, earliest report). If no gated account exists yet, the coverage census is still returned.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Event slug from trending_events or a search_news result, e.g. "tyler-robinson-trial-for-charlie-kirk-murder". |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | No | |
| slug | Yes | |
| status | No | |
| account | No | |
| coverage | Yes | |
| first_seen | No | |
| account_note | No | |
| article_count | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, description details return content (gated account, coverage census) and fallback behavior (census returned even without gated account). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences pack purpose, components, fallback, and slug source. Front-loaded with key action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given presence of output schema, description need not detail return values. It covers main use case and edge case (no gated account), making it complete for a tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single slug parameter. Description adds value by explaining its origin (from trending_events or search_news) and providing an example, going beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves a full neutral writeup of a news event by slug, specifying components like verification-gated account and coverage census. It distinguishes from siblings by focusing on a single event's detailed writeup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for obtaining event details via slug from trending_events or search_news, but lacks explicit when-not-to-use or comparisons with siblings. Still provides clear context for slug source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_newsSearch neutral newsARead-onlyInspect
Search Pure Report's neutral, bias-scored news. Returns articles rewritten to remove loaded language; bias_score (0-100) rates the ORIGINAL source reporting before neutralization (0 = wire-neutral, 100 = advocacy), NOT the returned rewrite, which is neutral by design. Each result also lists the event(s) it belongs to — pass an event slug to get_event for the neutral writeup or compare_coverage for cross-outlet framing. Ranked by relevance and recency.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-40 (default 15). | |
| query | Yes | Keywords or phrase, e.g. "Iran sanctions" or "2026 election". | |
| topic | No | Optional topic-slug filter. An unrecognized value searches all topics and returns a warning. |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| warning | No | |
| applied_topic | No | |
| total_matches | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description adds extensive behavioral detail: bias_score rates the original source before neutralization, the returned article is always neutral, each result lists its parent events, and results are sorted by relevance and recency. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is purposeful and front-loaded with the core action. The description efficiently covers purpose, a key behavioral nuance, event integration, cross-tool guidance, and ranking—all in three sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a separate output schema, the description adds essential context: the distinction between original source bias and returned neutral text, the event association, and clear usage directions. It fully equips the agent to understand what the tool does and how to proceed with results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not elaborate on individual input parameters beyond what the schema already provides, but it adds useful context about the output (bias_score meaning, event relationships) which indirectly helps understand usage. However, parameter-specific semantics are not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search Pure Report's neutral, bias-scored news,' using a specific verb and resource. It clearly distinguishes itself from sibling tools by explaining that this tool is for searching neutral articles, and that related tasks (event writeups, cross-outlet framing) are handled by get_event and compare_coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use alternative tools: 'pass an event slug to get_event for the neutral writeup or compare_coverage for cross-outlet framing.' This provides clear context for choosing between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trending_eventsTrending news eventsARead-onlyInspect
List the news events with the most current coverage activity. Each event clusters many outlets' articles about one story and includes has_account (boolean): true means get_event returns a full verification-gated writeup, false means only the coverage census is available yet. Returns slugs to pass to get_event / compare_coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max events, 1-25 (default 10). |
Output Schema
| Name | Required | Description |
|---|---|---|
| events | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; the description adds valuable behavioral details like clustering, has_account meaning, and slug usage. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and every sentence adds meaningful context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description appropriately explains key return attributes (has_account, slugs) and clustering behavior, making it complete for this simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description does not add further parameter information, but it is not needed since the schema already suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists trending news events with the most coverage activity, explains clustering and the has_account boolean, and directly relates to sibling tools like get_event and compare_coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage as a starting point for trending events by noting the returned slugs are for get_event/compare_coverage, but does not explicitly state when not to use it or provide alternatives for searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!