get
Retrieve a single entity by its unique ID, returning a short-form result for lightweight queries.
Instructions
Get single entity by ID (short form in light mode)
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| isShort | No | ||
| resource | Yes |
Retrieve a single entity by its unique ID, returning a short-form result for lightweight queries.
Get single entity by ID (short form in light mode)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| isShort | No | ||
| resource | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the behavioral burden. It only mentions 'short form in light mode', which hints at an abbreviated representation but does not explain side effects, return format, authentication, errors, or what 'light mode' means. This is insufficient for a tool with no annotation support.
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 a single sentence with no redundant filler and the core action is front-loaded. The phrase 'in light mode' is somewhat unclear but does not add bloat, so conciseness is good.
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 tool with no annotations, no output schema, and unexplained parameters, this description is incomplete. It does not explain how 'resource' is used, what 'isShort' really controls, when to prefer this over sibling tools, or what the response looks like. The genericness leaves an agent guessing.
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%, so the description must compensate. It clarifies 'id' as the lookup key and loosely hints at 'isShort' through 'short form', but it completely ignores the 'resource' parameter, leaving ambiguity about what entity types are supported.
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 'Get single entity by ID' clearly states the operation: retrieving exactly one entity using an identifier. It distinguishes from list by emphasizing 'single', though 'entity' is generic and does not differentiate between get vs get_priority or get_priorities.
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 it should be used when fetching a single entity by ID, in contrast to list operations. However, it does not explicitly mention alternatives or provide criteria for choosing between this and sibling tools like get_priority or get_term_types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AdminRHS/libs-mcp-service'
If you have feedback or need assistance with the MCP directory API, please join our Discord server