Skip to main content
Glama
zeluizr

Adobe Commerce MCP

Read an Adobe Commerce doc page

read-doc
Read-onlyIdempotent

Read a full Adobe Commerce documentation page or a single section by document ID, source path, or public Adobe URL, so you can pull exact details after a search or from a pasted docs link.

Instructions

Read a full page, or one section, of the bundled Adobe Commerce documentation by id (from search-docs), source path or public developer.adobe.com / experienceleague.adobe.com URL. Use it after search-docs, or when the user pastes a docs link.

Input Schema

NameRequiredDescriptionDefault
refYesDocument id as returned by search-docs (e.g. "php/development/components/plugins.md"), source path (e.g. "commerce-php/src/pages/development/components/plugins.md") or public URL. Append "#anchor" to read one section.
sectionNoSection anchor or heading to read only that section (e.g. "around-methods")

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the docs are 'bundled' (local, not a live fetch), and a single section can be targeted instead of the whole page. It does not mention output format or how very large pages are handled.

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, front-loaded with the core action and immediately followed by the routing condition. No redundant restatement of the title or wasted clauses.

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?

For a two-parameter, fully documented, annotation-rich read tool this is nearly sufficient; the main omissions are what the returned content looks like (markdown? full text?) and any size or truncation behavior for long pages. Since no output schema exists, that omission is a real, if minor, gap.

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%, and the schema already documents every accepted ref form, the #anchor convention, and the section parameter with an example. The description restates the same reference types without adding syntax, precedence, or fallback behavior, so baseline 3 applies.

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 ('Read a full page, or one section, of the bundled Adobe Commerce documentation') and explicitly bounds the accepted reference forms (id, source path, public URL). This is clearly distinguishable from siblings like search-docs or lookup-webapi, which retrieve different artifacts.

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

Usage Guidelines4/5

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

Gives explicit sequencing guidance: 'Use it after search-docs, or when the user pastes a docs link', which names the primary alternative and the condition that selects this tool. It stops short of any when-not-to-use statement (e.g. don't use for searching unknown topics), so it is clear context without full exclusions.

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