Alaska Jobs
Server Details
Every public-sector job in Alaska, daily: search listings, salary data, state pay schedule.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 6 of 6 tools scored. Lowest: 2.7/5.
Each tool serves a distinct purpose: board stats, employer profiles, job details, salary data, official pay, and search. No functional overlap.
All tools follow a consistent 'verb_noun' pattern (get_*, search_*), making them predictable across the tool surface.
With 6 tools, the server covers core functionality (search, details, stats, salary, pay scales) without being too sparse or excessive.
The tool set addresses all key informational needs for Alaska public-sector jobs: discovery, details, statistics, and salary/pay data.
Available Tools
6 toolsget_board_statsAlaska public-sector employment: current numbersAInspect
Board-wide daily statistics: open jobs, employers, new and closed this week, medians, by category and region. Includes a ready-to-quote citation sentence.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions the tool provides statistics and a citation but omits details about read-only nature, auth requirements, rate limits, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the most important information about the tool's output. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description adequately states what statistics are provided and mentions a citation. However, it could offer more context about frequency (daily) or usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so the description adds meaning by explaining what the output contains, which is beyond the schema. Baseline 4 is appropriate per guidelines for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool provides board-wide daily statistics including open jobs, employers, new and closed this week, medians, by category and region. It distinguishes from sibling tools like get_employer or get_job which focus on individual records rather than aggregate stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus its siblings (e.g., get_salary_data, get_state_pay). No explicit context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_employerEmployer hiring profileAInspect
Profile of an Alaska public-sector employer: current openings, hiring pace, typical posted pay. Omit 'name' to list employers.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | employer name or fragment, e.g. 'Fish & Game' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly indicates a read operation ('get') and describes returned content, but does not disclose potential side effects, authorization requirements, or any rate limits. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sentence establishes purpose and output, second gives a key usage instruction. Every word serves a function; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and no output schema, the description covers the main behaviors (specific profile vs list). It could mention return format or data ordering, but is largely complete for a simple profile retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the single parameter 'name' is described as 'employer name or fragment'. The description adds meaning beyond the schema by explaining that omitting the parameter returns a list of employers, providing crucial usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns a profile of an Alaska public-sector employer, listing specific data (current openings, hiring pace, typical posted pay). It also explains that omitting the 'name' parameter lists all employers, distinguishing it from sibling tools like get_job or search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage hint: 'Omit 'name' to list employers.' It implies when to use with vs without the parameter. However, it does not explicitly contrast with sibling tools or state prerequisites, though the purpose is sufficiently distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jobGet one job listing in fullAInspect
Full detail for one listing by slug or alaskajobs.org URL: description, salary, PCN, closing date, apply link.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | job slug or full alaskajobs.org/job/... URL |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the specific fields returned (description, salary, PCN, closing date, apply link) and handling of slug or URL input, indicating a read operation. Missing explicit statement about it being read-only, but adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, front-loaded with core purpose. Every word adds value, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description lists expected output fields and input format, which is sufficient. Could mention response format (e.g., JSON) but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'slug' well-described. The description repeats 'by slug or alaskajobs.org URL', adding no extra meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full detail for one listing' specifying the verb (get) and resource (job listing), and distinguishes from sibling tools like search_jobs that list multiple results. The input method (slug or URL) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific slug or URL but provides no explicit guidance on when to use this tool versus alternatives like search_jobs or get_employer. There are no when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_salary_dataPosted salary statistics by roleAInspect
Median and percentile posted salaries for Alaska public-sector roles, computed from tracked postings. Omit 'role' to list all roles with data.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | e.g. 'administrative assistant', 'correctional officer' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that data is 'computed from tracked postings', which adds context about data source. However, it does not mention other behavioral traits like read-only nature, rate limits, or handling of missing roles.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and scope concisely, second gives usage instruction. No filler words, every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description is fairly complete. It specifies geographic scope (Alaska), data type (public-sector roles), and how to get all roles. Could mention output shape or lack of pagination, but no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with example values, so baseline is 3. The description adds value by explaining the behavior of omitting the parameter to list all roles, which goes beyond the schema description that only gives an example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides median and percentile posted salaries for Alaska public-sector roles, with a specific verb ('get') and resource ('salary data'). It distinguishes from siblings like get_job and get_state_pay by focusing on aggregated statistics by role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells to omit 'role' to list all roles, indicating a key usage variant. While it does not compare with siblings or provide when-not-to-use, the context of Alaska public-sector roles is clear and covers basic usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_state_payState of Alaska salary schedule lookupAInspect
Official GG-schedule pay for a range + step + duty station, with Alaska's statutory geographic differential applied (AS 39.27.020).
| Name | Required | Description | Default |
|---|---|---|---|
| step | No | step letter, default A | |
| range | Yes | salary range, e.g. '16' | |
| duty_station | No | e.g. Anchorage, Juneau, Bethel, Kotzebue |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read-only operation ('lookup') but does not explicitly state safety, rate limits, or side effects. The mention of statutory geographic differential adds some behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Front-loads key information (official GG-schedule, geographic differential). Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description only says 'pay' without detailing return format, units, or additional columns. Adequate but could be more complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaning by specifying the geographic differential application and the combination of range+step+duty station beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes pay using GG-schedule with geographic differential. The title 'State of Alaska salary schedule lookup' and sibling names (e.g., get_salary_data, search_jobs) show it is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid using this tool vs. siblings like get_salary_data. The context suggests it is for schedule lookups, but alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_jobsSearch Alaska public-sector jobsCInspect
Search open Alaska government, legislative, campaign, policy, municipal, federal, and nonprofit job listings. All filters optional.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | keywords matched against title, employer, and description | |
| region | No | ||
| remote | No | only remote/hybrid-eligible jobs | |
| category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral context. It does not disclose pagination (limit parameter), result ordering, or output format (e.g., list vs single item). Minimal additional value beyond the action verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, front-loaded with the core action. However, it omits important context like result format, which could have been included without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is too sparse. Missing: return type, result structure, ordering, filtering behavior. Leaves significant gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameter beyond saying filters exist. Schema coverage is 40% (only query and remote have descriptions in schema). The description adds no per-parameter meaning, leaving 60% of parameters (limit, region, category) entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for various types of Alaska public-sector jobs, listing specific categories. It differentiates from sibling tools (specific retrievals) by being a general search. However, it does not explicitly state that it returns a list of job matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions 'All filters optional' but provides no guidance on when to use this tool versus alternatives like get_job or get_employer. No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!