BinaSmart MCP Server

One news article in full

get_news_article

Read-only

Retrieve the full text of a BinaSmart news article using its slug from list_news, so you can quote or summarize the complete story.

Instructions

The full text of a single BinaSmart news article by its slug from list_news.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes	Article slug from list_news

Output Schema

TableJSON Schema

Name	Required	Description	Default
`article`	No	The article with its full text
`source_url`	No	bina.et page this result comes from; cite it

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.2Oct 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "article": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "properties": {},
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The article with its full text"
+    },
+    "source_url": {
+      "description": "bina.et page this result comes from; cite it",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedv0.1.0Oct 18, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the bar is lower. The description's only added signal is that the response is the complete article text (not a snippet). With an output schema present, no return-value detail is owed, but nothing is said about error behavior.

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?

One sentence, zero filler, with the resource and its lookup key front-loaded. Nothing could be removed without losing information.

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 trivial single-parameter read with an output schema, full annotation coverage, and a complete input schema, the description supplies everything needed to call it correctly. Only slug-validation or not-found behavior is left unstated, which is a minor gap.

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% and there is a single parameter, so the schema already documents 'slug' fully, including its origin. The description's 'by its slug from list_news' merely echoes the schema wording rather than adding format or validation detail, so baseline 3 applies.

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 (fetch the full text of one news article) plus the exact lookup key (slug). It also names list_news as the origin of that slug, so an agent can immediately tell it apart from the sibling listing tool.

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 phrase 'by its slug from list_news' effectively routes the agent: call list_news first, then come here with a slug. It gives clear context for use but states no exclusions or failure conditions (e.g., unknown/expired slug).

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