Skip to main content
Glama
cloudcart

storefront-mcp

by cloudcart
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

introspect_graphql_schema

Look up CloudCart Storefront GraphQL types, queries and mutations by name to get exact field signatures and spot fields that only return data when a merchant app is running.

Instructions

Look up types, queries and mutations in the CloudCart Storefront schema by name.

Use this when you already know what something is called. When you know what you want to do but not what it is called, read learn_cloudcart_storefront's guide first — it names the operation for each step.

It searches the names of types, queries and mutations, not of fields: look up the type that holds a field.

Results flag fields that only answer when the merchant runs the app behind them, which is the usual explanation for an empty list.

Input Schema

NameRequiredDescriptionDefault
apiNoWhich schema to search.storefront
modeNo`full` expands the best match with all its fields. `compact` returns the summary line only — use it when you already have the signature and just want a sanity check.full
queryYesName or part of a name — 'Cart', 'cartLinesAdd', 'delivery', 'MoneyV2'.
filterNoRestrict the search to one category.
conversationIdYesFrom learn_cloudcart_storefront.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that matching is against type/query/mutation names (not fields), and that results flag fields gated behind merchant-run apps, which explains empty lists. It does not discuss auth or result-size limits, but for a read-only schema introspection these are minor omissions.

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?

Front-loaded with the core action in sentence one, followed by usage routing and two caveats. Slightly paragraph-heavy for the amount of information, but each paragraph carries a distinct point and none is filler.

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?

No output schema or annotations exist, so the description is the sole source of behavioral context; it covers usage routing and the empty-list explanation. It could say more about what a match looks like in 'full' vs 'compact' mode, but that detail is already in the schema descriptions.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema does not: the 'query' parameter matches names of types/queries/mutations and not fields, and that you should look up the containing type instead. The mode/compact and filter semantics are left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Look up types, queries and mutations in the CloudCart Storefront schema by name') and immediately scopes it against the sibling learn_cloudcart_storefront. An agent can distinguish it from both siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives the when:'Use this when you already know what something is called,' the when-not:'when you know what you want to do but not what it is called,' and names the alternative tool to use instead. It also warns that only names are searched, not fields, which steers the caller to the right query shape.

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