A
license-
qualityB
maintenanceExposes a public, read-only professional profile with tools to search resume evidence, fetch curated links, and generate career briefs for LLM agents.
MIT
Rung public career guides
by guru.rung
Server Details
Find public career guides, explore grounded occupations, and open Rung for private resume work.
- 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.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4/5.0
Tool DescriptionsA
Average 4/5 across 2 of 2 tools scored.
Server CoherenceA
Disambiguation5/5
The two tools have distinct purposes: find_public_guides searches for guides, while explore_occupation dives into the details of a specific occupation returned by the first. There is no overlap, and the dependency is clearly stated.
Naming Consistency5/5
Both tool names follow a consistent verb_noun pattern with underscores (find_public_guides, explore_occupation). The verbs are appropriate and the nouns clearly describe the target resource.
Tool Count4/5
With only two tools, the server feels slightly underpopulated for a general 'public guide search', but it covers the core workflow of finding and then exploring a guide. It is not excessive, and the scope is narrow enough to justify the small count.
Completeness2/5
The server only supports exploring occupations, but find_public_guides also returns resume-situation and military-to-civilian guides. There is no tool to explore those other guide types, creating a significant gap. Additionally, there is no way to retrieve a guide by ID or to list all occupations.
Available Tools
2 toolsexplore_occupationExplore a Rung occupationARead-onlyIdempotentInspect
Explore bounded examples of the public tasks, skills, and grounded tools for an occupation returned by find_public_guides. Examples are not claims about a person. Never pass a name, contact details, work history, resume text, selected skills, or other personal data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| soc | Yes | The exact published occupation code returned by find_public_guides. | |
| limit | No | ||
| offset | No | ||
| section | No | all | |
| language | No | en |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| caution | Yes | |
| privacy | Yes | |
| guideUrl | Yes | |
| sections | Yes | |
| startUrl | Yes | |
| occupation | Yes | |
| contentLanguage | Yes | |
| requestedSection | Yes | |
| requestedLanguage | Yes |
Tool Definition Quality
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey idempotent, read-only, non-destructive behavior. The description adds unique context beyond annotations: the examples are 'bounded', 'not claims about a person', and that personal data must never be passed. This helps the agent understand the scope and ethical use of the tool. Missing details like pagination behavior (offset/limit) are partially covered by the schema, so the description's additions are valuable but not exhaustive.
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 exceptionally concise—two sentences that front-load the core purpose, link to the sibling tool, and provide critical usage warnings (no personal data). No superfluous words or redundancy. Every sentence earns its place.
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?
Given the tool's complexity (5 parameters, 1 required, output schema exists), the description covers the high-level purpose and a critical constraint (no personal data) but fails to explain the parameters or the nature of the output. The output schema likely fills some gaps, but the description alone is incomplete for guiding an agent through parameter selection and interpretation.
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 20% (only the 'soc' parameter has a description). The tool description adds no information about any of the five parameters—not even the required 'soc' field beyond what the schema says. With low schema coverage, the description should compensate, but it entirely omits parameter meanings, defaults, or how they affect output. This is a significant gap for an agent trying to construct correct invocations.
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 clearly states the tool's purpose: exploring bounded examples of tasks, skills, and tools for an occupation returned by find_public_guides. It uses specific verbs ('explore') and nouns ('bounded examples', 'public tasks, skills, grounded tools') and distinguishes itself by referencing the sibling tool find_public_guides, making its role in the workflow clear.
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?
The description explicitly links the tool to find_public_guides, implying the prerequisite of calling that tool first. It also provides a strong 'when-not-to-use' instruction: never pass personal data like names, contact details, or work history. However, it does not elaborate on alternative scenarios or contexts where this tool should be preferred over others, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_public_guidesFind Rung public guidesARead-onlyIdempotentInspect
Find published Rung occupation, resume-situation, or military-to-civilian guides. Returns public facts, source pages, and browser handoffs only. Never pass a person's name, contact details, work history, resume text, or other personal data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | all | |
| limit | No | ||
| query | Yes | A public job title, occupation code, situation, military code, or military role. | |
| language | No | Language for occupation and situation guides. Military guides are currently English. | en |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| query | Yes | |
| privacy | Yes | |
| results | Yes | |
| requestedLanguage | Yes |
Tool Definition Quality
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context by specifying that it returns only public facts, source pages, and browser handoffs, and by warning against passing personal data. No contradiction with annotations.
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?
Two concise sentences, front-loaded with the core purpose, and every word adds value. The privacy constraint is important and follows naturally without bloat.
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 search tool with an output schema, the description covers purpose, privacy, and result scope well. However, it does not explain what 'browser handoffs' means or how this tool relates to the sibling 'explore_occupation', leaving a slight gap in completeness. Overall it is mostly sufficient.
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?
Schema has descriptions for query and language (50% coverage), but kind and limit lack descriptions. The description reinforces that the query must be public data and lists guide types that map to the 'kind' enum, providing some added meaning. However, it does not elaborate on limit behavior or kind values beyond the schema's enums/defaults, so the compensation is only partial.
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 uses a specific verb ('Find') and explicitly identifies the resource: published Rung occupation, resume-situation, or military-to-civilian guides. It also distinguishes itself from the sibling tool by focusing on finding guides rather than exploring occupations, and it clarifies the output type (public facts, source pages, browser handoffs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it finds, and it provides a strong privacy constraint ('Never pass a person's name...'). However, it does not explicitly state when to use this tool instead of the sibling 'explore_occupation', nor does it mention any exclusions or alternative tools. The context is clear but lacks comparative guidance.
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!
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides job search, local resume parsing, and resume-to-job matching via official APIs and local file processing.5MIT
- Alicense-qualityCmaintenanceEnables access to 200 compressed cybersecurity career profiles via tools for listing, searching, and invoking careers, supporting SOC, IR, pentest, GRC, IAM, and more.MIT
- AlicenseCqualityAmaintenanceEnables natural-language access to workspace-independent public job search, matching, and seeding tools, along with lazy job matching, while keeping private data and application state in a separate operator-owned workspace.4MIT