Skip to main content
Glama
zeluizr

Adobe Commerce MCP

Look up a bin/magento command

lookup-cli-command
Read-onlyIdempotent

Retrieves official Adobe Commerce bin/magento CLI command details—usage, arguments, and options—and accepts full names, shortcuts, or keywords to verify syntax before running or suggesting commands.

Instructions

Look up a bin/magento command of Adobe Commerce on-premises: description, usage, arguments and options, from the official CLI reference. Accepts full names, Symfony shortcuts (s:up) or keywords. Use it before suggesting or running a bin/magento command.

Input Schema

NameRequiredDescriptionDefault
commandYesA bin/magento command, full or with Symfony shortcuts (e.g. "setup:upgrade", "bin/magento s:up", "indexer:reindex"), or keywords to find one (e.g. "static content deploy", "maintenance")

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so safety needs no restating. The description adds real context: results come from the official CLI reference and the input can be fuzzy ('full names, Symfony shortcuts, keywords'), which explains why near-miss queries still resolve. It omits what happens on a no-match query, a minor gap.

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 tight sentences: the first defines scope, source and return content; the second gives the call-to-action. No filler, and the core definition leads.

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?

With one parameter, no output schema and full annotation coverage, this is nearly self-sufficient — it even says what fields the response contains. Only the behavior on an unresolvable command name is left unstated.

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 coverage is 100% and the single `command` parameter already documents full names, Symfony shortcuts and examples. The description echoes the same accepted input forms (s:up, keywords) so it adds emphasis but no new semantics beyond the schema. Baseline 3 is appropriate.

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?

Names a specific verb and resource ('look up a bin/magento command') and enumerates what is returned: description, usage, arguments, options, from the official CLI reference. The bin/magento domain implicitly separates it from lookup-webapi and search-docs, 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 Guidelines4/5

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

Gives a clear usage rule — 'Use it before suggesting or running a bin/magento command' — which tells the agent when to reach for it. It does not state when to prefer search-docs or read-doc instead, so alternatives remain inferred.

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