Skip to main content
Glama

get_article

Read-onlyIdempotent

Fetch the full text of a single TipRanks article.

Resolve a TipRanks article URL (e.g. from get_latest_news / get_assets_news),
a slug, or a numeric post id to its title, excerpt, full body text
(HTML-stripped, capped at 8000 chars), author, category, date, canonical
URL, and any tagged tickers.

Args:
    identifier: Numeric post id, slug, or a tipranks.com article URL.

Returns a JSON object, or {"error": ...} when no matching TipRanks article
exists (e.g. the URL points to an aggregated third-party site, which is not
stored in TipRanks).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
identifierYesA TipRanks article identifier: the numeric post id, the slug, or a full tipranks.com article URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "title": "Result",
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "title": "get_articleOutput",
      -  "type": "object"
      -}New value: +null
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, which covers safety. The description adds non-obvious behavior: HTML-stripped text, an 8000-character cap, and a JSON error response when no matching article exists. This goes beyond annotations and helps set expectations.

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 compact (~80 words), front-loaded with the core purpose, and structured with Args/Returns sections. Every sentence adds useful information; no filler or repetition.

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 single-parameter read tool with no output schema and strong annotations, the description is fully complete. It covers input types, the exact return fields, the 8000-character limit, and the error behavior — everything an agent needs to invoke and interpret the result.

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% and the schema already describes the identifier as numeric post id, slug, or full tipranks.com URL. The description echoes this and adds the source hint (from get_latest_news / get_assets_news), which is slight added value but not substantial beyond the schema.

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 opens with a specific verb+resource: "Fetch the full text of a single TipRanks article." It clearly distinguishes this from sibling news tools like get_latest_news and get_assets_news by focusing on resolving a single article identifier to its full content.

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

Usage Guidelines4/5

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

The description provides clear context by stating the identifier can come from get_latest_news / get_assets_news, implying when to use this tool. It also notes an exclusion (URLs to aggregated third-party sites are not stored), which counts as a when-not. However, it does not explicitly name alternative tools for those excluded cases, so it falls short of a 5.

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