Skip to main content
Glama

Custom Object Entries Get

tiendanube_custom_object_entries_get
Read-onlyIdempotent

Retrieve a single custom object entry by namespace, slug, and entry slug to read its field data, optionally limited to selected fields or rendered as markdown.

Instructions

Get one custom object entry (unstable API). HTTP: GET /custom-objects/{namespace}/{slug}/entries/{entrySlug} Required scope: read_products/write_products API version: unstable

Input Schema

NameRequiredDescriptionDefault
slugYesCustom object slug
fieldsNoComma-separated list of fields to return, to reduce payload size (e.g. 'id,name,variants')
entrySlugYesEntry slug
namespaceYesCustom object namespace
response_formatNoOutput format: 'json' (default, full data) or 'markdown' (human-readable)json

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds non-obvious context beyond them: the API is flagged as unstable, the required OAuth scope is given, and the API version is named. That is real value on top of the structured hints, though return behavior is not described.

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?

Four short lines: purpose, endpoint, scope, version. Nothing is redundant and the operation is front-loaded, with the 'unstable' caveat placed immediately next to the purpose.

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 single-resource GET there is no output schema, and the description says nothing about what an entry returns or how the fields/response_format options shape the payload. Parameters and safety are adequately covered, but the return-side context is missing.

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 the five parameters including the fields selector and response_format enum are already fully documented. The description only echoes the three required slugs via the path template, adding no syntax or format detail beyond 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?

States a specific verb and resource ('Get one custom object entry') and reinforces it with the exact HTTP path template. The singular 'one entry' implicitly distinguishes it from tiendanube_custom_object_entries_list, though no sibling is named 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 only implied: the path template shows you must supply namespace, slug and entrySlug to fetch a single entry, and the required scope is stated. There is no explicit guidance on when to use this versus the list or other entry tools.

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

Deploy Server

Other Tools