Skip to main content
Glama
RPasquale

lightbulb-mcp

by RPasquale
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

shopify_list_metafield_definitions

Read-onlyIdempotent

List metafield definitions for a given Shopify owner type (product, customer, order, variant, collection, shop). Limit the number of results returned to stay within desired scope.

Instructions

List declared metafield definitions for a given owner type.

Args: owner_type (required): One of: PRODUCT, CUSTOMER, ORDER, VARIANT, COLLECTION, SHOP. limit: Maximum definitions to return (1-250). project_id: Authenticated Project UUID. project_ref: Exact project correlation reference. connector_account_ref: Project-bound connector account alias. idempotency_key: Stable business-action identity. effect: Required and must be read; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
effectYes
owner_typeNo
project_idNo
project_refNo
approval_refNo
idempotency_keyNo
connector_account_refNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.1
    • addedInput schema / properties / approval_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Approval Ref"
+}
    • addedInput schema / properties / connector_account_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Connector Account Ref"
+}
    • addedInput schema / properties / effect
      Added value: +{
+  "const": "read",
+  "title": "Effect",
+  "type": "string"
+}
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}
    • addedInput schema / properties / project_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Id"
+}
    • addedInput schema / properties / project_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Ref"
+}
    • addedInput schema / required
      Added value: +[
+  "effect"
+]
  2. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true), lowering the bar. The description adds modest context beyond annotations, such as 'effect: Required and must be read; Spring verifies it' and the role of approval_ref, but does not explain openWorld implications. No contradiction with annotations.

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 one-line purpose statement is front-loaded, followed by an efficient parameter list. Each entry is short, and the format is scannable. Minor redundancy exists (several parameters are self-descriptive), but no wasted sentences.

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?

Adequate for a simple read/list operation: output schema covers return values, annotations cover safety, and parameter semantics are documented. Gaps remain: no usage differentiation from sibling tools, the odd 'when resuming a write' note on approval_ref for a read-only tool, and the owner_type-required inconsistency.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by documenting all 8 parameters: owner_type gets an inline enum, limit gets a range, and effect gets its constraint. However, it labels owner_type as 'required' while the schema marks it optional with a null default, which is a reliability concern; some entries (e.g., 'Exact project correlation reference') remain cryptic.

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 states a specific verb and resource: 'List declared metafield definitions for a given owner type.' This is clear and distinct from the closest sibling (shopify_get_metafields retrieves metafield values, not definitions), though it does not explicitly name the sibling it differs from.

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?

No when-to-use guidance is provided. The description never distinguishes this tool from alternatives like shopify_get_metafields or shopify_update_metafield, and gives no conditions for selecting it. The arg list only weakly implies usage context; there are no exclusions or alternative routes.

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