Skip to main content
Glama

Lintelly HR Deutschland

HR-Workflow

workflow_vorlage
Read-onlyIdempotent

Germany only. German employment law, Germany only: the ten follow-up workflows of the Lintelly workbench (HR-Workflows), e.g. payroll input deadline, missing onboarding documents, sick leave with eAU and BEM, maternity protection, probation decision, fixed-term contract signed before start. Each shows the chain 'when ... then ...' with default days and roles. Use it as a template for your own reminders. Without kennung it lists all ten.

Input Schema

NameRequiredDescriptionDefault
kennungNoKey of the workflow, leave out for the list

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/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 that each entry contains a when/then chain with default days and roles and that omitting kennung returns all ten, but says nothing about output shape or size beyond that.

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 content comes first, but the description opens with the fragment 'Germany only.' immediately repeated as 'German employment law, Germany only', which is wasted space. The example list is long and partly redundant with the enum values.

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 responsibly explains what each returned item contains (when/then chain, default days, roles) and the no-argument default. It falls short only on how entries relate to the overlapping sibling tools.

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 100% and the enum is self-explanatory, so the baseline is 3. The description earns an extra point by explicitly documenting the default behavior when kennung is omitted ('Without kennung it lists all ten'), which the schema itself does not state.

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 resource: the ten HR follow-up workflow templates of the Lintelly workbench, and explains their form ('when ... then' chains with default days and roles). It does not differentiate from siblings whose names mirror the kennung values (probezeit, mutterschutz, befristung, bem_pflicht), so an agent could confuse this collection with those detail tools.

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?

'Use it as a template for your own reminders' gives one implied use case, but there is no statement of when to prefer a sibling (e.g. probezeit or mutterschutz) or when this tool is the wrong choice. Usage is inferable but not guided.

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.