Neutral, bias-scored news for AI agents: compare left/right media-bias framing, fact-check receipts.
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.
Average 4.4/5 across 8 of 8 tools scored.
Each tool targets a distinct resource or action—articles, events, trending, feedback, methodology—but get_event and compare_coverage both relate to event coverage, requiring careful description reading to avoid confusion. Still, their outputs are clearly different.
Most tools follow verb_noun (get_article, search_news, submit_feedback), but about_pure_report and trending_events deviate from that pattern, making the set slightly inconsistent.
Eight tools is a well-scoped number for a news API covering search, retrieval, comparison, trending, feedback, and methodology, with no redundancy.
The tool set covers the full user workflow: search, read articles, retrieve event writeups, compare coverage, see trending, and submit/check feedback. A browse-all-events endpoint is missing, but trending_events and search_news provide adequate discovery.
about_pure_reportAbout & methodologyAHow 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 |
|---|---|---|---|
| article_id | No | Optional context for the report. | |
| event_slug | No | Optional context for the report. | |
| report_body | No | Optional. The detail needed to act. | |
| report_kind | No | Optional, defaults to bug. | |
| report_subject | No | Optional. Providing this (with report_body) files feedback and returns a ref under "filed" — use only if submit_feedback is missing from your tools. |
| Name | Required | Description |
|---|---|---|
| name | No | |
| filed | 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 | |
| reporting_problems | No | |
| reporting_problems_if_submit_feedback_is_missing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring readOnlyHint=true, the bar is lower, and the description adds useful context about the tool's informational content. However, it does not mention the potential write side effect when report_subject and report_body are provided (which files feedback), nor any other limitations. It provides moderate transparency beyond the annotation but not full behavioral disclosure.
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 a clear list of content, and ends with a practical usage directive. Every word earns its place with no redundancy or fluff.
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?
The tool is an informational resource, and the description covers its full scope and purpose. Since an output schema exists, return format details are not required. The presence of optional parameters is not explained in the description, but they are well-documented in the schema, so the overall context is complete enough.
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 description coverage is 100%, so the baseline is 3. The description does not add any meaning to the parameters, but the schema descriptions are already detailed, especially for report_subject. No additional compensation is needed or provided.
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 what the tool does: it explains how Pure Report works, listing specific content areas (bias scale, neutralization method, verification, labeling, coverage, support contact) and explicitly says when to call it ('to cite the source or explain its methodology'). This distinguishes it from sibling tools like get_article or search_news.
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 provides direct usage guidance ('Call this to cite the source or explain its methodology to a user'), making the intended use clear. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to disambiguate from siblings. The schema additionally provides fallback guidance for report_subject, but that is outside the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_feedbackCheck a feedback replyALook up feedback you filed with submit_feedback, using the ref it returned (e.g. PR-7F3K2Q). Returns the current status (open, answered, closed) and the operator's reply once one exists. Replies are written by a human and are not immediate — poll sparingly, on the order of hours or days, not seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The ref from submit_feedback, e.g. 'PR-7F3K2Q'. |
| Name | Required | Description |
|---|---|---|
| ref | Yes | |
| kind | No | |
| reply | No | |
| status | Yes | |
| message | No | |
| subject | No | |
| replied_at | No | |
| submitted_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals that replies are human-written and delayed, that the reply appears only 'once one exists,' and that status can be open/answered/closed. This adds meaningful behavioral context, though it does not cover failure or not-found behavior.
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 exactly two sentences: the first front-loads the purpose and input source, the second adds return fields and critical timing guidance. Every word contributes, with no filler or unnecessary repetition.
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?
For a simple one-parameter read-only tool with an output schema, the description adequately covers prerequisite (ref from submit_feedback), return values (status and reply), and usage cadence. The only omission is error handling, which is minor for this scope and not required given the output schema exists.
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?
The input schema already covers the single parameter 'ref' with a description that includes the same example format as the tool description. The description adds no new meaning beyond the schema, so the baseline score of 3 applies.
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 states a specific verb and resource: 'Look up feedback you filed with submit_feedback.' It clearly distinguishes itself from the sibling submit_feedback tool by referencing the ref returned by that tool, and from other read tools by its focus on feedback status and replies.
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 explicitly says when to use the tool: after filing feedback via submit_feedback, using the returned ref. It also provides clear exclusion guidance with 'poll sparingly, on the order of hours or days, not seconds,' and explains why (replies are human-written and not immediate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_coverageCompare outlet framingAShow 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. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | No | |
| slug | Yes | |
| framing_spectrum | No | |
| how_each_side_framed_it | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, so the description's mention of output details (bias-score spectrum, quotes) adds useful context without contradicting. It doesn't add behavioral traits beyond what annotations provide, but the output description is valuable.
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 deliver the purpose and usage efficiently. No fluff, front-loaded with key action and output.
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?
The description fully covers the tool's complexity: it explains the output (spectrum, framing quotes grouped by bias) and its role as the core comparison view. With an output schema present, return values need no extra explanation.
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 description of the slug parameter. The description adds context that the slug comes from trending_events or search_news, providing extra meaning beyond the schema.
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 shows how outlets framed an event with a bias-score spectrum and verbatim framing quotes grouped by ideology. It distinguishes itself from siblings like get_article (single article) and trending_events (list of 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?
It tells agents to use it to detect slant and consensus, and mentions the slug comes from trending_events or search_news. However, it could explicitly state when not to use it or list alternatives (e.g., use get_article for a single article).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_articleGet articleAFetch 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). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| title | No | |
| events | No | |
| content | No | |
| summary | No | |
| entities | No | |
| bias_score | No | |
| source_url | No | |
| source_name | No | |
| published_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds a key behavioral nuance: the bias_score refers to the ORIGINAL source, not the neutral rewrite. It also discloses the exact set of returned components, which prevents misinterpretation.
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 sentence that is information-dense without fluff. It lists the return fields in a structured way, making it easy to scan.
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?
For a simple one-parameter tool with an output schema and read-only annotation, the description covers the essential semantics and return contents. No critical gaps remain.
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 description coverage is 100%, so the parameter is already well-documented. The description does not add additional parameter details beyond restating 'by id', so baseline 3 is appropriate.
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, source, entities, events). This specific verb+resource combo distinguishes it from siblings like search_news and 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 context is clear: use this when you have a specific article id (from search_news, per schema) and need full article details. It does not explicitly mention when not to use it or list alternatives, but the reading is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventNeutral event writeupAGet 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". |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | No | |
| slug | Yes | |
| status | No | |
| account | No | |
| coverage | Yes | |
| first_seen | No | |
| account_note | No | |
| article_count | No | |
| coverage_report | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the description adds value by explaining the internal structure of the writeup and the fallback behavior when no gated account exists yet. This goes beyond the safety annotation and gives useful behavioral context without contradicting it.
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 the main purpose, and every sentence adds value: the first details content, the second clarifies fallback. No fluff or 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?
Given the output schema exists, the description sufficiently covers the tool's behavior: what the writeup contains, what the coverage census includes, and what happens if the gated account isn't ready. It is complete for a moderately complex tool and leaves no major gaps.
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?
The input schema already provides a thorough description of the slug parameter, including its source and an example (100% coverage). The description adds no new parameter semantics beyond repeating 'by slug', so the baseline score of 3 is appropriate.
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 gets the full neutral writeup of one news event by slug, specifying the content (verification-gated account with lede, what-we-know bullets, receipts, attributed items) and the coverage census. This distinguishes it from siblings like get_article (likely raw article) and search_news (search). The verb and resource are specific and unambiguous.
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 context by specifying the slug comes from trending_events or search_news, and explains what to expect. However, it doesn't explicitly state when to prefer this tool over alternatives (e.g., when needing verification-gated coverage vs. raw article), nor does it mention exclusions. This is clear context but lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_newsSearch neutral newsASearch 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 to RETURN, 1-40 (default 15). Does not affect total_matches, which always reports how many articles matched. | |
| 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. | |
| offset | No | Skip this many matches — page through results beyond the 40-row limit. The response echoes offset/returned/next_offset; next_offset is null on the last page. | |
| published_after | No | Only articles published on/after this date. 'YYYY-MM-DD' or full ISO. Use with published_before to bound a period, e.g. coverage during June. | |
| published_before | No | Only articles published on/before this date. 'YYYY-MM-DD' or full ISO. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| offset | No | |
| results | Yes | |
| warning | No | |
| returned | No | |
| next_offset | No | |
| applied_topic | No | |
| total_matches | Yes | TOTAL articles matching the query, independent of `limit` — not the number returned. len(results) < total_matches means more exist. |
| result_composition | No | Factual description of what the returned set is ABOUT. Search is lexical, so every query term appears in every result; this reports whether a term is the SUBJECT (title/entities/lede) or only a body mention, plus the entity distribution. Measurements only — no verdict. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes significantly beyond the readOnlyHint annotation by explaining that returned articles are rewritten to remove loaded language, and crucially that bias_score rates the ORIGINAL source, not the neutralized rewrite. This prevents a major misunderstanding. It also discloses that results include associated events and that ordering is by relevance and recency, providing rich behavioral context.
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 paragraph but every sentence adds value: it explains the neutralization, bias_score nuance, event links, and ranking. It is slightly long but not bloated; the structure could be improved with clearer sentence breaks, but it remains efficient and front-loaded with the core purpose.
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 tool's complexity (bias_score semantics, event associations, pagination) and that an output schema exists, the description covers the key behavioral nuances that could trip up an agent: the bias_score scope, the existence of event slugs, and the linking to related tools. With a detailed schema also present, nothing important is left unexplained.
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 description coverage is 100% and each parameter has detailed, self-explanatory descriptions (e.g., offset explains next_offset pagination, limit notes total_matches). The description adds no additional parameter-specific syntax or semantics beyond what the schema already covers, so the baseline 3 is appropriate.
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 begins with 'Search Pure Report's neutral, bias-scored news,' clearly stating the action (search) and resource (Pure Report's neutral, bias-scored news). It distinguishes itself from siblings by explaining that results include event slugs which can be passed to get_event or compare_coverage, making the tool's specific role clear.
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 provides clear context for when to use the tool: searching for neutral, bias-scored news. It explicitly directs users to get_event for neutral writeups and compare_coverage for cross-outlet framing when they have an event slug, offering alternatives. However, it doesn't explicitly state when not to use search_news (e.g., for fetching a known article via get_article), so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSend feedback to the operatorAInspectReport a problem or request to Pure Report's operator and get a tracking ref back. Use this when the data looks wrong — a bias score or outlet lean that doesn't match the source, an event cluster mixing unrelated stories, a missing neutral writeup, a broken article — or to ask a methodology question or request a capability. Include the article_id or event_slug you were looking at; that context is what makes a report actionable. A human reads these: replies take time and are not guaranteed. Call check_feedback with the returned ref to read the reply.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The detail needed to act: what you expected, what you got, and how to reproduce it. Max 12000 chars. | |
| kind | No | DEPRECATED alias for category; still accepted. | |
| subject | Yes | One line, max 200 chars. | |
| category | No | bug = broken or erroring; dx = developer-experience friction; data_error = wrong/miscategorised data; data_gap = missing coverage or field; feature = a capability request; question = methodology or usage; other. Defaults to bug. | |
| article_id | No | Optional article the report concerns. | |
| event_slug | No | Optional event slug the report concerns. |
| Name | Required | Description |
|---|---|---|
| ref | Yes | |
| status | Yes | |
| message | No | |
| how_to_check | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only negative hints (not read-only, not idempotent, not destructive), so the description carries the burden. It adds crucial behavioral context: a human reads the feedback, replies take time and are not guaranteed, and a tracking ref is returned. This goes well beyond the schema and manages expectations appropriately.
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 focused paragraph that front-loads the main purpose and outcome. Every sentence earns its place: use cases, required context, human caveat, and follow-up action. There is no fluff or repetition of schema information.
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 tool's complexity and the presence of an output schema, the description covers everything needed: what it does, when to use it, what context to provide, and what to expect. It even describes the returned tracking ref and how to use it, making the feedback loop fully transparent.
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 detailed descriptions, so the baseline is 3. The description adds value by explicitly instructing to include article_id or event_slug and explaining why ('that context is what makes a report actionable'). It does not repeat schema details for each field, but it highlights the most behaviorally important parameters.
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 a clear verb+resource: 'Report a problem or request to Pure Report's operator and get a tracking ref back.' It distinguishes itself from sibling tools by naming check_feedback as the follow-up for reading replies, and by enumerating concrete feedback types (wrong bias, miscategorised events, missing writeup). This leaves no ambiguity about what the tool does.
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 gives explicit 'Use this when...' scenarios, including data errors, methodology questions, and capability requests. It also tells the user what to include (article_id/event_slug) and points to check_feedback as the alternative for reading the reply, effectively providing both when-to-use and next-step guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trending_eventsTrending news eventsAList 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). |
| Name | Required | Description |
|---|---|---|
| events | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds valuable context about the has_account boolean and what it means for data availability, beyond what annotations provide. No contradiction.
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 with no wasted words. It front-loads the core purpose and immediately adds relevant details about the return value and usage.
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 parameter set (1 parameter, no required) and the presence of an output schema, the description covers the key behavioral aspects: clustering of articles, has_account interpretation, and relation to other tools.
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 description coverage is 100% for the only parameter (limit). The description does not add further parameter semantics beyond what the schema already provides, so baseline score of 3 is appropriate.
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 explicitly states 'List the news events with the most current coverage activity,' using a specific verb and resource. It distinguishes the tool from siblings like get_event and compare_coverage by mentioning it returns slugs for those tools.
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 says 'Returns slugs to pass to get_event / compare_coverage,' which guides the agent on downstream usage. It does not explicitly state when not to use, but the context implies this is for exploring trending stories.
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.
No comments yet. Be the first to start the discussion!