Remoote Remote Jobs MCP
Server Details
Search remote jobs, compare salaries, create alerts, and request user-confirmed apply links.
- 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.5/5 across 6 of 6 tools scored. Lowest: 2.9/5.
Each tool has a distinct purpose: job retrieval, search, popular jobs, salary stats, alerts, and apply intents. No overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_alert, get_job, search_jobs), making the set predictable.
6 tools cover core remote job operations without being excessive or insufficient for the domain.
Covers discovery, search, job details, alerts, and apply intent. Missing alert management (update/delete) is a minor gap.
Available Tools
6 toolscreate_alertBInspect
Create a daily or weekly Remoote job alert for the authenticated user. Requires the alerts:write scope.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | ||
| criteria | Yes | ||
| frequency | No | daily |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description solely states it creates an alert and requires scope. It omits behavioral details such as idempotency, creation confirmation, response format, rate limits, or whether duplicate alerts are allowed.
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 sentence, achieving conciseness. However, it is too brief to be fully informative; it sacrifices completeness for brevity.
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 output schema, no annotations, and only basic purpose, the description lacks information on return values, success/error handling, and how alerts function. It is incomplete for an agent to use confidently.
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%, yet the description adds no parameter details. It does not explain the meaning or usage of name, limit, criteria, or frequency, leaving agents without guidance on how to fill them.
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 creates a daily or weekly Remoote job alert for the authenticated user, specifying verb, resource, and scope requirement. It distinguishes from sibling tools like search_jobs or get_job, which are read-oriented.
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 explicitly mentions the required scope (alerts:write), providing a prerequisite. It implies usage for setting up recurring job notifications, but lacks explicit when-not-to-use guidance or comparisons with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_apply_intentAInspect
Create a user-confirmed Remoote apply redirect for an authenticated agent token. Requires the apply:intent scope and never returns raw employer apply URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes creation of a redirect, requires user confirmation and scope, and states what it does not return. However, missing details on error handling, return format, or side effects. With no annotations, description carries full burden but is incomplete.
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 concise sentences, no fluff. Front-loads the core action and includes important constraints without wordiness.
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?
Covers scope and behavioral constraint, but lacks output schema or return type info. Agent is left guessing what the redirect response looks like. For a simple tool with one parameter, more completeness would be expected.
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 single parameter `job_id` has no description in the schema (0% coverage) and the description does not mention it at all. The parameter name alone is somewhat informative but no additional semantics are provided.
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?
Clearly states the tool creates a 'user-confirmed Remoote apply redirect', specifying the verb 'create' and the resource 'apply redirect'. Distinguishes from sibling tools (e.g., get_job, search_jobs) by focusing on the apply flow.
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 mentions the required scope 'apply:intent' and a key behavioral constraint ('never returns raw employer apply URLs'), guiding the agent on prerequisites and expected behavior. Lacks explicit when-not-to-use but siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jobAInspect
Fetch public details for one active Remoote job, including salary, location, skills, excerpts, and a Remoote job URL.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
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 burden. It correctly indicates a read-only fetch (no mutation) and lists response contents. However, it does not disclose error behavior or conditions for inactive jobs.
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 sentence with no wasted words, covering key elements (verb, resource, output fields) efficiently.
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 exists, but the description lists key fields (salary, location, skills, excerpts, URL). It is sufficient for a simple fetch but lacks details on error handling or pagination (not applicable).
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%, so the description must clarify parameters. It mentions 'one active Remoote job' implying job_id is the identifier but does not explain its origin or additional constraints beyond the schema.
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 verb 'Fetch' and the resource 'public details for one active Remoote job', listing specific fields. It distinguishes from siblings like search_jobs (multiple jobs) and other actions.
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 for fetching a single job by ID but does not explicitly state when to use this tool over alternatives like search_jobs. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_salary_statsCInspect
Return salary stats for active Remoote jobs matching supported filters when enough normalized compensation data exists.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| region | No | ||
| skills | No | ||
| country | No | ||
| seniority | No | ||
| company_id | No | ||
| location_tag | No | ||
| exclude_skills | No | ||
| employment_type | No | ||
| salary_required | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions only that data must be sufficient and focuses on active jobs, but omits details like authentication needs, error handling if data is insufficient, or rate limits. This is minimal transparency.
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 sentence that quickly states the core purpose. It is efficient but could benefit from slight expansion without losing 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?
Given 10 parameters, no output schema, and no annotations, the description is highly incomplete. It fails to describe the return format, the types of stats, or how filters affect the result, making it insufficient for an agent to use reliably.
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% for 10 parameters, yet the description adds no explanation of any parameter. The general statement about 'supported filters' does not clarify the 10 parameters' meaning or usage.
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 it returns salary stats for active Remoote jobs with filters and a condition on data sufficiency. This distinguishes it from sibling tools like search_jobs, which return job listings.
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 this tool versus alternatives. The condition 'when enough normalized compensation data exists' is mentioned but not elaborated, and no exclusions or comparisons with sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_top_jobsAInspect
Return a capped public list of currently popular Remoote remote jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'capped public list,' implying limited results and public access, which are key behavioral traits. However, it does not disclose authentication needs, rate limits, or the nature of 'popularity' (e.g., recency, views). No annotations exist to supplement, so the description provides basic but insufficient detail.
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, concise sentence (10 words) with no extraneous information. Every word contributes to understanding the tool's core function.
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's simplicity (one optional parameter, no output schema), the description covers the essential purpose. However, it lacks details on return format (e.g., job objects with fields) or ordering criteria (e.g., by popularity). The absence of an output schema increases the need for such context in the description.
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,' has no schema description (0% coverage). The description hints at 'capped' but does not explicitly explain that 'limit' controls the maximum number of jobs returned. It adds marginal context beyond the schema's default/min/max values.
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 returns a capped public list of currently popular remote jobs. It specifies the verb (Return), resource (list of popular remote jobs), and key attributes (capped, public, current). This distinguishes it from siblings like 'search_jobs' (searching) and 'get_job' (single job).
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 guidance is provided on when to use this tool versus alternatives such as 'search_jobs' for targeted searches or 'get_job' for specific job details. The description lacks context on preferring this tool for trending jobs without filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_jobsAInspect
Search active Remoote remote jobs. Returns capped public results with canonical Remoote URLs and no raw employer apply URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| region | No | ||
| skills | No | ||
| country | No | ||
| seniority | No | ||
| location_tag | No | ||
| exclude_skills | No | ||
| employment_type | No | ||
| salary_required | No |
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 results are capped and return canonical URLs without raw apply URLs, but does not cover other behaviors like rate limits, read-only nature, or authorization needs.
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 extremely concise at two sentences with no redundant information. Every word adds value, making it easy to scan.
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 10 parameters, no output schema, and no annotations, the description lacks completeness. It does not explain return structure, pagination, error handling, or parameter interactions, leaving the agent underinformed.
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 does not explain any of the 10 parameters. While parameter names are somewhat self-explanatory, the description adds no value to clarify their usage or constraints, which is a significant gap.
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 verb 'search' and the resource 'active Remoote remote jobs'. It distinguishes from siblings like get_job and get_top_jobs by mentioning 'capped public results' and the nature of URLs.
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 minimal guidance on when to use this tool vs alternatives. While it implies this is for general searching of public jobs, it does not explicitly state when not to use it or compare to sibling tools like create_alert or create_apply_intent.
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!