Skip to main content
Glama
satovarb16
by satovarb16

set_work_authorization

Declare the full set of countries you may legally work in, replacing any prior declaration. An empty list records zero authorized countries.

Instructions

Declare the FULL set of countries the user may legally work in.

REPLACES the previous declaration in its entirety (SC-26) — this is a statement about the whole set ("I can work in X and Y"), not an additive append. An empty list is a valid, distinct declaration (SC-27): "declared, zero countries" differs from "never declared" — analyze_job treats the two differently (no_work_authorization only for the latter).

Countries are canonicalized at write time (tools/_country.py); both the raw text and the canonical form are stored. Two raw spellings that canonicalize to the same country (e.g. "USA" and "United States" in one call) collapse to a single declared row — the first raw spelling encountered wins the echo.

This tool NEVER raises.

Args: countries: Free-text country names, as the user states them. An empty list explicitly declares zero authorized countries.

Entries that canonicalize to nothing ("", " ", "...") are not countries and are dropped. If that leaves nothing, the call is REJECTED rather than silently storing a declaration that means nothing — see the loop below.

Returns: SetWorkAuthorizationResult with success=True and the stored raw/ canonical forms on success; success=False with error="invalid_input" when no given name could be understood, "corrupt" on a broken database, or "write_error" when the write itself fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countriesYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
messageNo
successYes
countries_rawNo
countries_canonicalNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations present the description carries the full burden and does so: it discloses the full-replace semantics, that it NEVER raises, the rejection path when all entries canonicalize to nothing, and all three error codes (invalid_input, corrupt, write_error). Canonicalization behavior and the 'first raw spelling wins' echo rule are also spelled out.

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?

Front-loaded with the core contract and structured with explicit Args/Returns sections, but the parenthetical requirement IDs (SC-26, SC-27) and internal module path (tools/_country.py) are implementer-facing noise that a calling agent does not need. Slightly long, but nearly every sentence carries behavioral weight.

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

Completeness5/5

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

For a one-parameter mutation tool with no annotations, the definition covers semantics, edge cases, failure modes, and return shape completely. Although an output schema exists, the description's brief return summary is a bonus rather than a redundancy, and nothing needed to invoke the tool correctly is missing.

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

Parameters5/5

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

Schema coverage is 0% and the single required parameter is fully compensated: free-text country names as the user states them, empty list explicitly declares zero countries, non-country entries like '', ' ', '...' are dropped, and the rejection behavior when nothing remains. An agent knows exactly what to pass and what happens to edge-case input.

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?

States a specific verb+resource ('Declare the FULL set of countries the user may legally work in') with the scope constraint ('FULL set') front-loaded. No sibling tool overlaps this action, so an agent can route to it unambiguously.

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?

Explains that the call replaces the prior declaration rather than appending, that an empty list is a distinct valid declaration, and ties the distinction to how analyze_job interprets it (no_work_authorization only for 'never declared'). This is strong contextual guidance, though it does not frame when to call this versus any other sibling — reasonably so, since no sibling offers an alternative.

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