Skip to main content
Glama

saightly

by io.github.emils-design

Avropa tjänst

avropa_tjanst

Skickar en FÖRFRÅGAN till en leverantör — Saightly förmedlar kontakten (gratis, avgift_kr är alltid 0). Direktbokning är pausad: bekraftad_tid/pass avvisas (409). Ange kundens behov i kontakt.meddelande och gärna onskad_tid, så återkommer företaget direkt till kunden.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typNoTyp av avrop. Standard: forfragan.
passNoDELAD bokning: flera tillfällen (även spridda över dagar, t.ex. mån 14–16 + ons 08–12) som EN bokning med samma status och kund. Varje pass: start (ledig tid enligt lediga_tider, ISO 8601) + langd_minuter. Ersätter bekraftad_tid/langd_minuter.
slugNoTjänstens slug (från sok_tjanster/las_tjanst) — VÄLJ RÄTT tjänst när företaget har flera. Utelämnad: företagets första aktiva tjänst.
orgnrYesLeverantörens organisationsnummer.
kontaktNoKundens kontaktuppgifter. Vid bokning krävs namn, epost och telefon; adress krävs dessutom när tjänstens platstyp är hos_kund (se lediga_tider).
tillvalNoId:n på tjänstens tillval som kunden vill boka till (t.ex. färgning, webbmaster). Extra tid läggs på bokningen; namn och pris snapshotas på avropet.
onskad_tidNoÖnskad tid (ISO 8601) för en förfrågan.
ordervardeNoOrdervärde i kr (ger värdebaserad avgift för bokning/försäljning).
bekraftad_tidNoVald ledig tid (ISO 8601) från lediga_tider → direktbokning som blockerar slotten. Kräver kontakt med namn, epost och telefon.
langd_minuterNoBokningens längd i minuter — sätt till summan av flera INTILLIGGANDE pass för en längre bokning (annars ärvs tjänstens standardlängd).

TDQS

A3.9/5.0
Behavior4/5

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

It discloses that the service is free (avgift_kr always 0), that Saightly mediates the contact, and that bekraftad_tid/pass are rejected with 409. These are meaningful behavioral details, but it doesn't describe response format or side effects beyond the request being sent.

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?

The description is two sentences, front-loaded with the main action, and includes critical caveats without excess.

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?

Despite rich schema descriptions, the tool lacks an output schema and the description doesn't mention what the response contains. There is also ambiguity about whether typ=bokning is functional given the 'direct booking paused' note.

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?

The input schema has complete descriptions for all 10 parameters, including nested objects and enums, so the description doesn't need to add much. It mentions onskad_tid and kontakt.meddelande but relies on the schema for the rest.

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 clearly states the tool sends a request (FÖRFRÅGAN) to a supplier and notes the fee is zero. It distinguishes itself from direct booking by saying that is paused, but does not explicitly differentiate it from the sibling skapa_offertforfragan.

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 instructs the user to include the customer's needs in kontakt.meddelande and preferably onskad_tid, and explicitly warns that direct booking fields are rejected with 409. However, it does not mention when to use this over skapa_offertforfragan.

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

All saightly toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Most tools have distinct purposes, but avropa_tjanst and skapa_offertforfragan overlap in sending requests, with the difference being specific vs. general targeting. lediga_tider is somewhat redundant as it merely explains the paused booking and directs to other tools.

Naming Consistency4/5

The majority follow a verb_noun pattern (e.g., sok_tjanster, las_foretag, skapa_offertforfragan), but lediga_tider deviates as a noun phrase rather than an action. Swedish naming is consistent in style, though las and tjanst are reused in multiple contexts.

Tool Count5/5

Eight tools is well-scoped for a service mediation platform, covering search, details, requests, and quote management without feeling bloated or sparse.

Completeness4/5

Core workflows for requesting a specific service or a general quote are covered with create/read/select actions. Minor gaps include no way to track a direct avropa_tjanst request and the paused direct booking creates a dead end, but the tool descriptions guide workarounds.

Resources