Server Quality Checklist

Tool Scores

• lager_bestilling_hentC
  2.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation-but-not-destructive profile is covered. The description adds genuinely non-obvious context: the withdrawal is charged to a case while stock is left untouched, which an agent would otherwise assume wrongly for a warehouse-order pickup. It still omits what order state changes and whether the call is repeatable (idempotentHint=false is not explained).

  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?

  One short, front-loaded sentence with no padding, which is structurally fine. However, the brevity reflects under-specification rather than disciplined conciseness, so it earns only a middling score.

  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?

  For a mutating tool with a required identifier, no output schema, and annotations covering only safety flags, the description leaves the operation's purpose, the meaning of the ID, the resulting state change, and repeat-call behavior undocumented. What is present (case-charging vs. stock) is useful but far from sufficient.

  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% for the single required parameter bestillingId, and the description never identifies or defines it. It refers obliquely to 'sagen' (the case) and 'beholdningen' (stock), which are not parameters at all, so it does not compensate for the documentation gap.

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

  Purpose2/5

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

  The description never states what the tool does; it only describes a side effect ('the withdrawal is charged to the case; stock is not touched'). The tool's actual purpose must be inferred from the name/title ('hent'/'Afhent bestilling'), making this close to a restatement of the name. It also does not distinguish itself from siblings like lager_bestillinger, lager_bestil or lager_aflever.

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

  Usage Guidelines1/5

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

  There is no guidance on when to call this tool, no prerequisites, and no mention of alternatives among the many bestilling/lager siblings. The agent is left to guess the invocation context entirely.

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

• lager_search_capabilitiesC
  2.2/5.0
  Behavior2/5

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

  Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds no behavioral context of its own — nothing about what a query matches, how results are ranked or returned, or the effect of an empty query.

  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?

  A single short sentence with no filler, so it is structurally clean. But it is under-specified rather than genuinely concise — brevity here comes at the cost of information.

  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 should explain what a search returns (tool names? schemas? capability descriptions?) and how to use the query. For a discovery/meta tool with 0% parameter documentation, one tagline sentence leaves the agent guessing.

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

  Parameters1/5

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

  Schema description coverage is 0% for both parameters, and the description says nothing about 'query' (search semantics, matching behavior) or 'limit' (default 20, max 50). It entirely fails to compensate for the undocumented schema.

  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 name and title indicate a search over the lager MCP's own capabilities, and the description's phrase 'find det rigtige værktøj' (find the right tool) loosely conveys a tool-discovery purpose. However, the description itself never says it searches the MCP's tool catalog or returns tool metadata; an agent must infer that from the name/title alone.

  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?

  'Før første kald' (before the first call) hints at timing, but no explicit when-to-use conditions, no mention of when it is unnecessary, and no alternatives are named. It stops short of real guidance.

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

• lager_ansvarlig_koeC
  2.3/5.0
  Behavior2/5

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

  Annotations declare this as a read-only, idempotent, non-destructive operation, so safety is covered. However, the description does not add behavioral context such as what the queue represents, what the agent will receive, or any prerequisites. With annotations handling the safety profile, the description still fails to disclose anything meaningful about the tool's behavior beyond the topic list.

  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?

  The description is a single, short sentence, which is concise. However, it is front-loaded with a vague clause ('Det, der kræver afgørelse') before listing topics, and the meaning is not immediately clear to an agent unfamiliar with the domain. It is adequately sized but not optimally structured.

  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?

  Given a tool with one optional parameter, no output schema, and read-only annotations, the description should at least clarify what the queue contains and how it differs from sibling tools. Instead, it offers only a cryptic topic list, leaving the agent unable to determine when or why to invoke it. This is insufficient for correct tool selection.

  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?

  Schema description coverage is 100%, and the single optional parameter 'lagerId' is fully documented with a clear note to omit it when only one warehouse is accessible (referencing lager_me). The description adds no parameter guidance, which is acceptable given the high schema coverage, so the baseline of 3 applies.

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

  Purpose2/5

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

  The description 'Det, der kræver afgørelse: ukendte mærker, karantæne, klargøring, afstemning, afregninger' (What requires decision: unknown brands, quarantine, preparation, reconciliation, settlements) lists topics but does not state a specific verb and resource. It reads as a category label rather than a clear action, and there is no differentiation from the numerous sibling tools despite the 'lager_ansvarlig_' naming convention hinting at a responsibility queue.

  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 guidance on when to use this tool versus alternatives. The description does not explain what the 'queue' is, when an agent should call it, or how it relates to the many sibling 'lager_ansvarlig_' tools. Usage remains entirely implicit.

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

• lager_ansvarlig_modtag_leveringC
  2.3/5.0
  Behavior3/5

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

  Annotations declare this is a non-read-only, non-idempotent mutation, so the write nature is already covered. The description adds real behavioral context beyond annotations: the cost price on a line becomes today's price, and ordered goods are set aside for waiting users. It does not mention permissions, reversibility, or effects on stock balances explicitly.

  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 short and front-loads the operational facts, but the phrasing is cryptic and uses terms the agent must decode. It is concise but at the cost of clarity, and nothing indicates the primary action.

  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?

  For a mutation tool with 5 parameters, 20% schema coverage, nested line objects and no output schema, the description is largely incomplete. It omits the core operation name, parameter meanings, and consequences, so an agent lacks enough to invoke it reliably.

  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 only 20%, so the description should compensate. It mentions bilag, linjer, kostpris and ordered items, but does not explain dato, leverandoer, lagerId, or the nested ny/forbrugsvareId fields, leaving most parameters undocumented in both schema and text.

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

  Purpose2/5

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

  The Danish description says billing lines per item and that a line cost price becomes today's price, with ordered goods reserved for waiting users. It never states the actual action plainly in a way that distinguishes it from siblings; a reader must infer that this registers/receives a delivery. It does not name the command verb (modtag levering) as an operation the agent can recognize against lager_aflever, lager_bestil, etc.

  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 statement of prerequisites, and no mention of alternatives such as lager_bestil or lager_aflever. The agent gets behavior hints (prices, reservation) but no decision rule for selecting this tool over siblings.

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

• lager_bestilling_fortrydC
  2.3/5.0
  Behavior2/5

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

  Annotations declare destructiveHint=false, which is already a weak signal for a cancellation tool. The description does not disclose irreversibility, whether stock is affected, or required authorization beyond 'the warehouse manager can always'. It adds some behavioral context (timing, stock consequence) but is too terse for a mutation tool carrying most of the burden.

  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?

  Very short, but it reads as a fragment rather than a structured definition. It is front-loaded with a condition, not the action, and omits the essential verb.

  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?

  For a mutation tool with a required but unexplained parameter, no output schema, and only partial behavioral disclosure, the description is too sparse. It doesn't explain what happens on success or what 'ready' means operationally.

  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%, so the single required parameter bestillingId has no documented meaning anywhere. The description never explains what bestillingId refers to or how to obtain it, leaving the parameter semantically opaque.

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

  Purpose2/5

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

  The title 'Fortryd bestilling' (cancel order) restates the tool name 'lager_bestilling_fortryd', and the description only adds a temporal condition ('Indtil varen er klar' – until the item is ready). It never states what the tool actually does in a full sentence. An agent must infer 'cancel' from the name/title alone.

  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 gives a genuinely useful timing constraint: cancellation is possible until the item is ready, and the warehouse manager can always cancel (a ready item goes to stock). This implies when cancellation is permitted, though it doesn't name alternatives or explicitly state when-not.

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

• lager_ansvarlig_perioderC
  2.5/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no behavior beyond that — no return shape, no pagination, no scope/permission notes for the lagerId context, and no indication of what 'open' periods mean.

  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?

  A single dense fragment with no wasted words, but it is terse to the point of near-cryptic ('Pr. enhed') and is not front-loaded with the tool's purpose — it opens with a filter modifier rather than what the call returns.

  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?

  For a 5-parameter tool with no output schema and 20% schema coverage, the description is too thin: it never says what is returned, whether tag and fra/til are exclusive, or how lagerId scoping interacts with access. Too much is left for the agent to reconstruct.

  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?

  With only 20% schema description coverage, the description must compensate, and it partially does: it gives the date format (ÅÅÅÅ-MM-DD) for fra/til and the meaning of aabne=true. It leaves 'tag' and the mutual exclusivity of tag vs. fra/til window only loosely implied.

  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 specifies two query modes (per unit via 'tag' or in a window via 'fra'/'til') but never states the actual action or resource — that it retrieves rental periods ('lejeperioder'). An agent must infer the verb from the title alone, so the purpose is implied rather than stated.

  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?

  No when-to-use guidance and no routing to alternatives, despite many overlapping siblings such as lager_ansvarlig_overblik, lager_bookinger, and lager_ansvarlig_afregninger. The 'eller' hints at two modes but not when to choose this tool over another.

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

• lager_bestilC
  2.6/5.0
  Behavior2/5

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

  Annotations already declare the operation is a non-read-only, non-idempotent, non-destructive write, so the mutation nature is covered. The description adds that the order is 'ready after typically 2 to 3 days' with 'notification in the app,' which is useful post-call behavior. However, it omits critical details for a write operation with no annotations beyond hints: whether the order can be cancelled, whether it incurs cost, and what happens if items are not actually sold out. The behavioral disclosure is thin.

  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?

  Two short sentences with no waste, and the core action is front-loaded. It is appropriately sized for a simple ordering tool, though the second sentence about timing and notification could be seen as slightly peripheral to the tool's invocation.

  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?

  For a non-idempotent write tool with no output schema, three parameters (one nested), and no usage routing among many siblings, the description is insufficient. It fails to explain what happens on success/failure, whether the order is cancellable, or how it relates to other ordering tools, leaving the agent with too little to invoke it confidently.

  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?

  Schema description coverage is 67%, so the schema already documents lagerId and projektId, including cross-references to sibling tools. The description adds no parameter-level meaning whatsoever. With partial schema coverage, a baseline 3 is appropriate, but the description does nothing to compensate for the undocumented nested 'linjer' array fields.

  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 states a specific verb and resource ('Bestil forbrugsvarer' – order consumables), which is clear enough. However, it adds a condition ('der er udsolgt' – that are sold out) without stating whether this is a requirement or just typical context, and it doesn't distinguish itself from siblings like lager_bestilling_hent or lager_forbrugsvarer. The purpose is discernible but not sharply defined.

  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 guidance on when to use this tool versus alternatives. With 26 sibling tools, several of which relate to ordering (lager_bestilling_hent, lager_bestilling_fortryd, lager_ansvarlig_send_bestillingsliste), the absence of when-to-use or when-not-to-use criteria is a significant gap. The phrase 'der er udsolgt' hints at a condition but is not framed as a usage rule.

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

• lager_ansvarlig_bestillingerC
  2.8/5.0
  Behavior3/5

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

  Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds content semantics (grouping by supplier, two inclusion categories, status) but says nothing about ordering, size, or how results are shaped, so it adds only moderate value beyond the annotations.

  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 sentence with no filler, but the nested parenthesis ('skal bestilles: brugernes bestillinger og varer under minimum') makes the scope hard to parse on first read. Reasonably compact but not cleanly front-loaded.

  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?

  With no output schema, the description should carry the return-value burden; it partially does by naming the two supplier-grouped categories and the status list, but omits ordering, volume, or pagination behavior and never disambiguates from sibling order-listing tools.

  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?

  There is a single optional lagerId parameter with 100% schema description coverage that already explains when to omit it. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

  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 conveys that this returns an order list grouped per supplier (user orders plus items below minimum stock) and all orders with status, which is a coherent purpose. However, it is phrased as a noun fragment rather than a verb+resource statement, and it never distinguishes itself from close siblings like lager_bestillinger or lager_ansvarlig_send_bestillingsliste.

  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 named alternative among the many order-related siblings (lager_bestillinger, lager_bestil, lager_bestilling_hent). The agent is left to infer the context entirely.

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

• lager_modelC
  2.8/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 a closed world, so the safety profile is fully covered structurally. The description adds the useful constraint that pricing data is deliberately omitted, sparing the agent from expecting cost fields, but says nothing about lookup failures, authorization, or missing-model behavior.

  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?

  Two terse fragments, no filler, with the returned-content summary front-loaded and the price exclusion trailing. Efficient, though the extreme brevity costs it the clarity that a verb-led sentence would have provided.

  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?

  For a single-parameter read with no output schema, the field enumeration does double duty as an implicit return-value summary, which is genuinely helpful. However, the required modelId is unexplained and there is no indication of what happens when the model is absent, leaving the description only partially complete.

  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% for the single parameter modelId, so the description carries the full burden of explaining it. It says nothing about what modelId is, where it comes from, or its format, leaving the required identifier completely undocumented in both schema and description.

  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 enumerates the data attached to a model (name, photos, documents, protective equipment), which implies a fetch/read of a single model's record, but it never states a verb or resource explicitly. It also does not differentiate this tool from sibling model-related tools such as lager_ansvarlig_modeller, so the agent must guess which one to call.

  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?

  "Ingen priser" is the only scoping signal and is framed as a content exclusion rather than a when-to-use rule. There is no statement of when this tool is appropriate versus the many sibling tools, nor any prerequisites or alternatives named.

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

• lager_ansvarlig_forbrugsvarerC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare this a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description does add value by signalling that cost and sales prices are exposed, which is meaningful for a 'lageransvarlig' role tool, but it says nothing about scope, filtering, or whether the whole catalogue is returned.

  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 clause with no filler and no repetition; it gets straight to the resource and fields. It is arguably under-sized rather than bloated, but nothing in it is wasted.

  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?

  With no output schema, the field enumeration partially compensates by telling the agent what comes back. However, for a role-scoped inventory listing it omits whether results are filtered, paged, or scoped beyond lagerId, and it gives no routing versus the sibling forbrugsvarer tool.

  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?

  Schema description coverage is 100% and the single lagerId parameter is fully documented in the schema, including its fallback rule via lager_me. The description adds no syntax or meaning beyond the schema, so the baseline of 3 applies.

  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 is a bare noun phrase enumerating returned fields ('Forbrugsvarer med beholdning, minimum, kost- og salgspris, sidst modtaget') with no verb, so it reads as a data listing rather than stating what the tool does. The resource (forbrugsvarer) is identifiable, but it is not distinguished from the near-identical sibling lager_forbrugsvarer, leaving the agent to guess which one to call.

  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 prerequisite, and no mention of the sibling lager_forbrugsvarer or of how this 'ansvarlig' variant differs from the plain one. The only scoping hint (lagerId omitted when you have access to one warehouse, see lager_me) lives in the schema, not the description.

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

• lager_ansvarlig_overblikC
  2.9/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 elsewhere. The description adds useful content-level context about what data is surfaced (problems requiring action plus recent movements), but says nothing about aggregation granularity, time windows, or whether lagerId is optional.

  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 terse sentence fragment with no filler, and the action-requiring categories are front-loaded before the secondary 'seneste bevægelser'. It is efficient, though the fragmentary style makes the intended outcome slightly ambiguous.

  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?

  For an aggregating overview tool with no output schema and only one optional parameter, the critical missing piece is what the returned numbers look like and over what period they are computed. The category enumeration partially compensates, but an agent still cannot predict the shape or freshness of the response.

  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?

  Schema description coverage is 100% – the single lagerId parameter is already documented in the schema, including the note that it can be omitted when the user only has one warehouse. The description adds no parameter information, so the baseline of 3 applies.

  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 enumerates the concrete content categories (afregninger, ukendte, karantæne, lav beholdning, forfaldne, seneste bevægelser), which conveys that this is an action-oriented dashboard aggregation. However, "Tal, det der kræver handling" is a loose noun phrase rather than a clear verb+resource, and nothing distinguishes it from siblings such as lager_ansvarlig_afregninger or lager_ansvarlig_perioder that cover the same domains individually.

  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?

  No explicit when-to-use statement. The agent must infer that this is the entry-point overview for a warehouse manager, and there is no guidance on when to prefer this aggregated view over the more specific lager_ansvarlig_* tools. No exclusions or prerequisites are given.

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

• lager_bestillingerC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description does add one genuine behavioral fact the annotations lack: the result set is scoped to three order states plus a 30-day window for picked-up orders. It says nothing about ordering, volume or pagination.

  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 only a fragment, not a sentence, but it is front-loaded and free of padding. Brevity here is achieved by omission rather than by tight writing, which limits the score.

  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?

  For a no-parameter read tool with full annotation coverage the bar is modest, but the description still omits what is returned (order object fields, counts, sorting), what the '30 dage' window applies to precisely, and whether results are grouped by the three states. Without an output schema, an agent cannot know the response shape.

  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?

  The tool takes zero parameters, and the schema is empty, so there is no parameter semantics for the description to compensate for. Baseline 4 applies; nothing in the description misleads about inputs.

  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 never states a verb or resource; it only enumerates the statuses the results cover ('Klar til afhentning, på vej, hentet'). The agent must rely on the name and title ('Mine bestillinger') to infer that this lists the caller's own orders, and nothing distinguishes it from siblings such as lager_ansvarlig_bestillinger or lager_bestil.

  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 and no mention of alternatives. With siblings like lager_bestilling_hent, lager_bestilling_fortryd and lager_ansvarlig_bestillinger in the namespace, an agent gets no help deciding when this read-only listing is the right pick.

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

• lager_opslagB
  3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful context about the returned content domains (PPE, documents/datasheets), but does not describe the response shape or any lookup failure behavior.

  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 compact sentence that front-loads the returned information with no filler. It is terse to the point of being cryptic, but every clause maps to a content domain.

  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?

  With no output schema, the description appropriately enumerates what a successful lookup returns, and the single-parameter, read-only nature keeps complexity low. It is complete enough to call the tool correctly, though the routing to sibling tools remains unaddressed.

  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?

  Schema description coverage is 100% with a single documented parameter ('kode' = tag or serial number), so the schema already carries parameter meaning. The description adds nothing beyond it, which is the expected baseline when the schema does the work.

  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 enumerates the information the lookup returns (what it is, who holds it, where it belongs, PPE, documents) rather than stating the action itself. Combined with the name 'opslag' and title 'Slå et mærke op', the purpose is inferable, but the description on its own is a content list, not a clear verb+resource statement.

  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 mention of any of the many sibling tools (e.g. lager_tjek_ud, lager_forbrug). The agent must infer usage entirely from the name.

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

• lager_bookingerB
  3.1/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 a closed-world scope, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: results are limited to the coming days rather than all history. It still says nothing about ordering, horizon length, or timezone handling.

  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 filler, and the resource plus scope are front-loaded. It is arguably terse to the point of under-specification, but no sentence is wasted.

  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?

  For a no-parameter, read-only tool with full annotation coverage and no output schema, the minimum needed is what it returns and for whom. The description delivers the resource and time window but leaves ownership ambiguity (mine vs. everyone's) and any notion of result shape unaddressed.

  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?

  The tool takes zero parameters, so there is no parameter semantics for the description to explain; the baseline of 4 applies. The description cannot and need not document inputs here.

  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 (bookinger af værktøj) and a time scope (kommende dage), so an agent knows it retrieves equipment bookings for an upcoming window. However, it never clarifies whose bookings these are (the title says 'Mine', the description omits ownership), and it does nothing to distinguish itself from siblings such as lager_mine, lager_bestillinger or lager_ansvarlig_overblik.

  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 mention of alternative tools for retrieving bookings or order data. The agent must infer usage purely from the tool name.

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

• lager_flyt_projektB
  3.1/5.0
  Behavior3/5

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

  With readOnlyHint=false and destructiveHint=false already declared, the description usefully adds what changes and what does not: 'custody uændret, lejen skifter projekt fra i dag' (custody unchanged, rental switches project from today). That timing/state detail goes beyond the annotations, but auth/permission behavior and failure handling are not clarified; the trailing 'som lageransvarlig på lagerId' fragment is too cryptic to count as clear disclosure.

  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?

  The core action is front-loaded, but the sentence is a colon/semicolon chain and closes with an incomplete-looking fragment ('Egne emner; som lageransvarlig på lagerId alt på lageret') that reads as dangling rather than earning its place.

  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?

  For a non-idempotent mutation with no output schema, the description covers the essential effect (project switch from today, custody preserved) but leaves the warehouse-manager condition and 'egne emner' clause unexplained, and offers nothing on confirmation or response. Adequate but with clear gaps.

  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?

  Schema description coverage is 75%, so the schema already documents koder, lagerId and projektId ('Mærker eller serienumre', 'Lager-id... se lager_me', 'Projektets id... se lager_projekter'). The description only loosely gestures at lagerId and 'egne emner' without adding format or constraint detail, so the baseline 3 applies.

  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 opening clause 'Udlejet værktøj flyttes til et andet projekt' gives a specific verb (flyttes/move) and resource (udlejet værktøj/leased tool) plus a destination (et andet projekt), and 'uden om lageret' clarifies the scope. It does not, however, distinguish itself from siblings like lager_aflever or lager_tjek_ud, so it lands below a 5.

  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 vs when-not, and no sibling is named as an alternative. The 'uden om lageret' phrase implies a bypass path but never states the condition under which an agent should pick this tool over the other lager_* movement tools.

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

• lager_mineB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a little return context (grouped per project, includes daily rate), but says nothing about how 'dagsleje' is derived, freshness, or result shape, and with no output schema that gap matters.

  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?

  It is a single short clause with no filler, and the scope qualifiers ('pr. projekt, med dagsleje') come after the core claim. It is efficient, though being a sentence fragment it is terse to the point of being cryptic rather than thoroughly front-loaded.

  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?

  For a parameterless, read-only list tool with no output schema and no field documentation, the description should at least sketch what comes back. It hints at per-project groupings with a daily rate but leaves the structure, any time scoping, and the meaning of 'dagsleje' unexplained.

  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?

  The tool takes zero parameters, so there is no parameter semantics for the description to explain; baseline is 4. No misleading parameter hints are present.

  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 conveys the resource ('det, du har ude' – what you currently have checked out) and adds scope detail (per project, with daily rate). However, it is a noun phrase with no verb, and it never distinguishes itself from siblings like lager_tjek_ud, lager_projekter, or lager_me, so an agent cannot confidently route to it from the text alone.

  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 or when-not-to-use statement, and no alternative sibling is named. The phrase 'det, du har ude' weakly implies a read of current loans, but the agent is given no condition that selects this tool over the many other lager_* query tools.

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

• lager_projekterB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered. The description adds useful content context — that results include case numbers and what the user currently has checked out — but says nothing about scoping, filtering, or result size.

  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 compact sentence with no filler, and the identifying scope ('projects you can book on') is front-loaded before the payload description. Slightly clipped grammar costs it the top score.

  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?

  With no parameters and no output schema, the description partially compensates by naming the returned fields (case number, current holdings). It remains silent on whether the list is scoped to the calling user, whether it is paginated, and how it relates to booking flows, leaving real gaps for an agent.

  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?

  The tool takes zero parameters and the schema is empty, so there is no parameter semantics to explain; the baseline of 4 applies. The description correctly implies this is a parameterless listing operation.

  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 identifies the resource (projects available for pickup and booking) and the data they carry (case number, current holdings), which is more than a tautology. However, it is phrased as a noun fragment without an explicit verb ('retrieve/list'), and it does not distinguish itself from siblings such as lager_bookinger or lager_aflever.

  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 statement of when to call this tool versus the many sibling tools (lager_bookinger, lager_tjek_ud, lager_flyt_projekt, etc.). The phrase 'du kan afhente til og booke på' only implies a booking-related context, leaving the agent to infer the trigger condition.

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

• lager_ansvarlig_send_bestillingslisteB
  3.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description goes beyond that by disclosing the actual side effects: open orders are 'sent' and items under minimum get a new warehouse order created, which is valuable mutation context. It still omits reversibility, permissions, and whether re-running duplicates orders.

  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 tight two-clause sentence that front-loads the scoping ('for én leverandør til indkøb') before the effects. It is efficient, though the terse phrasing borders on cryptic and requires interpretation.

  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?

  The description covers the return ('Svaret er teksten til indkøb') even though there is no output schema, and annotations carry the safety profile. However, for a mutation tool with zero required params and two undocumented parameters, it leaves too much unresolved for an agent to call it confidently.

  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 coverage is only 33%, with just lagerId documented in the schema. The description implicitly covers leverandoer via 'for én leverandør', but forventet is completely unexplained in both schema and description, and no parameter is required, so the agent has little to go on for the undocumented inputs.

  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 states a specific action (sending the order list for one supplier to purchasing) plus the resulting effects, so the core purpose is identifiable. It does not distinguish itself from siblings such as lager_bestil, lager_ansvarlig_bestillinger, or lager_bestilling_hent, leaving the agent to infer which is the right one.

  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?

  The description implies a context (one supplier, purchasing) but gives no explicit when-to-use guidance and no exclusions or named alternatives. With many closely related ordering siblings, an agent gets no routing help for choosing this over lager_bestil or lager_bestilling_hent.

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

• lager_tjek_udB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world behavior. The description adds genuinely useful behavioral detail beyond that: the overtag: true requirement when the item currently sits with a colleague, and the accepted retur values. It still says nothing about failure modes or what happens to the record on success.

  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?

  Three short, front-loaded sentences with no filler; the core action and the key conditional (overtag) come first. Slightly terse/telegraphic rather than tightly organized, but nothing is wasted.

  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?

  With no output schema and four parameters, the description covers the action, the overtag conditional, and the retur enumeration, which is most of what is needed. It still omits prerequisites (e.g. which lager/project access is required) and any statement about the result, leaving gaps for a mutating tool.

  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?

  Schema description coverage is only 50% (lagerId and projektId are annotated in-schema), but the description compensates by documenting the two undocumented concerns: overtag semantics per line and the enumerated values for retur, which the schema leaves as a bare string. Only linjer/kode is left implicit.

  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?

  States a concrete action and target ("Udlevering til et projekt"), so an agent knows this checks stock out to a project rather than returning it. The title "Tag værktøj med ud" reinforces the checkout semantics, though it never explicitly distinguishes itself from the close sibling lager_aflever.

  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?

  No explicit when-to-use / when-not-to-use guidance and no alternative named. The reader must infer from "Udlevering til et projekt" that this is the checkout path and lager_aflever is the return path.

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

• lager_meB
  3.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.

• lager_forbrugA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds genuine behavioral context beyond that: charging at today's sales price, that bestil:true lines route through procurement, and that they are only charged upon pickup.

  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?

  It is a single dense sentence with the primary action front-loaded and no filler. The semicolon-compressed structure is efficient, though a slightly more structured phrasing could improve scannability.

  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?

  For a mutation tool with annotations covering the safety profile and partial schema coverage, the description covers pricing and the bestil nuance. It still leaves the agent without explicit routing against the many sibling order/hand-in tools, so it is adequate but not 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?

  Schema description coverage is 67%, and the key undocumented field 'bestil' is explained in the description (bestil:true → ordered via procurement, charged at pickup), which adds meaning the schema lacks. It does not elaborate the antal/vareId fields, but those are self-evident.

  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 states a specific action ('Udtag til projektet' – withdraw for the project) at today's sales price, which conveys the consumption-registration purpose distinct from ordering siblings. It is somewhat indirect (the verb is 'udtag' rather than an explicit 'register consumption'), but an agent can grasp the core operation.

  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 or when-not guidance, nor a named alternative such as lager_bestil or lager_aflever. The only conditional mentioned (lines with bestil:true) is parameter-level behavior, not tool-selection guidance.

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

• lager_forbrugsvarerA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds that this is a catalogue view and that sold-out items are orderable elsewhere, but says nothing about result size, pagination, or permissions; modest added value over the annotations.

  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?

  Two terse fragments that are entirely front-loaded and waste-free. It is arguably slightly under-specified rather than padded, but every word carries information.

  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?

  With no output schema, the field list (navn, varenr, gruppe, beholdning, salgspris) usefully conveys what a call returns, and the cross-reference to lager_bestil closes the ordering loop. Remaining gaps are minor for a simple read-only catalogue tool.

  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?

  Schema description coverage is 100% – both soeg (filter on name/item no.) and lagerId (omit when you only have one warehouse, see lager_me) are documented in the schema itself. The description adds no parameter-level detail, so the baseline 3 applies.

  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?

  Identifies the resource ("Kataloget") and enumerates the fields it returns (navn, varenr, gruppe, beholdning, salgspris), so an agent knows this is a consumables catalogue lookup. However, there is no explicit verb and no differentiation from the similarly named sibling lager_ansvarlig_forbrugsvarer.

  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 sentence "Udsolgt kan bestilles med lager_bestil" routes one sub-case (ordering sold-out items) to a named sibling, which is genuine routing guidance. But it gives no general when-to-use context or distinction from lager_forbrug, lager_opslag, or lager_ansvarlig_forbrugsvarer, so usage is only partially implied.

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

• lager_afleverA
  3.7/5.0
  Behavior4/5

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

  Annotations declare the safety profile only negatively (not read-only, not destructive, not idempotent), so the description adds real value: it discloses that the response tells the caller where the item should be placed, and imposes a conditional requirement ('Skadet kræver en note'). It does not cover bulk/partial-failure behavior or whether re-submitting the same lines is safe.

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

  Conciseness5/5

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

  Two compact clauses, front-loaded with the core action, and every sentence carries a distinct piece of information (return semantics, response behavior, damaged-item rule). No filler.

  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?

  With no output schema, the description usefully signals what the response contains, and it covers the damaged-item validation path. It stops short of describing multi-line handling, partial success, or what happens if an item is not in the warehouse.

  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?

  Schema coverage is 50% and the nested linjer fields (kode, note, skadet) carry no descriptions, but the description compensates by explaining the conditional relationship between skadet and note — a rule the schema alone would not convey. The lagerId parameter is documented in the schema itself, so no duplication is needed.

  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?

  States a specific verb+resource: return goods to the warehouse ('Retur til lageret'), which is unambiguous on its own. It does not name or contrast with its obvious counterpart lager_tjek_ud, so an agent must infer the inverse relationship rather than being told it.

  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 lager_tjek_ud, lager_flyt_projekt, or lager_forbrug. Usage is only implied by the phrase 'Retur til lageret'.

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

• lager_ansvarlig_afregningerA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new context: what each mode returns (settlements with status; per-case detail with lines and missing items) and an explicit boundary that approval and posting cannot be done here. It stops short of describing pagination or volume limits.

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

  Conciseness5/5

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

  Three short sentences, front-loaded with the mode-based behavior and ending with the scope boundary. No filler, every sentence 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?

  With no output schema, the description carries the return-content burden and does describe both result shapes plus the approval/posting exclusion. For a two-parameter read tool it is nearly complete; only edge details such as result size or pagination are omitted.

  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?

  Schema coverage is only 50% (afregningId is undocumented). The description partially compensates by explaining the semantic effect of supplying an id (per-case detail vs. full list), which is the key behavioral meaning of afregningId. However it never names the parameter, leaving it ambiguous whether 'id' means afregningId or lagerId, and adds nothing beyond the schema for lagerId.

  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 names the resource (afregninger) and precisely splits the tool's behavior by mode: without an id it returns all settlements with status, with an id it returns the per-case settlement including lines and missing items. That is enough to tell it apart from siblings like lager_ansvarlig_overblik or lager_bookinger, though no sibling is named explicitly.

  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 two modes of use are described (id omitted vs id supplied), which implies when each call shape applies. The statement that approval and posting happen in the app, not here, usefully bounds scope, but there is no explicit guidance on when to choose this tool over the other lager_ansvarlig_* tools.

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

• lager_ansvarlig_modellerA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare this a read-only, idempotent, non-destructive operation, so safety is covered. The description adds genuine value by disclosing the shape of the result in each mode (counts and prices vs. photos, documents, price versions and units), which is behaviour an agent could not infer from the annotations alone.

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

  Conciseness5/5

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

  Two tight clauses, front-loaded with the no-modelId case first and the modelId case second. Every word earns its place and nothing is repeated from the schema.

  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?

  With no output schema and no required parameters, the description carries the burden of describing returns and does so well for both modes. The gaps are the unexplained inklInaktive flag and the absence of any pagination or volume caveat for the all-models listing.

  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?

  Schema coverage is only 33%, so the description has to compensate. It does explain the central modelId parameter and its effect on the response, which is the most valuable addition, but inklInaktive is left totally undocumented in both schema and description, and the lagerId scoping note exists only in the schema.

  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 states a specific resource (modeller) and clearly splits the behaviour into two modes based on whether modelId is supplied, so an agent knows exactly what it gets back in each case. It never names or contrasts itself with the sibling lager_model, so differentiation from nearby tools is left to inference.

  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?

  Usage is implied structurally: omit modelId for the list view, supply it for the detailed single-model view. There is no explicit when-not guidance, no mention of the alternative lager_model/lager_me tools, and no note on when the lagerId scope matters.

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

• lager_ansvarlig_enhederA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds real behavioral value by disclosing what each mode returns: filtered entities in list mode versus photos, history, rental periods and sales in tag mode. It omits pagination/limit behavior, but otherwise goes beyond the annotations.

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

  Conciseness5/5

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

  Two tightly parallel clauses front-load the mode switch and waste no words; the status list is the only length and it carries genuine information.

  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?

  With 5 params, no output schema and low schema coverage, the description covers the critical mode distinction, the return payload per mode, and the status vocabulary. The remaining gap is the meaning/optionality of lagerId, modelId and soeg for filtering.

  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?

  Schema description coverage is only 20%, so the description must compensate, and it does: it enumerates the accepted status values (paa_lager, ude, karantaene, til_klargoering, til_service, savnet, kasseret, solgt) that are absent as an enum in the schema, and explains the semantic difference of tag. It leaves soeg, modelId and lagerId's usage unexplained, preventing a 5.

  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 names a specific resource (enheder) and clearly splits behavior into two modes: a filtered list when no tag is given, and a single detailed unit when tag is given. It distinguishes itself from generic list siblings via the status/model/search filter description, though it never explicitly contrasts itself with tools like lager_opslag or lager_model.

  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 'Uden tag' / 'Med tag' framing implicitly tells the agent which mode to pick based on whether it holds a tag, which is useful routing guidance. However there is no explicit when-to-use, when-not-to-use, or reference to a sibling alternative for the list case.

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