Skip to main content
Glama

LC Mods

mod_info

Read-onlyIdempotent

Public mod details and an agent page with LC Mod Installer setup and install command.

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that the response includes an 'agent page' with LC Mod Installer setup and an install command, which is genuine behavioral context beyond the annotations. It still says nothing about behavior for invalid or missing ids, or about external dependencies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

It is a single tight sentence with no waste, which is good, but the noun-phrase construction and the vague phrase 'an agent page' make it less front-loaded than a clear verb-first statement of purpose would be.

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

Completeness2/5

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

There is no output schema, so the description carries full responsibility for describing return values, and it only vaguely gestures at 'details' plus an 'agent page'. Combined with zero parameter documentation, an agent lacks enough information to call this confidently versus its siblings.

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

Parameters2/5

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

Schema description coverage is 0% and the single parameter 'id' is undocumented in both schema and description. The description never states that 'id' is a mod identifier or what its form is, so an agent must infer this from the tool name alone.

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

Purpose3/5

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

The description names the resource (a mod's public details) and an additional payload (an agent page with LC Mod Installer setup/install command), which tells an agent roughly what comes back. However, it is a noun phrase with no verb, and it never distinguishes itself from the sibling search_mods or collections, so the agent must infer that this is a single-mod lookup by id.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as search_mods for finding mods or how_to_install for installation help. Usage is only vaguely implied by the phrase 'mod details'.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources