Skip to main content
Glama

Agentry — The Trust Layer for the Agent Economy

by io.github.cthulhutoo

get_agent_api_agents__agent_id__get

Get Agent

Get full details for a specific AI agent by ID.

Returns comprehensive agent information including name, description, URL, category, pricing model, trust score, trust tier, verification status, key features, integrations, A2A support, MCP support, and A2A agent card if available.

Responses:

200: Successful Response (Success Response) Content-Type: application/json

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_idYesThe unique agent identifier, e.g. 'agent-0001'. Found in search/list results.

TDQS

A3.5/5.0
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 'Returns comprehensive agent information' but does not state that it is read-only, any authentication requirements, rate limits, or error behavior (e.g., what happens with an invalid ID). The 'Responses: 200' section is minimal and lacks error cases.

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 well-structured and appropriately sized. It front-loads the purpose, then lists the comprehensive fields returned, and ends with a minimal response section. No unnecessary fluff; the field list is informative and 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?

For a simple single-parameter GET tool with no output schema, the description lists the return fields comprehensively, which covers the expected response content. However, it omits potential error responses (e.g., 404) and any pagination or edge-case behavior, leaving a small gap in completeness.

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

Parameters3/5

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

The input schema covers 100% of parameters with a clear description for agent_id (unique identifier, example, source). The description's phrase 'by ID' adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.

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 clearly states 'Get full details for a specific AI agent by ID', specifying the verb and resource. The list of returned fields (trust score, verification status, etc.) differentiates it from siblings like get_agent_trust or discover_single_agent, making it the comprehensive 'get agent' endpoint.

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 for retrieving full agent details but does not explicitly mention when to use this versus alternatives (e.g., for trust-specific info, use get_agent_trust). It provides no exclusions or alternative tool guidance.

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

All Agentry — The Trust Layer for the Agent Economy toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.3/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, with descriptions that differentiate related operations like discovery vs. scanning or mint vs. melt quotes. A few pairs (e.g., list_agents vs. a2a_public_discovery, get_agent vs. discover_single_agent) could cause confusion, but the endpoint paths and descriptions mitigate this.

Naming Consistency5/5

All tool names follow a consistent pattern: a descriptive operation prefix followed by the full API path and HTTP method (e.g., list_agents_api_agents_get, create_melt_quote_api_payments_ecash_melt_quote_post). No mixed casing or inconsistent verb styles.

Tool Count2/5

With 36 tools, the server is overloaded. Even though it covers multiple domains (directory, trust, discovery, payments), the count exceeds the 25+ threshold and likely should be split into focused sub-servers. The tool set feels sprawling rather than well-scoped.

Completeness4/5

The core workflows for agent registration, search, trust, A2A discovery, scanning, and ecash payments are well-covered. Minor gaps exist, such as no update or delete agent operations and no way to modify agent details post-registration, but these are not critical dead-ends for the platform's purpose.

Resources