Skip to main content
Glama

get_post

Retrieve full details of a single crypto news post including title, summary, body, categories, hashtags, and source by providing a slug or numeric ID.

Instructions

Full detail of a single post — title, summary, full body, all categories, hashtags, source attribution. Accepts either a slug (from a previous tool call) or a numeric id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slug_or_idYes
langNoen-US

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • MCP tool handler for 'get_post' — decorated with @mcp.tool, accepts slug_or_id (str) and lang (str), delegates to ZippClient.get_post().
    @mcp.tool(
        name="get_post",
        description=(
            "Full detail of a single post — title, summary, full body, all "
            "categories, hashtags, source attribution. Accepts either a slug "
            "(from a previous tool call) or a numeric id."
        ),
    )
    async def get_post(
        slug_or_id: str,
        lang: str = _DEFAULT_LANG,
    ) -> dict[str, Any]:
        """Get the full content of a single post.
    
        Args:
            slug_or_id: Either the post slug (e.g. "bitcoin-etf-...") or numeric id.
            lang: BCP-47 language tag (default en-US).
        """
        async with ZippClient() as client:
            return await client.get_post(slug_or_id=slug_or_id, lang=lang)
  • Function signature defines input schema: slug_or_id (str, required) and lang (str, default 'en-US').
    async def get_post(
        slug_or_id: str,
        lang: str = _DEFAULT_LANG,
    ) -> dict[str, Any]:
  • Registration via @mcp.tool(name='get_post', description=...) decorator on FastMCP instance 'mcp'.
    @mcp.tool(
        name="get_post",
        description=(
            "Full detail of a single post — title, summary, full body, all "
            "categories, hashtags, source attribution. Accepts either a slug "
            "(from a previous tool call) or a numeric id."
        ),
    )
  • ZippClient.get_post() — helper that makes the actual HTTP GET request to /api/v1/news/posts/{slug_or_id} with lang param.
    async def get_post(
        self,
        *,
        slug_or_id: str,
        lang: str = "en-US",
    ) -> dict[str, Any]:
        # Path encoding is handled by httpx — slugs are URL-safe by
        # construction, numeric ids are ASCII digits.
        return await self._get(f"/posts/{slug_or_id}", params={"lang": lang})
  • _get() internal helper used by get_post — constructs the httpx GET request, raises ZippAPIError on non-2xx, returns JSON.
    async def _get(self, path: str, *, params: dict[str, Any]) -> dict[str, Any]:
        # Drop None values so the upstream doesn't get e.g. ?category=None.
        clean = {k: v for k, v in params.items() if v is not None}
        resp = await self._client.get(_API_PREFIX + path, params=clean)
        if resp.status_code >= 400:
            raise ZippAPIError(resp.status_code, resp.text)
        return resp.json()
Behavior4/5

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

Describes what data is returned (title, summary, full body, etc.). No annotations exist, so description carries burden; side effects are absent, but auth needs or rate limits are not mentioned.

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 sentences with no wasted words, clearly front-loading capability and input options.

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?

Given an output schema exists, the description covers input and output well. Still, could note that it reads a specific post, not a list, and lacks error handling context.

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?

Clarifies that 'slug_or_id' can be a slug or numeric id, adding value beyond schema. However, the 'lang' parameter is left undescribed, and with 0% schema coverage, more detail would help.

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 states it retrieves full details of a single post, listing specific fields. It distinguishes from siblings like get_latest or get_featured by emphasizing a single post, but does not explicitly contrast usage.

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?

Mentions acceptable inputs (slug or numeric id), but lacks guidance on when to choose this over sibling tools or when not to use it.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/deficlow/zipp-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server