Skip to main content
Glama

4dayweek.io Jobs

Get employer

get_company
Read-onlyIdempotent

Fetch one employer's full profile by slug, as returned by search_companies.

Returns the schedule policy and what it means, full-time weekly hours, the office-presence policy and whether the employer hires worldwide, benefits, industry, headcount, founding year, the work-life score, the count of open roles, and the employer's own website.

Where the employer has published them, it also returns which day is off, vacation days, fully-paid parental leave weeks for both parents, a no-meeting day, and verified work-life awards with the year and a proof url for each.

Where the employer's schedule is sourced from a public announcement, four_day_reference_url is that source.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "get_company"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesThe slug, as returned by the matching search tool.

Output Schema

NameRequiredDescriptionDefault
urlNo
nameNo
slugNo
awardsNo
countryNo
day_offNo
benefitsNo
industryNo
logo_urlNo
verifiedNo
open_rolesNo
descriptionNo
methodologyNo
website_urlNo
company_sizeNo
founded_yearNo
remote_levelNo
schedule_typeNo
vacation_daysNo
employee_countNo
no_meeting_dayNo
hires_worldwideNo
hours_full_timeNo
work_life_scoreNo
schedule_meaningNo
short_descriptionNo
hybrid_office_daysNo
parental_leave_weeksNo
vacation_descriptionNo
four_day_reference_urlNo
schedule_type_descriptionNo
parental_leave_secondary_weeksNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive and openWorld, so safety is covered. The description adds genuinely useful behavioral context beyond that: many fields are conditional ('Where the employer has published them'), and schedule data may come from a public announcement with a traceable source URL.

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 first sentence is well front-loaded, but the description then enumerates a long list of returned fields (benefits, industry, headcount, founding year, work-life score, award urls) that are already represented in the output schema, so a substantial portion of the text does not earn 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?

For a single-parameter read with an output schema and full annotation coverage, the definition supplies everything needed to call it correctly, including conditional-field semantics. The only shortfall is that it spends effort restating return values already captured by the output schema.

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 required parameter with 100% schema description coverage, so the baseline is 3. The description's mention of the slug's provenance duplicates what the schema description already states ('as returned by the matching search tool') rather than adding new constraint or format detail.

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

Purpose5/5

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

The description opens with a specific verb+resource ('Fetch one employer's full profile by slug') and explicitly ties the input to a sibling tool ('as returned by search_companies'), so an agent can distinguish it from search_companies, get_job, and the other siblings without opening a schema.

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

Usage Guidelines4/5

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

It establishes the usage context clearly: this is the follow-up lookup after search_companies, taking a slug that search produced. It stops short of explicit when-not-to-use guidance or naming alternatives for related lookups (e.g. get_job), so it is clear context rather than full routing guidance.

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.