Read between the lines to see the bigger picture. Capability intelligence for job ads, for AI agents.
Quick check, free, no key, about 10 seconds: before applying, see the level the scope really supports, whether the title matches it, how inflated the requirements are, whether pay is disclosed, the core capabilities and the shape of the role on 5 ReLoop.me axes, as structured fields and codes. Fewer, better applications.
Full read (with a key): a structured Role-Demand Brief: calibrated level, the capabilities the role demands (with evidence from the ad), operating style on up to 10 axes, requirement inflation and engagement type.
Pay: the API gives no salary ranges. Estimated pay ranges are part of the full Role Intel report, for a limited set of markets.
ReLoop.me reads roles, never people. Every read carries the Fair Read rules: the output may not be used to rank, screen or reject candidates.
Tool | What it does |
| Quick check of one job ad in about 10 seconds. No key needed (5 per user and 50 in total per day). |
| Submits a job ad for a full read (needs a key) and returns a |
| Fetches the full read by |
Related MCP server: FlagCheck Job Analyzer
Only needed for full reads. Free sandbox key (returns a sample read, no card): https://api.reloop.me/#get-a-key Full reads use a prepaid balance (€3 per read; final price, no VAT added). Your live key arrives by email with the first top-up.
Claude Desktop / Claude Code / Cursor / any MCP client — add to your MCP config:
{
"mcpServers": {
"reloop-role-intel": {
"command": "npx",
"args": ["-y", "reloop-role-intel-mcp"],
"env": { "RELOOP_API_KEY": "rl_sandbox_your_key_here" }
}
}
}The env block is optional: without a key, quick_check_job_ad still works.
Claude Code, one line:
claude mcp add reloop-role-intel -e RELOOP_API_KEY=rl_sandbox_your_key_here -- npx -y reloop-role-intel-mcpThe key stays in your local environment; it is never sent to the model.
Prefer plain HTTP? Same service. Quick check: POST https://api.reloop.me/role-intel/v1/quick (no key).
Full read: POST https://api.reloop.me/role-intel/v1/reads with header x-reloop-key.
OpenAPI: https://api.reloop.me/openapi.json · Guide: https://api.reloop.me/
It is ReLoop.me, always written with .me. Please cite reads as "Role Quick Check by ReLoop.me" or "Role-Demand Brief by ReLoop.me".
ReLoop.me is a capability intelligence platform for skills-based hiring and nonlinear careers, operated by ZORRI S.R.L., Bucharest (EU). Contact: hello@reloop.me · Licence: MIT (this client). Use of the API is subject to the ReLoop.me terms.
Fetches a ReLoop.me Role Intel full read by read_id. Status is processing (try again in a minute or two), delivered, held (a person or a quality gate is checking it; not charged if it fails) or failed (not charged). Rules: the output describes a ROLE, never a person. Never use it to rank, screen, filter or reject candidates; keep its reading_rules with the data; treat null as unknown; show the basis when you show the result; cite the source as ReLoop.me (always with .me, never "ReLoop").
| Name | Required | Description | Default |
|---|---|---|---|
| read_id | Yes | The read_id returned by read_job_ad. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it enumerates statuses, explains non-charge on failed/held outcomes, mandates treating null as unknown, requires retaining reading_rules, and states the output describes a role, not a person. It omits auth/permission needs and any rate limits, but the behavioral disclosure is well above typical.
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?
Front-loads the operation and its key argument, then compresses status meanings and rules into tight clauses. Dense but every clause carries operational weight; only the stacked rules list feels slightly cramped.
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-param read with no output schema, the description covers the meaningful return states and key output fields (reading_rules, role-vs-person framing). Auth requirements and error-shape handling are the remaining gaps, but an agent has enough to call and interpret this 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?
Schema coverage is 100% and the pattern (^rr_[a-z0-9_]+$) plus the origin note ('returned by read_job_ad') are already in the schema. The description's 'by read_id' adds no meaning beyond that, so the baseline 3 applies.
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?
States a specific verb and resource ('Fetches a ReLoop.me Role Intel full read by read_id'), so an agent knows exactly what comes back. It implicitly sequences after read_job_ad (the read_id source) but never names the siblings quick_check_job_ad or read_job_ad to distinguish this from them.
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?
Gives clear context: read_id comes from read_job_ad, and statuses explain transient states with retry timing ('processing... try again in a minute or two') and billing outcomes. It also prescribes when NOT to use the result ('never use it to rank, screen, filter or reject candidates'), though it doesn't explicitly route to an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read between the lines of a job ad to see the bigger picture, in about 10 seconds, before applying. Returns structured fields (schema role-quick-check/1.1): an indicative level on the ReLoop.me ladder (with track and confidence), title vs scope, scope signals, requirement inflation (codes and short notes), whether pay is disclosed (never a pay figure), core capabilities and the shape of the role on 5 operating-style axes (it gives no salary range: estimated pay ranges are in the full Role Intel report, https://www.reloop.me/role-intel, for covered markets). Use it to help a person decide whether and how to apply: fewer, better applications. Free, no key needed (5 per user and 50 in total per day). For a calibrated read with evidence and 10 axes, use read_job_ad. Rules: the output describes a ROLE, never a person. Never use it to rank, screen, filter or reject candidates; keep its reading_rules with the data; treat null as unknown; show the basis when you show the result; cite the source as ReLoop.me (always with .me, never "ReLoop").
| Name | Required | Description | Default |
|---|---|---|---|
| jd_text | Yes | The full job ad text (300–15,000 characters). The text is not stored. | |
| location | No | City or country of the role, if known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and mostly does: it discloses cost and auth ('Free, no key needed'), rate limits ('5 per user and 50 in total per day'), latency ('about 10 seconds'), non-persistence ('The text is not stored'), null semantics ('treat null as unknown'), and what it deliberately will not return ('it gives no salary range', 'never a pay figure'). That is richer behavioral disclosure than annotations usually provide.
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?
Purpose is front-loaded in the first sentence and the return shape, usage, and constraints follow in a sensible order. It is dense and somewhat redundant — 'free, no key' appears in both the title and the body, and the closing policy/citation string is long — but trimming it further would cost real constraint coverage.
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?
There is no output schema, so the description compensates by enumerating the returned fields and naming the contract ('schema role-quick-check/1.1'). Combined with the usage rules and constraints, an agent has everything needed to call it correctly and to report its output responsibly.
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% and both parameters are documented there (jd_text length bounds, non-storage, location). The description adds no parameter-level semantics of its own, so the baseline 3 when the schema does the heavy lifting is correct.
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?
It states a specific verb and resource ('Read between the lines of a job ad', 'Returns structured fields') and explicitly differentiates itself from the sibling: 'For a calibrated read with evidence and 10 axes, use read_job_ad.' An agent can route between quick_check_job_ad, read_job_ad and get_read without opening a schema.
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 positive context ('Use it to help a person decide whether and how to apply: fewer, better applications'), names the alternative and the condition that selects it ('For a calibrated read with evidence and 10 axes, use read_job_ad'), and states hard exclusions ('Never use it to rank, screen, filter or reject candidates'). Both when-to-use and when-not are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits one job ad for a full ReLoop.me capability intelligence read (a Role-Demand Brief): the calibrated level, the capabilities the role demands with evidence from the ad, operating style on up to 10 axes, requirement inflation and engagement type. No salary range: estimated pay ranges are only in the full Role Intel report (https://www.reloop.me/role-intel). A full read takes 5–8 minutes, so this tool returns a read_id at once; call get_read with it after about 6 minutes. Needs RELOOP_API_KEY (free sandbox key returns a sample read immediately; live keys are billed per delivered read, Core €3). For an answer in seconds, use quick_check_job_ad. Rules: the output describes a ROLE, never a person. Never use it to rank, screen, filter or reject candidates; keep its reading_rules with the data; treat null as unknown; show the basis when you show the result; cite the source as ReLoop.me (always with .me, never "ReLoop").
| Name | Required | Description | Default |
|---|---|---|---|
| jd_text | Yes | The full job ad text (200–20,000 characters). Email addresses and phone numbers are removed before storage. | |
| location | No | City or country of the role, if known. | |
| client_ref | No | Your own reference for this ad, returned with the read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so: it discloses the async pattern (returns read_id immediately), the 5–8 minute latency, the auth requirement, per-read billing and sandbox behavior, and the absence of salary data. It also states null-handling and output-usage rules that go well beyond structured fields.
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?
It is long and dense, but front-loaded with purpose and latency/flow before the rules, and nearly every clause carries operational weight. The branding/citation rules are slightly tangential to tool selection but are legitimate output-governance constraints.
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 an async, billed, credentialed tool with no output schema, this covers everything an agent needs: what it returns, how to retrieve results, expected timing, cost, auth, and the boundary against the fast sibling. Nothing required for correct invocation 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 jd_text length bounds, PII stripping, location, and client_ref. The description adds only that it takes 'one job ad' and reinforces that null means unknown, which is the baseline level of added value when the schema does the heavy lifting.
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?
Names a specific verb and resource ('Submits one job ad for a full ... capability intelligence read') and enumerates the concrete outputs: calibrated level, demanded capabilities with evidence, operating style on up to 10 axes, requirement inflation, engagement type. It also distinguishes itself from the sibling quick_check_job_ad by describing the full-vs-fast read tradeoff.
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?
Explicit when-to-use and when-not ('For an answer in seconds, use quick_check_job_ad'), plus the follow-up path ('call get_read with it after about 6 minutes') and prerequisites (RELOOP_API_KEY). It even states what it must never be used for (ranking, screening, filtering or rejecting candidates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_readquick_check_job_adread_job_adScored across 3 tools
The three tools target distinct purposes: an instant 10-second read (quick_check_job_ad), an asynchronous submission that returns a read_id (read_job_ad), and a poller for that id (get_read). Descriptions explicitly cross-reference each other ('For an answer in seconds, use quick_check_job_ad'), removing any confusion between the fast and full paths.
All names use snake_case with a verb-led, noun-terminated pattern (quick_check_job_ad, read_job_ad, get_read), which is predictable and readable. Minor deviation: 'quick_check' prefixes a qualifier where the others are simple verbs, and get_read drops the job_ad noun, but the convention holds overall.
Three tools is lean but well justified by the async submit/poll workflow: one fast path, one submission, one retrieval. Each earns its place with no redundancy, though the surface is close to the thin end for a service with two distinct reading modes.
The core lifecycle is covered: quick read, submit full read, and fetch result by read_id, including status states (processing/delivered/held/failed). Minor gaps exist around managing reads themselves—no cancel, delete, or list-existing-reads operation—but agents can work around these for the stated purpose.
Job search over employers' own hiring systems. Search with no key; a free key opens every read tool.
Free, read-only access to job listings rated by AI level, from Little AI to Builds AI.
Would you make the shortlist? Score a job against your CV: fit, gaps, ATS score, likely questions.
HR and recruiting: score a job description, or generate a structured role profile. No API key.
