Skip to main content
Glama

FreeDailyPro Calculators

converters_job_experience

Read-onlyIdempotent

Job experience calculator

Input Schema

NameRequiredDescriptionDefault
endIsoNo
startIsoYes
otherJobsNoMore jobs. When given, the top-level years, months and label are the TOTAL across all jobs (overlapping periods counted once; the first job alone is in `firstJob`), and the response also has a `history` object: each job's length, the total, and the gaps between jobs.
countEndDateNoOnly used with otherJobs. true (default) counts the end date as a full day, so 1 Jan to 31 Dec is one year.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / otherJobs / description
      Previous value: -"More jobs. When given, the response also has a `history` object: each job's length, the total with overlapping periods counted once, and the gaps between jobs."New value: +"More jobs. When given, the top-level years, months and label are the TOTAL across all jobs (overlapping periods counted once; the first job alone is in `firstJob`), and the response also has a `history` object: each job's length, the total, and the gaps between jobs."
  2. Changed2 schema fields changed
    • addedInput schema / properties / countEndDate
      Added value: +{
      +  "description": "Only used with otherJobs. true (default) counts the end date as a full day, so 1 Jan to 31 Dec is one year.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / otherJobs
      Added value: +{
      +  "description": "More jobs. When given, the response also has a `history` object: each job's length, the total with overlapping periods counted once, and the gaps between jobs.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "endIso": {
      +        "description": "YYYY-MM-DD. Leave out for a job that is still going on (today is used).",
      +        "type": "string"
      +      },
      +      "startIso": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "startIso"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 50,
      +  "type": "array"
      +}
  3. First observed

TDQS

D1.9/5.0
Behavior2/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. However, the description adds nothing about the calculation behavior, such as how overlapping jobs are handled, defaults for ongoing jobs, or what output fields are produced.

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

Conciseness2/5

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

It is extremely short, but the issue is under-specification rather than conciseness. The single noun phrase is front-loaded with no useful detail.

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

Completeness1/5

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

For a calculator with four parameters, optional multi-job aggregation, overlap rules, and no output schema, this description is inadequate. It does not explain return values, date formats, or multi-job behavior.

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 50%, and the description adds no parameter meaning at all. The schema itself explains otherJobs and countEndDate, but startIso and endIso remain undocumented and the description does not compensate.

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 is essentially a restatement of the tool name and title: 'Job experience calculator' gives the domain but no specific verb or output. It does not distinguish this tool from the many other calculator siblings in any meaningful way.

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, what it is for versus alternatives, or any prerequisites. The description provides no usage context beyond the bare topic.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources