Skip to main content
Glama
Sign In
Amazon Q CLI MCP Server

Amazon Q CLI MCP Server

by yanggf8
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

take_q

Send a prompt to Amazon Q CLI to get AI assistance with coding questions, command translation, and status checks.

Instructions

Execute Amazon Q CLI with a prompt to get AI assistance (alias for ask_q)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>"
    },
    "name": "take_q"
  }
}

Input Schema

NameRequiredDescriptionDefault
agentNoAgent/context profile to use (optional)
modelNoModel to use (optional)
promptYesThe question or prompt to send to Amazon Q

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are present, so the description carries the full burden for behavioral disclosure. It mentions executing a CLI and getting AI assistance, but does not disclose side effects, permissions, network usage, output format, or any operational traits beyond the basic function.

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?

The description is a single sentence with no wasted words. The core action is front-loaded, and the alias note efficiently prevents confusion with the sibling ask_q.

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 simple tool with fully documented parameters, the description is adequate for basic invocation. However, it lacks behavioral details, return value expectations, and explicit guidance on choosing this alias over ask_q, leaving some contextual gaps.

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 all three parameters are already documented. The description adds no meaningful detail beyond the word 'prompt', which is already represented in the schema, so the baseline of 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?

The description states a specific action ('Execute Amazon Q CLI') and resource ('Amazon Q CLI') with a prompt, and clarifies it is an alias for ask_q. It clearly conveys what the tool does, though 'AI assistance' remains somewhat generic.

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?

By explicitly stating 'alias for ask_q', the description gives clear context that this tool is interchangeable with the sibling ask_q. It does not provide explicit when/when-not guidance for other siblings, but the alias note makes the usage relationship unambiguous.

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