Is this company actually hiring, or is the board just still up? Real dates on 187,923 roles.
Average 3.8/5 across 6 of 6 tools scored.
Each tool answers a clearly distinct question: company-specific verdict, fresh boards, quiet boards, market-level stats, job search, and change tracking. There is no meaningful overlap between tool purposes.
Four tools follow a verb-first pattern (check_company, find_fresh_boards, find_quiet_boards, search_jobs), but hiring_stats is a noun phrase and whats_changed is question-style. The names are readable but not fully predictable.
Six tools is well-scoped for a hiring intelligence server. Each tool covers a distinct aspect of the domain without redundancy or bloat.
The surface covers the core workflows: searching jobs, evaluating a single company, surfacing fresh versus quiet boards, viewing market stats, and monitoring changes. No obvious dead ends or missing critical operations for the stated purpose.
check_companyAInspectAsk whether a company is ACTUALLY hiring, not just whether it has jobs listed. Returns a verdict on the board -- actively_hiring, still_open, gone_quiet or likely_abandoned -- with the age of the newest posting, the median role age, and how many reqs have sat open over 90 days and over a year. This is the check that tells you whether an application or a sales approach is worth the time.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the return verdicts, the age metrics, and the 90-day/year thresholds, giving an agent a solid understanding of what the tool computes and returns.
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, front-loaded with the core distinction, followed by concrete output details and a clear use case. Every sentence earns its place with no filler.
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 one-parameter tool with no output schema, the description is nearly complete: it lists the verdict values, the metrics returned, and when to use it. It could add a bit more context on how to interpret each verdict, but nothing essential for calling the tool correctly is missing.
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 description coverage is 100%, so the schema already documents the only parameter ('company'). The description adds no additional parameter meaning, but it does not need to; this is the baseline case where the schema carries the weight.
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 states a specific verb ('Ask whether') and resource ('a company'), and immediately differentiates itself from tools that only check for listed jobs. The verdict categories make the tool's function unmistakable and distinguish it from sibling tools like 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 gives clear context: use this check to decide whether an application or sales approach is worth the time. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_fresh_boardsBInspectCompanies where EVERY currently open role was posted in the last 30 days -- no backlog of applicants ahead of you, and usually a team that just started hiring. For sales, a company that just opened its first roles in a function is one whose budget has recently moved.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It clearly discloses the selection logic and the implications of the results. However, it doesn't mention whether results are sorted, paginated, or limited, nor does it state the output format or any implicit read-only guarantee.
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 and wastes little space. The core criterion is front-loaded, and the additional sales context earns its place by explaining why a 'fresh board' matters in a specific domain. It is compact and readable.
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 tool with one optional parameter and no output schema, the description gives a clear conceptual model of what is returned and why it is useful. However, it is incomplete on parameter meaning and does not describe the shape of results, ordering, or any limits. These gaps are significant but not fatal for a low-complexity 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 only parameter, limit, is an integer with no schema description, and the description does not mention it at all. Schema description coverage is 0%, so the description should compensate, but it doesn't. An agent can guess that limit caps the number of results, but the tool description provides no explicit semantics.
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 identifies what the tool does: find companies where every currently open role was posted in the last 30 days. It gives a specific, testable criterion and implies a read-only list operation. It doesn't explicitly name sibling tools, but the 'fresh' vs 'quiet' contrast with find_quiet_boards gives implicit differentiation.
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 conveys when this tool is valuable: when you want no backlog of applicants and a team that just started hiring. The sales-specific sentence adds practical context for one use case. It does not explicitly state when not to use it or name alternatives, but the usage context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_quiet_boardsBInspectCompanies still advertising open roles while having posted nothing new in over six months. Strong evidence of a board nobody tidied up after the hiring finished. Useful for striking dead accounts off a prospect list, or for avoiding applications that will never be read.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavior disclosure. It adds useful interpretive context ('strong evidence of a board nobody tidied up'), but it does not state that the tool is read-only, describe output format, or mention pagination or limits.
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?
Three concise sentences: the first defines the selection criteria, the second explains the signal, and the third gives practical use cases. Every sentence earns its place and the key definition is front-loaded.
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?
The description covers the purpose and practical usefulness of the tool well. It is weaker on the sole parameter's meaning and on alternative routing among siblings, but the low complexity and the inferable return type keep it reasonably complete.
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 description coverage is 0%, and the description completely ignores the 'limit' parameter. The agent only knows it is an optional integer, not what it limits or how it affects results, which is a real gap for a one-parameter tool.
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 identifies the resource: companies with open roles but no new posts in over six months. It implies a look-up operation, but there is no explicit verb and no direct contrast with the obvious sibling find_fresh_boards.
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?
It gives concrete use cases: removing dead accounts from a prospect list or avoiding applications that won't be read. However, it never mentions alternatives or says when not to use this tool, so the usage guidance stays implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hiring_statsAInspectMarket-level hiring numbers measured this morning across every board we read: employers hiring, open roles, how many went up in the last 24 hours, how many have been open over 90 days and over a year, how many boards have gone quiet, and the most in-demand technologies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 freshness ('measured this morning'), scope ('across every board we read'), and the exact data points, which strongly implies a read-only aggregate query. It does not explicitly state that it is read-only, nor does it mention output format, caching, or rate considerations, leaving some room for inference.
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 a single, dense sentence with the core purpose front-loaded and the specific metrics delivered via a clear colon-led list. Every element contributes meaningfully, though the sentence is long; the length is justified by the number of metrics covered.
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 no-parameter, no-output-schema aggregate stats tool, the description is largely complete: it names the metrics, the freshness of the data, and the coverage ('every board we read'). It stops short of describing the return format or container, but with zero inputs and enumerated data points this is likely sufficient for correct invocation.
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 tool has zero parameters, so the baseline is 4. The description adds useful context about the data domain an agent can expect (hiring numbers, board activity, technology demand), even though no parameter-level semantics are applicable because the input schema is empty.
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 states a specific purpose: providing market-level hiring numbers across all boards read, and enumerates concrete metrics (open roles, 24h increases, 90-day/1-year openings, quiet boards, in-demand technologies). The 'market-level' scope clearly differentiates it from company- or board-focused siblings like check_company, find_quiet_boards, and 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 usage context is implied through 'market-level' and the aggregate metrics, suggesting it is for broad hiring overviews rather than company- or board-specific lookups. However, there is no explicit statement of when to use this tool versus siblings, nor any exclusion like 'for a specific employer, use check_company instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_jobsAInspectSearch open job postings read directly from employers' own Greenhouse, Ashby and Lever boards. Unlike a job board, every result carries the employer's real publish date and age in days, so you can tell a role posted this morning from one that has been open two years.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25) | |
| query | No | Words in the job title, e.g. 'staff backend engineer' | |
| remote | No | Only roles flagged remote | |
| location | No | Any part of the location string, e.g. 'Berlin', 'California' | |
| department | No | Function, e.g. 'Engineering', 'Sales' | |
| technology | No | Technology named in the posting, e.g. 'Python', 'Kubernetes' | |
| max_age_days | No | Only roles posted within this many days | |
| min_age_days | No | Only roles OLDER than this many days -- use to hunt stale listings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does more than repeat the name: it states the data source (direct from employer ATS boards), and discloses that every result includes the employer's real publish date and age in days. It could add pagination/ordering/coverage caveats, but the disclosed behavior is specific and useful.
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 with no filler: the first states the operation and source, and the second explains the differentiating value with a concrete example. Every sentence earns its place and the key information is front-loaded.
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 tool with 8 optional parameters and no output schema, the description gives enough context to select the tool but not a complete picture: it omits result shape beyond date/age, ordering, pagination, and how filters interact. The self-documenting schema covers parameters, so this is acceptable but not comprehensive.
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%, so parameters like query, location, and max_age_days are already self-documented. The description's age-in-days emphasis supports min_age_days and max_age_days, but it doesn't add meaning beyond what the schema already provides.
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 identifies the action ('Search') and resource ('open job postings') and adds meaningful source detail (employers' own Greenhouse, Ashby and Lever boards). It does not explicitly contrast with siblings like find_fresh_boards or check_company, so it misses the top bar for sibling differentiation.
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 freshness example implies a use case (distinguishing newly posted roles from stale ones), and the source statement defines what kind of results to expect. However, there is no explicit guidance about when to prefer search_jobs over sibling tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whats_changedAInspectWhat actually MOVED, on a list of companies you name or across the whole record. Answers the question a person with a book of accounts has every morning: which of mine changed, and is anyone suddenly ramping? Returns NET movement, because a company that opened 342 roles and closed 317 is churning and one that opened 261 and closed 41 is hiring -- and flags a board whose VERDICT flipped, which is a budget unfreezing and the strongest signal in this data.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window, default 7 | |
| limit | No | ||
| companies | No | Company names to watch. Omit for the whole market. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that it returns NET movement (not gross) and explains the rationale with concrete examples, and it discloses the verdict-flip flag as a special signal. This goes beyond a simple 'returns changes' and gives the agent insight into the tool's logic and output semantics.
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 front-loaded with the core purpose ('What actually MOVED') and each sentence adds value. It includes a vivid metaphor and examples that clarify the net-movement logic, but it is slightly verbose. Still, it is well-structured and not padded with irrelevant details.
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 3-parameter tool with no output schema, the description covers the key behaviors (net movement, verdict flip) and the main use case. It does not detail the exact return structure or pagination, but it likely suffices for an agent to call it correctly. The 'limit' parameter remains ambiguous, but overall the description is fairly complete.
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 67% (days and companies documented, limit not). The description adds meaning for 'companies' by mentioning 'on a list of companies you name or across the whole record', which explains the omit behavior. However, it does not explain 'days' or 'limit' beyond what the schema provides (days has a default, limit undefined). It partially compensates but leaves gaps.
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 states a specific verb ('MOVED', 'Returns NET movement', 'flags') and a clear resource (changes on named companies or the whole record). It distinguishes itself from siblings by focusing on movement and net change, with a clear user story (book of accounts, morning check). Even without naming alternatives, the purpose is unmistakable.
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 a clear usage context: to find which companies changed and whether anyone is ramping. It describes the exact question it answers ('which of mine changed, and is anyone suddenly ramping?'), giving a concrete scenario. It does not explicitly name alternatives or exclusions, but the context is strong enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Verified job search: every listing confirmed live and accepting applicants within the last 72h.
Search a live index of millions of open jobs from employer career sites and 100+ ATS platforms.
Read job postings live from employer career sites across 10 applicant tracking systems.
Fresh company, employee, and jobs records in real time.
