Skip to main content
Glama
borgels

mcp-server-lager

by borgels

Hvem er jeg

lager_me
Read-onlyIdempotent

Retrieve your profile, account, warehouse roles, and per-warehouse item counts.

Instructions

Person, konto, lagre med roller (vaerktoejsbruger/lageransvarlig) og tal pr. lager.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered externally. The description adds only the data categories returned (roles, per-warehouse counts); it says nothing about auth requirements or what the role values imply. A 3 is appropriate with annotations carrying the safety burden.

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?

A single short sentence with no wasted words, front-loaded with the resource list. It is somewhat under-specified as a fragment rather than a full statement, but nothing is padded.

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 zero-argument read-only tool with no output schema, the description does list the returned data categories (identity, account, warehouses/roles, counts), which is the main thing an agent needs to plan around it. It could be more explicit that this targets the authenticated user and what 'tal' counts refer to, but it is largely complete.

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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No syntax or filtering concerns exist for this call.

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 enumerates the resources surfaced (person, account, warehouses with roles, and per-warehouse counts), which lets an agent distinguish this identity/context tool from the transaction-oriented siblings like lager_bookinger or lager_bestil. It lacks an explicit verb ('returns the current user's...'), but the resource scope is specific and unambiguous.

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 when-to-use guidance, no prerequisites, and no alternatives named (e.g., lager_search_capabilities or lager_mine, which look closely related). The agent must infer that this is a context-priming call from the title alone.

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