Provides tools for interacting with Apache Atlas, a metadata governance platform, enabling AI agents to search data assets, trace lineage, browse glossaries, inspect types, and manage classifications (with write mode enabled).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@apache-atlas-mcp Search for all Hive tables related to sales"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A community-built MCP (Model Context Protocol) server that connects LLM agents to Apache Atlas metadata governance platform. Not affiliated with the Apache Software Foundation.
Read-only by default. Write operations (create/delete entities, manage classifications) require explicit opt-in via --write flag or ATLAS_ALLOW_WRITE=true.
Apache Atlas is a widely-used open-source metadata governance framework for Hadoop ecosystems and beyond. With the 2.4.0 release (Jan 2025) breaking a 2-year gap and 2.5.0 (RC) adding PostgreSQL backend support and Trino extractor, Atlas is seeing renewed activity.
This MCP server lets AI agents:
Search data assets across your entire metadata catalog
Trace lineage — understand how data flows from source to destination
Browse glossaries — look up business terms and definitions
Inspect types — understand the metadata schema structure
Manage classifications — apply governance tags like PII, GDPR, Confidential (write mode)
Create/delete entities — modify metadata catalog (write mode)
Related MCP server: VAST DB MCP Server
# Using uv (recommended)
uv add apache-atlas-mcp
# Using pip
pip install apache-atlas-mcp
# Run without installing
uvx apache-atlas-mcpSet environment variables to connect to your Atlas instance:
export ATLAS_BASE_URL=http://your-atlas-server:21000
export ATLAS_USERNAME=your-username
export ATLAS_PASSWORD=your-passwordAll configuration options:
Variable | Default | Description |
| (required) | Atlas server URL (e.g., |
| (required) | Authentication username |
| (required) | Authentication password |
|
| Verify SSL certificates |
|
| HTTP request timeout (seconds) |
|
| Enable write operations (create, delete, classify) |
Add to your claude_desktop_config.json:
{
"mcpServers": {
"apache-atlas": {
"command": "uvx",
"args": ["apache-atlas-mcp"],
"env": {
"ATLAS_BASE_URL": "http://your-atlas-server:21000",
"ATLAS_USERNAME": "your-username",
"ATLAS_PASSWORD": "your-password"
}
}
}
}To enable write operations:
{
"mcpServers": {
"apache-atlas": {
"command": "uvx",
"args": ["apache-atlas-mcp", "--write"],
"env": {
"ATLAS_BASE_URL": "http://your-atlas-server:21000",
"ATLAS_USERNAME": "your-username",
"ATLAS_PASSWORD": "your-password"
}
}
}
}# Read-only (default)
claude mcp add atlas-server -- uvx apache-atlas-mcp
# With write operations enabled
claude mcp add atlas-server -- uvx apache-atlas-mcp --write# Read-only (default)
apache-atlas-mcp
# With write operations enabled
apache-atlas-mcp --writeTool | Description |
| Basic search by keyword, type, or classification |
| Advanced search using Atlas DSL query language |
| Fast partial-match search (autocomplete-style) |
| Get full entity details by GUID |
| Get entity by unique attribute (e.g., qualifiedName) |
| Fetch multiple entities by GUIDs |
Tool | Description |
| Trace upstream/downstream data flow by GUID |
| Trace lineage by unique attribute |
Tool | Description |
| List all classifications on an entity |
Tool | Description |
| List all business glossaries |
| Get glossary details with terms and categories |
| List terms in a glossary |
| Get full details of a glossary term |
Tool | Description |
| Get the complete Atlas type system |
| Get a specific type definition by name |
| Get an entity type with all attributes |
--write or ATLAS_ALLOW_WRITE=true)Tool | Description |
| Create or update an entity |
| Soft-delete an entity |
| Apply a classification tag (with lineage propagation) |
| Remove a classification from an entity |
LLM Agent <--> MCP Protocol <--> Apache Atlas MCP Server <--> Atlas REST API v2
|
FastMCP + httpx
|
Apache Atlas Instance
(HBase / PostgreSQL backend)The server wraps the Atlas REST API v2 using:
FastMCP for MCP protocol handling
httpx for async HTTP communication
Pydantic V2 for data validation and serialization
The REST API is backend-independent — it works regardless of whether Atlas uses HBase, Cassandra, or the new PostgreSQL backend (Atlas 2.5.0+).
Apache Atlas: 2.1.0+ (tested with 2.3.2 and 2.4.0)
Python: 3.11+
Authentication: HTTP Basic (Atlas file-based auth, LDAP, or AD — all use Basic HTTP headers)
# Clone the repository
git clone https://github.com/DanMeon/apache-atlas-mcp.git
cd apache-atlas-mcp
# Install dependencies
uv sync --group dev
# Run tests
uv run pytest tests/ -v --cov
# Lint & type check
uv run ruff check src/ tests/
uv run pyright src/apache_atlas_mcp/MIT
Execute an Atlas DSL (Domain Specific Language) search query.
Atlas DSL supports structured queries with type filters, attribute conditions, and aggregations. Useful for complex, precise queries.
Example DSL queries:
"hive_table where name = 'customers'"
"hive_column where table.name = 'orders'"
"DataSet where owner = 'analytics_team'"
Args: query: Atlas DSL query string. limit: Maximum number of results (default: 25). offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose whether the tool is read-only, requires authentication, or has performance implications. It only describes pagination via limit and offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the purpose, explains DSL briefly, gives examples, and defines parameters. Every sentence is informative and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the query syntax with examples and parameter details. An output schema exists, so return values are not needed. However, error handling or performance considerations are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description includes an 'Args' section that explains each parameter, their defaults, and meaning (e.g., 'query: Atlas DSL query string'). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute an Atlas DSL search query.' It explains that DSL supports structured queries with type filters, attribute conditions, and aggregations, and provides example queries. This distinguishes it from sibling tools like quick_search and search_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says the tool is 'Useful for complex, precise queries,' implying when to use it. However, it does not explicitly exclude use cases or compare with alternatives, so some guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all type definitions from Atlas.
Returns the complete type system including entity types, classification types, relationship types, enum types, and struct types. This is useful for understanding the metadata schema structure.
Warning: This can return a large response. Consider using get_type_definition for specific types instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears full responsibility for behavioral disclosure. It warns about potentially large responses, which is a key behavioral trait. However, it does not mention other aspects like authentication requirements, rate limits, or whether the data is live or cached. Nonetheless, for a simple read-only list operation, the warning suffices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two clear paragraphs. The first paragraph states the purpose and contents, the second provides usage guidance and a warning. It is front-loaded with the primary information. Minor improvement could be merging into a more streamlined single paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and includes an output schema (not shown but indicated), the description adequately covers what the tool returns (the complete type system). It is complete for the tool's simplicity and context signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because none is needed. Schema coverage is 100% automatically, so no compensation required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get all type definitions from Atlas' and enumerates the specific type categories (entity types, classification types, etc.), making the tool's purpose very clear. It distinguishes itself from the sibling tool 'get_type_definition' which is for specific types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it states the tool is useful for understanding the metadata schema structure, and warns about large responses while suggesting the alternative 'get_type_definition' for specific types. This helps the agent decide when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all classifications (tags) applied to an entity.
Classifications are used for data governance — e.g., PII, Confidential, HIPAA, GDPR tags that indicate sensitivity or compliance requirements.
Args: guid: The GUID of the entity.
| Name | Required | Description | Default |
|---|---|---|---|
| guid | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by stating 'Get all classifications,' which is clear. No annotations provided, so the description carries full burden and adequately discloses the basic behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loads the purpose, and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking usage guidelines, the description covers the essential purpose and parameter adequately, and an output schema exists to explain return values, making it sufficiently complete for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning by explaining 'guid' as the entity's GUID, compensating for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all classifications (tags) for an entity, with specific examples like PII and HIPAA, distinguishing it from sibling tools that search or retrieve other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; usage is implied by the specific purpose, but no exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get multiple entities by their GUIDs in a single request.
Efficient way to fetch details for several entities at once, e.g., after collecting GUIDs from a search or lineage query.
Args: guids: List of entity GUIDs to retrieve (max 25).
| Name | Required | Description | Default |
|---|---|---|---|
| guids | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds bulk behavior and max 25 limit, but lacks error handling, authentication, or partial result behavior. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded purpose, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need no explanation. Description covers input adequately. For a bulk retrieval tool, it's nearly complete; only missing minor details like response format hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning: 'List of entity GUIDs to retrieve (max 25)'. Compensates for lack of schema descriptions, though minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb and resource: 'Get multiple entities by their GUIDs'. Distinguishes from sibling 'get_entity' by emphasizing bulk operation. Scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use: after collecting GUIDs from search/lineage. Implies not for single entity, but no explicit when-not-to-use or alternative names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of an entity by its GUID.
Returns the complete entity with all attributes, classifications, relationship attributes, and optionally referred entities.
Args: guid: The unique identifier (GUID) of the entity. min_ext_info: If true, returns minimal info for referred entities. ignore_relationships: If true, omits relationship attributes.
| Name | Required | Description | Default |
|---|---|---|---|
| guid | Yes | ||
| min_ext_info | No | ||
| ignore_relationships | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the output (complete entity with attributes, classifications, etc.) but does not explicitly state that the tool is read-only or mention any side effects. No annotations are present to provide this context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose and uses a structured Args list. It is slightly verbose but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the detailed description of return content, the description is mostly complete. However, it lacks context on when to choose this tool over siblings in a large toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all three parameters: guid, min_ext_info, and ignore_relationships, adding meaning beyond the schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full details of an entity by its GUID' with a specific verb and resource. It distinguishes from siblings like 'get_entities_bulk' by focusing on a single entity, but it does not explicitly differentiate from other 'get' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'search_entities' or 'get_entities_bulk'. The description lacks context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an entity by its unique attribute value.
Useful when you know the qualified name or another unique attribute instead of the GUID. Common pattern: look up by qualifiedName.
Args: type_name: The entity type (e.g., "hive_table", "rdbms_table"). attribute_name: Unique attribute name (typically "qualifiedName"). attribute_value: The attribute value to match.
| Name | Required | Description | Default |
|---|---|---|---|
| type_name | Yes | ||
| attribute_name | Yes | ||
| attribute_value | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only operation but doesn't state behavioral traits (e.g., idempotent). Adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences plus labeled parameter list. No fluff, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers usage pattern and parameter semantics adequately. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaningful explanations for each parameter, including type examples and typical usage (qualifiedName). This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('entity'), and the method ('by unique attribute value'). It distinguishes from sibling tools like get_entity (which uses GUID) and search functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when you know qualifiedName or other unique attribute instead of GUID. Mentions common pattern, but lacks explicit when-not-to-use or alternative tools beyond context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an entity type definition by name.
Returns the entity type definition with all attribute definitions, super types, sub types, and relationship attribute definitions.
Args: name: The entity type name (e.g., "hive_table", "hive_db", "rdbms_table").
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the return value structure (attribute definitions, super types, sub types, relationship attributes) but does not address behavioral traits like idempotency, authentication needs, or rate limits. Since no annotations are provided, the description carries the full burden, which is partially fulfilled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences and an 'Args' line. Information is front-loaded and every sentence adds value. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema (so return format is covered elsewhere), the description provides adequate context for the tool's operation and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial meaning to the 'name' parameter by providing examples (e.g., 'hive_table', 'hive_db') and indicating it is the entity type name. This significantly compensates for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get an entity type definition by name' and specifies the resource. However, it does not explicitly differentiate from the sibling tool 'get_type_definition', leaving potential ambiguity about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_all_type_definitions, get_type_definition). Does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a glossary by its GUID, including its terms and categories.
Args: glossary_guid: The GUID of the glossary.
| Name | Required | Description | Default |
|---|---|---|---|
| glossary_guid | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds that it includes terms and categories, but lacks details on pagination, depth, or permissions. Output schema exists for return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences, includes args, no wasted words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and an output schema, the description is sufficient. Tells what is returned (terms and categories). Siblings are many but no additional context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains that 'glossary_guid' is a GUID, adding meaning beyond the bare schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', resource 'glossary by its GUID', and includes 'terms and categories'. Distinguishes from sibling tools like 'list_glossaries' and 'get_glossary_term'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates use when a specific glossary GUID is known and full details are needed, but does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a glossary term by its GUID.
Returns the full term including definition, linked entities, related terms (seeAlso), and category assignments.
Args: term_guid: The GUID of the glossary term.
| Name | Required | Description | Default |
|---|---|---|---|
| term_guid | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists returned fields but does not mention errors, permissions, or side effects. Adequate for a simple read, but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus parameter definition. Front-loaded with action and return list. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get with one parameter and an output schema, the description covers input and return content. Lacks error handling details, but overall sufficient. Lacks sibling comparison.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds 'The GUID of the glossary term' to the parameter. Provides basic semantics but lacks format or example detail. Baseline adjusted upward slightly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a glossary term by its GUID' with a specific verb and resource, and distinguishes from siblings like 'get_glossary_terms' by indicating single-term retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (when you have a GUID), but no explicit comparison to alternatives or exclusion criteria. Lacks guidance on when to prefer this over search or get_glossary_terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List terms in a specific glossary.
Returns business terms with their definitions, linked entities, and category assignments.
Args: glossary_guid: The GUID of the glossary. limit: Maximum number of terms to return. offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| glossary_guid | Yes | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions return type but does not disclose behavioral traits such as pagination behavior, sorting, or whether it is read-only. The defaults for limit and offset are only in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with one sentence for purpose, one for returns, and a structured argument list. It is front-loaded with the action. Could be slightly more structured, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description need not detail return values. It covers parameters well and mentions key return components. Missing context about ordering or limits, but overall adequate for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear explanations for all three parameters: glossary_guid (GUID of the glossary), limit (max terms), and offset (pagination offset). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List terms in a specific glossary' and specifies the return content (business terms with definitions, linked entities, category assignments). It effectively distinguishes from sibling tools like 'get_glossary_term' (single term) and 'list_glossaries' (lists glossaries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use (to list terms in a specific glossary) and implies the prerequisite of having a glossary GUID. However, it does not explicitly state when not to use or mention alternatives, though sibling tool names provide some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the data lineage graph for an entity.
Traces upstream (INPUT) and/or downstream (OUTPUT) data flow relationships. This is the most valuable tool for understanding how data moves through your system.
The response includes:
guidEntityMap: All entities in the lineage graph
relations: Directed edges showing data flow
Args: guid: The GUID of the entity to trace lineage for. direction: "INPUT" (upstream), "OUTPUT" (downstream), or "BOTH". depth: How many hops to traverse (default: 3, max: 10).
| Name | Required | Description | Default |
|---|---|---|---|
| guid | Yes | ||
| direction | No | BOTH | |
| depth | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the response structure (guidEntityMap, relations), parameter options, and defaults. It does not mention permissions or side effects, which is acceptable for a read-only operation implied by 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized and front-loaded with purpose. It includes a blank line and parameter list, but the section 'This is the most valuable tool...' could be integrated to be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, an output schema (even though not provided in the evaluation), and no annotations, the description fully explains what the tool does, its parameters, and the response structure. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must define parameters. It provides clear descriptions for `guid`, `direction` (with enum values), and `depth` (with default and max). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the data lineage graph for an entity' with a specific verb and resource, and explains it traces upstream/downstream data flow. It distinguishes itself from siblings like `get_lineage_by_attribute` by focusing on GUID-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding data flow and calls it 'the most valuable tool.' However, it does not explicitly state when to use alternatives like `get_lineage_by_attribute` or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get lineage for an entity identified by a unique attribute.
Same as get_lineage but uses a unique attribute (like qualifiedName) instead of a GUID. Convenient when you know the entity's name but not its GUID.
Args: type_name: Entity type (e.g., "hive_table"). attribute_name: Unique attribute name (typically "qualifiedName"). attribute_value: The attribute value to match. direction: "INPUT" (upstream), "OUTPUT" (downstream), or "BOTH". depth: How many hops to traverse (default: 3, max: 10).
| Name | Required | Description | Default |
|---|---|---|---|
| type_name | Yes | ||
| attribute_name | Yes | ||
| attribute_value | Yes | ||
| direction | No | BOTH | |
| depth | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes parameter behavior (defaults, max depth) but does not state that the operation is read-only or other potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a one-sentence purpose, a brief comparison with sibling tool, and a clear parameter list. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown), the description fully explains the tool's purpose, parameter semantics, and relationship to sibling tools. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter in detail, including direction enum values and depth default/max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get lineage for an entity identified by a unique attribute' and distinguishes itself from get_lineage by specifying it uses an attribute instead of a GUID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Same as get_lineage but uses a unique attribute... Convenient when you know the entity's name but not its GUID,' providing clear when-to-use context. No exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific type definition by name.
Returns the full type definition including attributes, super types, and constraints. Useful for understanding what attributes an entity type has.
Args: name: The type name (e.g., "hive_table", "rdbms_column", "PII").
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return content includes 'attributes, super types, and constraints'. No annotations exist; description partially covers behaviors but lacks details on effects, auth requirements, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences plus an Args line. No redundancy, each sentence adds value: purpose, content, usefulness. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, output schema exists), the description sufficiently covers purpose, usage, and parameter detail. The output schema handles return structure, so no further explanation needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'name' is clarified with examples and a description in the Args section, adding meaning beyond the schema. Schema has 0% description coverage, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get a specific type definition by name', with examples like 'hive_table'. Differentiates from sibling 'get_all_type_definitions' by specifying 'specific' and from 'get_entity_type_definition' by using 'type definition' instead of 'entity type definition'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context 'Useful for understanding what attributes an entity type has', implying when to use. Does not explicitly state when not to use or mention alternatives like 'get_entity_type_definition'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all business glossaries.
Glossaries organize business terms and definitions, providing a shared vocabulary for data assets across the organization.
Args: limit: Maximum number of glossaries to return. offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It explains the tool lists glossaries but lacks details on authentication, rate limits, or empty results. It minimally describes the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes a helpful introductory sentence about glossaries. However, it could be more structured by separating parameter details into a clearer section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists to describe return values, the description adequately explains the tool's purpose and the meaning of glossaries. It is sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes 'Args' for limit and offset, but these merely restate the parameter names from the schema with no additional context like allowed ranges or behavior. Schema coverage is 0%, so the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all business glossaries,' specifying the verb and resource. It distinguishes from sibling tools like 'get_glossary' which targets a single glossary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for listing all glossaries, but does not explicitly state when to use it versus related tools like 'get_glossary' or 'search_entities'. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a quick search across all entity types.
Faster than basic search, optimized for autocomplete-style lookups. Good for finding entities when you have a partial name.
Args: query: Search text (supports partial matching). type_name: Optional type filter (e.g., "hive_table"). limit: Maximum number of results (default: 25).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| type_name | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only mentions speed and partial matching, but fails to disclose any behavioral traits like whether the operation is read-only, destructive, or requires authentication. No mention of side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: one-line purpose, one sentence for use case, then bulleted parameter descriptions. Front-loaded with essential info, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema (signal indicates true), so return value details are covered. Description covers basic functionality, parameter semantics, and use case. Lacks info on sorting or pagination, but acceptable for a quick search tool given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description includes an Args section that explains each parameter: query (supports partial matching), type_name (optional type filter), limit (default 25). This adds meaningful context beyond the raw schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Perform a quick search across all entity types' and adds 'Faster than basic search, optimized for autocomplete-style lookups.' This distinguishes it from sibling tools like search_entities or dsl_search by emphasizing speed and partial matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Faster than basic search' and 'optimized for autocomplete-style lookups' and 'Good for finding entities when you have a partial name.' It implies when to use vs a basic search, but doesn't name specific sibling alternatives. Clear enough for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for entities in Apache Atlas using basic search.
Finds data assets (tables, columns, processes, etc.) by keyword, type, or classification. Returns matching entity headers with key attributes.
Args: query: Free-text search query (e.g., "customer_orders"). type_name: Filter by entity type (e.g., "hive_table", "rdbms_table"). classification: Filter by classification tag (e.g., "PII", "Confidential"). limit: Maximum number of results (default: 25, max: 100). offset: Pagination offset.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| type_name | No | ||
| classification | No | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns 'matching entity headers with key attributes' and includes defaults and limits, but omits behavioral traits like read-only nature, authorization requirements, or response structure beyond headers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise summary followed by an Args list. Each sentence provides essential information without redundancy. The summary could be slightly more compact, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and parameters adequately but lacks usage guidance and behavioral context (e.g., read-only, pagination behavior). An output schema exists, so return value details are not needed, but the absence of when-to-use advice reduces completeness given the many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial meaning to each parameter. It explains query as free-text, type_name with examples (e.g., 'hive_table'), classification with tag examples (e.g., 'PII'), and explicitly states limit max (100) and offset for pagination. This compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for entities in Apache Atlas using basic search, listing the resource types (tables, columns, processes, etc.) and criteria (keyword, type, classification). However, it does not explicitly differentiate from sibling tools like dsl_search or quick_search, missing a clear contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter details but no guidance on when to use this tool versus alternatives. It says 'basic search' but doesn't specify when to use dsl_search (likely more advanced) or quick_search. Agents lack context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1dsl_searchget_all_type_definitionsget_classificationsget_entities_bulkget_entityget_entity_by_attributeget_entity_type_definitionget_glossaryget_glossary_termget_glossary_termsget_lineageget_lineage_by_attributeget_type_definitionlist_glossariesquick_searchsearch_entitiesEach tool has a clearly distinct purpose: search (dsl, quick, basic), entity retrieval, lineage, type definitions, glossaries, and classifications. No overlap in functionality.
Tool names follow a consistent verb_noun pattern with underscores (get_, list_, search_, quick_search). All names are descriptive and predictable.
With 16 tools, the server covers the main facets of Apache Atlas metadata management without being bloated or sparse. Each tool serves a distinct need.
The tool set is comprehensive for metadata discovery: search, retrieval, lineage, type definitions, glossaries, and classifications. However, it lacks write operations (create, update, delete) for entities, classifications, and glossaries, which limits full lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Connect AI clients to biomedical data and tools.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
The grounded data layer for any LLM: governed SQL, metrics, lineage and catalog over your data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DanMeon/apache-atlas-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
