Skip to main content
Glama
HearthisAt

hearthis

Official
by HearthisAt

Home section

get_home_section
Read-only

Fetches a specific section of the hearthis.at home screen—stories, latest artists, moods, newcomers, genre trends, or premium—to display targeted content.

Instructions

One section of the hearthis.at home screen: stories (banners), latest_artists (featured artists), moods, newcomers (first upload in the last 7 days), genres_today (sounds per genre in the last 24 h), premium (plans and running promotion).

Input Schema

NameRequiredDescriptionDefault
pageNoPage, starting at 1
countNonewcomers (max 20) and genres_today (max 50)
genreNonewcomers only: genre id from list_genres
sectionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds useful behavior context by explaining each section’s content and recency windows, such as newcomers being uploads in the last 7 days and genres_today covering the last 24 hours.

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?

The description is a single tight sentence with no filler, and the section meanings are front-loaded. It is slightly dense as a long sentence but remains efficient and scannable enough for a tool with six enum values.

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?

With no output schema, the description partially compensates by explaining what each section contains, but it does not describe the response structure or pagination behavior. It is adequate for selecting the section, but an agent still lacks some details needed to interpret the returned data.

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 75%, and the schema describes page, count, and genre, so parameter documentation is mostly handled structurally. The description meaningfully explains the section enum values, which the schema only lists, but it adds little about page, count, or genre beyond what is already in the schema.

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 clearly identifies the resource as one section of the hearthis.at home screen and enumerates every valid section with a short meaning. It is specific enough for an agent to understand what will be returned, though it does not explicitly contrast itself with siblings such as get_feed.

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?

It lists the available sections but gives no guidance on when to call this tool versus alternatives. There are no exclusions, prerequisites, or suggested sibling tools; the only routing hint, list_genres for genre ids, appears in the schema rather than the description.

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