Skip to main content
Glama

SnapWidget

Get Review Source

get_review_source
Read-only

One review source and one page of its reviews, with the review ids for update_review and delete_review. 50 a page.

Input Schema

NameRequiredDescriptionDefault
pageNoThe page, from 1.
per_pageNoReviews a page, 100 at most (50 when not given).
source_idYesThe source's id (the id in list_review_sources).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two useful facts beyond that: it returns ids usable by update_review/delete_review and it pages 50 at a time, but it says nothing about ordering, total counts, or what happens with an invalid source_id.

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 short sentences, zero filler, with the primary return content front-loaded before the pagination note. Nothing here needs trimming.

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 small read-only tool with three fully documented parameters and no output schema, this covers the essentials: what comes back, the page size, and the downstream use of returned ids. The only minor gap is the absence of an explicit pointer to list_review_sources for id discovery, which the schema already supplies.

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 all three parameters are already documented, including defaults and maximums. The description's only added semantic is '50 a page', which duplicates the per_page default already stated in the schema, 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?

States a specific verb and resource: returns one review source plus one page of its reviews. The singular 'one review source' implicitly contrasts with the sibling list_review_sources, but the contrast is never made explicit, so an agent must infer that distinction from the name alone.

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 only implied — it returns the review ids needed by update_review and delete_review, which suggests a read-then-mutate workflow, but the description never says when to prefer this over list_review_sources or how to obtain a source_id (that hint lives only in the schema).

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.