Skip to main content
Glama

Re:amaze MCP by usefulapi

Get article

reamaze_get_article
Read-only

Get a single help-center article by its slug. Re:amaze REST: GET /articles/{slug}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesThe article slug.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A3.6/5.0
Behavior3/5

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

The readOnlyHint annotation already tells the agent this is a safe read. The description adds only the underlying REST mapping (GET /articles/{slug}), with no detail on 404 behavior, auth requirements, or return shape.

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?

Two compact sentences, core action front-loaded, no filler. Every word contributes.

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?

A simple single-parameter read tool whose safety profile is covered by annotations; no output schema, so return values need not be explained. Adequate for correct invocation, though slightly more on missing-slug behavior would round it out.

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?

Only one parameter, and schema description coverage is 100%, so the schema fully documents 'slug'. The description restates that the lookup is by slug but adds no format or matching semantics beyond the schema. Baseline 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?

States a specific verb and resource ('Get a single help-center article') and specifies the lookup key ('by its slug'), which separates it from the list_articles sibling. The distinction is implicit rather than naming an alternative explicitly.

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

Usage Guidelines3/5

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

Usage is implied by the requirement of a slug and the word 'single', which contrasts with the list tool. There is no explicit statement of when to prefer this over reamaze_list_articles or any prerequisite/error context.

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.