Skip to main content
Glama
Atlasent

atlasent-mcp

Official
by Atlasent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Lookup Canonical Action Spec

atlasent_lookup_action
Read-only

Find the canonical specification for any governed action using its slug or a plain-language query, returning authorization patterns, risk flags, and regulatory mappings.

Instructions

Look up canonical action specifications from the Authorization Intelligence Library. Returns the permanent canon_id, gate flags (requires_human_approval, requires_mfa, requires_verified_actor, requires_state_snapshot), authorization pattern, risk posture, AI risk classification, regulatory mappings, evidence requirements, and the action's knowledge-graph relationships (what it requires and produces, and which frameworks / control objectives it satisfies) for every governed action type in the Canon. Use slug for an exact match (e.g. 'production.deploy') or query to describe what you want to do in plain language (e.g. 'deploy the api service to prod', 'grant admin access', 'close the books'). query is ranked offline against the vendored Canon and returns a retrieval block with confidence = confident | ambiguous | none — act only on confident; the tool never invents an action type, and a none result means the Canon has no such action (see the hint). Omit both to list the full Canon.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugNoExact canonical action slug (e.g. 'production.deploy', 'access.grant').
queryNoPlain-language description of the action to find. Ranked deterministically (offline, no network) over slug, display name, family, description and a curated alias vocabulary.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.12.2
    • changedInput schema / properties / query / description
      Previous value: -"Substring search across slug, display_name, and description. Case-insensitive."New value: +"Plain-language description of the action to find. Ranked deterministically (offline, no network) over slug, display name, family, description and a curated alias vocabulary."
  2. First observedv2.11.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it discloses that query ranking is performed offline, that it returns a retrieval block with confidence levels (confident/ambiguous/none), and that the tool never invents action types. This goes beyond the annotations and helps the agent understand edge cases. It doesn't fully detail the return format but provides sufficient context.

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 dense but well-organized, front-loading the purpose and then systematically covering parameters, confidence handling, and the full-canon listing. Every sentence contributes new information without redundancy. While it is long, the length is justified given the tool's complexity and the absence of an output schema. It could be slightly more concise, but it earns a 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a lookup tool with no output schema and two optional parameters, the description is remarkably complete. It enumerates all the returned fields (canon_id, gate flags, authorization pattern, risk posture, AI risk classification, regulatory mappings, evidence requirements, knowledge-graph relationships), explains the retrieval confidence mechanism, and covers the edge case of 'none' results. An agent has everything needed to decide when to call and what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100% (both parameters have descriptions), the tool description adds substantial meaning beyond the schema. It explains the difference between slug (exact match) and query (plain-language, ranked deterministically), provides concrete examples for each, and describes the behavior of query ranking (offline, over slug, display name, family, etc.). This significantly enhances the agent's ability to use the parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool looks up canonical action specifications from the Authorization Intelligence Library, and enumerates the specific fields returned (canon_id, gate flags, authorization pattern, risk posture, etc.). This is a specific verb-resource combination that clearly distinguishes it from sibling tools like atlasent_list_policies (which manage policies) or atlasent_explain_authority (which explains authority). The purpose is unambiguous and detailed.

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?

The description gives clear usage guidance on how to invoke the tool: use 'slug' for exact match, 'query' for plain-language description, or omit both to list the full Canon. It also instructs the agent to act only on 'confident' retrieval confidence and explains the meaning of 'none' results. However, it does not explicitly name alternative tools or state when NOT to use this tool versus siblings, though the purpose clarity makes that largely implicit.

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