Skip to main content
Glama

seodata_list_articles

Retrieve published articles from a storefront with full content. Use limit and offset to paginate results.

Instructions

Опубликованные статьи витрины с полным контентом. Scope: content:read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoМакс. статей (1–100, по умолчанию 50)
offsetNoСмещение для пагинации (по умолчанию 0)
storefrontSlugYesSlug витрины из seodata_list_storefronts

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses two things beyond the schema: results are limited to published articles with full content (not summaries), and the call requires the content:read scope. It omits pagination semantics, result ordering, and whether the full content is truncated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short fragments, front-loaded with the resource and its key property, then the required scope. Nothing is wasted, though the telegraphic fragment style leaves no room for routing or pagination context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list endpoint with no output schema and no annotations, the description covers what is returned (published, full content) and the auth scope, but says nothing about pagination behavior, default/max page sizes, or result shape. Adequate but with clear gaps an agent must discover by calling.

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%, so limit, offset, and storefrontSlug are already documented in the schema (including the cross-reference to seodata_list_storefronts). The description adds no parameter-level meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource precisely ('Опубликованные статьи витрины') and adds a meaningful qualifier ('с полным контентом'), so an agent knows this returns published articles with full bodies. It does not, however, differentiate itself from the sibling seodata_get_article (single article) or seodata_search, leaving the boundary to be inferred from the name.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance. The only usage-adjacent signal is the 'Scope: content:read' permission note; nothing tells the agent to prefer this over seodata_get_article or seodata_search, nor that a storefrontSlug must first come from seodata_list_storefronts.

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