AWS AgentCore MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting different components of the AWS AgentCore platform (code interpretation, gateway integration, identity management, memory, observability, tool integration, and quickstart). There is no overlap in functionality, making it easy for an agent to select the appropriate tool.
Naming Consistency4/5
Six of the seven tools follow a consistent 'agentcore_' prefix pattern with descriptive suffixes (e.g., agentcore_code_interpreter, agentcore_memory), which is highly predictable. The outlier 'quickstart' deviates slightly by omitting the prefix, but it remains readable and contextually appropriate.
Tool Count5/5
With 7 tools, this server is well-scoped for its purpose of documenting AWS AgentCore components. Each tool covers a distinct aspect of the platform, and the count is neither too sparse nor overwhelming, allowing comprehensive coverage without redundancy.
Completeness4/5
The tool set provides thorough documentation coverage for core AWS AgentCore features, including development, integration, security, and monitoring. A minor gap exists in not explicitly covering deployment or scaling operations, but agents can likely work around this given the comprehensive foundational coverage.
Average 2.6/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'executing code' which implies a potentially powerful/destructive operation, but provides no information about safety, permissions, side effects, rate limits, or execution environment. The description is insufficient for understanding the tool's behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that's appropriately brief, but it's not particularly well-structured or front-loaded with critical information. While concise, it doesn't efficiently communicate the tool's core purpose and value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a code execution tool (implied by 'executing code') with no annotations and an output schema (though unspecified), the description is inadequate. It doesn't explain what kind of code can be executed, what languages are supported, what the execution environment provides, or what the output might contain. For a potentially powerful tool like this, the description leaves too many questions unanswered.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of parameters. The description doesn't need to compensate for any parameter documentation gaps. The baseline for 0 parameters with complete schema coverage is 4, as there's no parameter semantics to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Documentation on AgentCore Code Interpreter for executing code in agents' is tautological - it essentially restates the tool name 'agentcore_code_interpreter' with minimal additional information. While it mentions 'executing code in agents', it doesn't specify what type of code, in what environment, or with what capabilities, making it vague rather than specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the six sibling tools (agentcore_gateway, agentcore_identity, etc.). There's no mention of appropriate contexts, prerequisites, or alternatives, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It hints at security functions ('secure agent authentication and authorization') but doesn't specify whether this is a read-only informational tool, a configuration tool, or something else. It lacks details on permissions needed, side effects, rate limits, or what the output contains, making it insufficient for a tool with potential security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is reasonably concise, but it's not front-loaded with the most critical information. It starts with 'Documentation on...' which is ambiguous—it could mean the tool provides documentation or is itself documented. While not wasteful, it could be more direct and structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'secure agent authentication and authorization' and the presence of an output schema (which suggests structured returns), the description is incomplete. It doesn't explain what the tool returns (e.g., identity tokens, user info, permissions) or how it integrates with siblings. With no annotations and a vague purpose, this leaves significant gaps for an agent to use it effectively.
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?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is given since the schema fully covers the absence of parameters, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Documentation on AgentCore Identity for secure agent authentication and authorization' is vague about what the tool actually does. It mentions a topic area (authentication/authorization) but doesn't specify a clear action verb or what resource it operates on. It's better than a tautology but doesn't clearly distinguish this tool from its siblings like agentcore_gateway or agentcore_tools which might also handle security aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of specific contexts, prerequisites, or comparisons with sibling tools like agentcore_gateway (which might handle routing) or agentcore_tools (which might manage tool access). This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It vaguely suggests 'monitoring and debugging' but does not disclose behavioral traits such as whether it's read-only, requires authentication, has side effects, or involves rate limits. The lack of specifics makes it inadequate for understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, but it is under-specified rather than efficiently informative. It front-loads the topic but fails to provide actionable details, making it less helpful. While not verbose, it lacks the density of useful information that would warrant a higher score.
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?
Given 0 parameters, 100% schema coverage, and an output schema, the description's minimal content is partially acceptable. However, for a tool with no annotations and siblings, it should clarify purpose and usage more. It is incomplete as it leaves key behavioral and contextual gaps, but the structured data reduces the burden slightly.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. A baseline of 4 is applied as it compensates for the lack of parameters by not introducing confusion, though it doesn't enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Documentation on AgentCore Observability for monitoring and debugging agents' restates the tool name with minimal elaboration. It mentions 'monitoring and debugging' but lacks a specific verb (e.g., 'retrieve', 'configure') and resource (e.g., 'logs', 'metrics'), making it vague. It does not differentiate from siblings like agentcore_tools or agentcore_gateway, which could also relate to agent operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, and there is no reference to sibling tools (e.g., agentcore_memory for memory-related tasks). This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The description mentions 'documentation' which suggests a read-only informational function, but doesn't clarify whether this is actually a configuration tool, a testing interface, or something else. No information about authentication needs, rate limits, side effects, or return format is provided beyond the vague 'documentation' reference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that's reasonably concise, but it's not particularly well-structured or front-loaded with the most critical information. While it doesn't waste words, it also doesn't efficiently communicate the tool's core function in a way that would help an AI agent quickly understand when to use it.
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?
Given that the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description doesn't need to explain parameters or return values. However, for a tool with no annotations and sibling alternatives, the description should do more to clarify the tool's specific role and behavioral characteristics. The current description is minimally adequate but leaves significant gaps about what the tool actually does.
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?
The tool has 0 parameters with 100% schema description coverage, so there are no parameters to document. The description doesn't need to compensate for any parameter documentation gaps. A baseline of 4 is appropriate since there are no parameters requiring semantic explanation in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Documentation on AgentCore Gateway for integrating external APIs and services' is vague about what the tool actually does. It mentions 'documentation' which could imply a read-only informational tool, but doesn't specify a clear action verb or what resource it operates on. It distinguishes somewhat from siblings by mentioning 'gateway' and 'integrating external APIs', but doesn't clearly state the tool's function.
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 guidance is provided about when to use this tool versus the sibling tools (agentcore_code_interpreter, agentcore_identity, etc.). The description mentions 'integrating external APIs and services' which implies a specific context, but doesn't explicitly state when this tool should be selected over alternatives or what prerequisites might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal insight. It doesn't reveal whether this is a read-only or mutative operation, what permissions might be required, or any side effects like rate limits or data persistence. The phrase 'Documentation on AgentCore Memory' suggests informational retrieval, but this is implied rather than explicitly stated, leaving behavioral traits ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise but under-specified. While it avoids unnecessary length, it fails to front-load critical information about the tool's function. The sentence 'Documentation on AgentCore Memory for building context-aware agents' is efficient but lacks substance, making it more of a placeholder than a helpful description.
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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's minimalism is somewhat acceptable. However, it still lacks clarity on purpose and usage, which are essential for agent decision-making. The presence of an output schema means return values are documented elsewhere, but the description should better explain what the tool does to complement that structured data.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Since there are no parameters to explain, it avoids redundancy and meets the baseline expectation for tools without inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Documentation on AgentCore Memory for building context-aware agents' is vague about what the tool actually does. It mentions the tool's domain (AgentCore Memory) and a high-level purpose (building context-aware agents), but lacks a specific verb-action-resource statement. It doesn't clearly state whether this tool retrieves, modifies, configures, or manages memory, making it difficult to distinguish from sibling tools like agentcore_observability or agentcore_tools.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any specific contexts, prerequisites, or exclusions for usage. While it hints at 'building context-aware agents,' it fails to specify scenarios where this tool is appropriate compared to siblings like agentcore_code_interpreter or agentcore_identity, leaving the agent without practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool provides documentation, implying a read-only operation, but fails to describe how the documentation is accessed, formatted, or any limitations (e.g., authentication needs, rate limits). This leaves significant gaps in understanding the tool's behavior.
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 description is a single, clear sentence that efficiently states the tool's purpose without redundancy. It is appropriately sized and front-loaded, with no wasted words, though it could be more specific to enhance clarity.
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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally complete. However, it lacks depth for a tool that provides documentation, such as explaining the format or scope of the documentation, which could help the agent use it effectively.
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?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description does not need to compensate for any parameter gaps, making it adequate in this dimension without adding unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides 'Documentation on integrating tools with AWS AgentCore agents,' which gives a general purpose but lacks specificity. It doesn't clearly distinguish this from sibling tools like agentcore_code_interpreter or agentcore_gateway, making it vague about what unique function it serves.
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 guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent with no information on appropriate usage scenarios among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool provides documentation but doesn't specify whether this is read-only, if it requires authentication, how it retrieves or displays the documentation, or what format the documentation takes. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence that states exactly what the tool does without unnecessary words. It's appropriately sized for a zero-parameter documentation tool and front-loads the essential information. Every word earns its place.
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?
Given the tool's simplicity (0 parameters, 100% schema coverage, output schema exists), the description is reasonably complete. The existence of an output schema means the description doesn't need to explain return values. However, for a documentation tool with no annotations, it could benefit from specifying the documentation format or access method to be fully complete.
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?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema fully documents this absence. No additional parameter information is needed or provided.
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 clearly states the tool provides 'Quickstart documentation for AWS AgentCore SDK' - a specific resource (documentation) with a clear purpose (getting started). It distinguishes from siblings by focusing on documentation rather than functional components like code interpretation or identity management. However, it doesn't specify the exact format or delivery method of this documentation.
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?
The description provides no guidance on when to use this tool versus alternatives. There's no indication of prerequisites, timing considerations, or comparison to other documentation tools. The agent must infer usage from the tool name and description alone without explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agentcore-mcp-server MCP server](https://glama.ai/mcp/servers/weiwarren/agentcore-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/weiwarren/agentcore-mcp-server)

Score Badge

Copy to your README.md:

[![agentcore-mcp-server MCP server](https://glama.ai/mcp/servers/weiwarren/agentcore-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/weiwarren/agentcore-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/weiwarren/agentcore-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server