Skip to main content
Glama

generic_aap_api

Access any AAP Controller API endpoint directly with proper authentication to manage jobs, inventories, workflows, and system resources through HTTP methods.

Instructions

Generic AAP Controller API access tool. Provides direct access to any AAP Controller API endpoint with proper authentication.

Examples:

  • GET /jobs/: method="GET", endpoint="jobs/"

  • GET /inventories/2/hosts/: method="GET", endpoint="inventories/2/hosts/"

  • POST /job_templates/5/launch/: method="POST", endpoint="job_templates/5/launch/", data={"extra_vars": {"var1": "value1"}}

  • GET /analytics/job_explorer/: method="GET", endpoint="analytics/job_explorer/", params={"period": "month"}

  • GET /jobs/123/stdout/: method="GET", endpoint="jobs/123/stdout/", get_stdout=true

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodYesHTTP method: GET, POST, PATCH, DELETE
endpointYesAPI endpoint path (e.g., 'analytics/job_explorer/', 'jobs/', 'inventories/1/')
dataNoRequest body data for POST/PATCH requests
paramsNoQuery parameters for GET requests
get_stdoutNoUse stdout format for job/adhoc output endpoints

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

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 'proper authentication' which is useful context, but doesn't describe rate limits, error handling, response formats, or what happens with destructive operations (DELETE/PATCH). The examples show different use cases but don't explain behavioral traits like whether operations are idempotent, reversible, or have 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with a clear opening statement followed by relevant examples. Each example demonstrates a different parameter combination, earning its place. However, the examples could be more efficiently grouped or explained with brief commentary rather than just listing them.

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's complexity (generic API access with 5 parameters), no annotations, but with output schema present, the description is moderately complete. It covers basic purpose and provides examples, but lacks important context about authentication details, error handling, and when to use this versus specialized tools. The presence of an output schema means return values are documented elsewhere, but behavioral aspects remain underspecified.

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?

With 100% schema description coverage, the baseline is 3. The description adds value through concrete examples showing how parameters work together: method+endpoint combinations, when to use data vs params, and the specific use case for get_stdout. The examples provide practical semantics beyond the schema's technical descriptions, though they don't cover all parameter combinations.

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 'direct access to any AAP Controller API endpoint with proper authentication', which is a specific verb+resource combination. It distinguishes itself from sibling tools by being a generic API access tool rather than specialized management tools like 'job_execution_management' or 'inventory_host_management'. However, it doesn't explicitly contrast with 'gateway_generic_api' which appears similar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage through examples showing when to use different parameters (GET with params, POST with data, etc.), but doesn't provide explicit guidance on when to choose this generic tool versus the many specialized sibling tools. It mentions 'proper authentication' as a prerequisite but doesn't explain authentication requirements or when to use alternatives like 'gateway_generic_api'.

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

Install Server

Other Tools

Latest Blog Posts

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/anshulbehl/aap-mcp-pilot'

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