Hyreflow

by ai.hyreflow

Overview Discussions Admin

Server Details

Recruitment automation: source, enrich, qualify and sequence candidates, push to your ATS.

Ownership verified

Status: Healthy
Uptime: 88.7% over 23 days
OAuth: Works in Glama
Last Tested: 2026-10-08 16:08
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: automindz-solutions/hyreflow-plugins
GitHub Stars: 1

TDQS

A3.6/5.0

Scored 2026-10-07 13:31 across 18 tools

Disambiguation4/5

Most tools have clearly distinct purposes (e.g., dataset_read vs dataset_export, skills_list vs skill_read), but there is notable overlap between hyreflow_tools_execute and hyreflow_enrich_run, both of which can enrich rows of data. The detailed descriptions help differentiate them, but an agent could still misselect between the generic executor and the specialized enrichment runner.

Naming Consistency4/5

All tools share the hyreflow_ prefix and use snake_case, which is highly consistent. However, the internal pattern is mostly noun_noun (e.g., dataset_read, tools_execute) with a few verb_noun deviations (e.g., enrich_run, enrich_job) and some bare nouns (feedback, shortlist), making it slightly less uniform than an ideal verb_noun scheme.

Tool Count4/5

18 tools is slightly above the typical 3-15 range but remains reasonable for a platform covering billing, datasets, enrichment, shortlisting, skills, tools, and workflows. Each tool appears to serve a distinct function, though the count is on the higher side.

Completeness4/5

The surface covers core operations: dataset reading/exporting, enrichment running, shortlisting, skill/tool discovery, and workflow execution. However, there are minor gaps such as no tools for creating, updating, or deleting datasets/workflows, and no way to fetch a specific workflow run by ID beyond listing recent runs.

Available Tools

19 tools

hyreflow_billing_balanceB

Read-only

Inspect

Credit balance and recent spend for this workspace. Free.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact not in the annotations: the call is free (no credit consumed). It does not disclose the return shape or what window 'recent spend' covers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short fragments, front-loaded with the resource and the payload, no filler. It is arguably too terse to be maximally useful, but nothing is wasted.

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?

With no output schema, the description is the only source for what comes back, and it only gestures at 'balance and recent spend' without defining the window, currency, or response shape. For a trivial parameterless read this is minimally adequate, but it leaves real gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. No argument syntax or defaults are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource and data returned ('credit balance and recent spend for this workspace'), which is clearly distinct from the dataset, enrich, and workflow siblings. It stops short of an explicit verb, but 'balance and spend' unambiguously identifies a read of billing state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus other tools, nor any prerequisite or context statement. The reader must infer that it is for checking workspace billing status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_dataset_exportAInspect

Create a download link for a dataset's full CSV (ds_…): every row and every column, not a sample. The link opens in the browser signed in to Hyreflow; the response's instruction field explains what to do if the page asks to sign in or cannot find the dataset. Free.

ParametersJSON Schema

Name	Required	Description	Default
`dataset_id`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=false and openWorldHint=true, but the description adds real context beyond them: the link opens in a signed-in browser session, and the response carries an `instruction` field for sign-in/not-found cases. This is useful behavioral disclosure the structured fields do not provide.

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?

Three short sentences, front-loaded with the core action, then browser behavior, then cost. 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.

Completeness4/5

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 covers the return shape (link plus `instruction` field) and the sign-in caveat well. Only the parameter's exact semantics remain thin.

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?

With 0% schema description coverage, the description must carry parameter meaning. It does hint at the `dataset_id` format via the `ds_…` prefix, but does not otherwise explain the single required parameter. Partial compensation only.

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?

States a specific verb+resource ('Create a download link for a dataset's full CSV') and defines scope precisely ('every row and every column, not a sample'). This distinguishes it from the read/list siblings without needing to open their schemas.

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 'not a sample' contrast implicitly routes the agent away from a preview-style sibling, but there is no explicit when-to-use statement or named alternative. Usage is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_dataset_readA

Read-only

Inspect

Read a page of rows from a stored dataset (ds_…): at most 100 rows per call (default 25), paged with offset. The reply carries has_more and next_offset. format is json (default, row objects) or csv (the same rows as one CSV string, identical cells to the exported file and far fewer tokens). A dataset another workspace owns reads as 'dataset not found'. Free.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`format`	No
`offset`	No
`dataset_id`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring readOnlyHint/destructiveHint, the description adds substantial context: a hard 100-row cap with 25 default, offset-based paging, the `has_more`/`next_offset` response contract, cross-workspace access returning 'dataset not found', and that the call is free. These are the behavioral traits annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The paging constraint and defaults are front-loaded, and each clause carries information. It is dense for a single paragraph, but no sentence is filler given the 0% schema coverage it has to compensate for.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description names the return fields (`has_more`, `next_offset`) and the row shape for each format, plus the cross-workspace failure mode and cost. An agent has everything needed to page correctly and switch formats.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry all four parameters — and it does: `limit` (max 100, default 25), `offset` (paging), `format` (json row objects vs csv string, with defaults), and `dataset_id` (`ds_…` prefix, error semantics). No parameter is left ambiguous.

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?

States a specific verb and resource ('Read a page of rows from a stored dataset') with the `ds_…` identifier convention, and implicitly distinguishes itself from hyreflow_dataset_export by contrasting csv rows with 'the exported file'. An agent can identify the operation without opening the schema.

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?

Usage is implied by the format discussion (csv = fewer tokens, same cells as the export), steering token-conscious reads toward csv, but there is no explicit statement of when to use this over hyreflow_dataset_export or hyreflow_datasets_list. Adequate but leaves the routing decision to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_datasets_listA

Read-only

Inspect

List this workspace's stored datasets (ds_…), newest first. Any search or enrichment over 50 rows, and every workflow run's output, is stored as a dataset; the original response carries only a 5-row sample. Each entry has id, name, source, row_count and created_at. session_id narrows the list to one session; without it the whole workspace is listed. Free.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`session_id`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description adds ordering behavior (newest first), the exact fields returned per entry, and a cost hint ('Free') — all useful context beyond the structured data. It stops short of describing pagination behavior, which matters for a list tool.

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?

Four tight sentences, front-loaded with purpose and ordering, followed by the context that makes the resource meaningful, then scope semantics. Nothing is padding; even the one-word 'Free' earns its place as a cost signal.

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?

With no output schema, the description correctly enumerates the returned fields (id, name, source, row_count, created_at), and annotations cover the read-only nature. The only real gap is undocumented limit/offset behavior for a paginated list.

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 description coverage is 0%, so the description must carry all parameter meaning. It explains session_id well (narrows to one session; omitting it lists the whole workspace) but says nothing about limit or offset, leaving pagination semantics undocumented.

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?

States a specific verb and resource ('List this workspace's stored datasets (`ds_…`), newest first'), including the ID prefix convention that identifies the resource type. The explanation that datasets are the full-result store (vs. the 5-row sample in the original response) cleanly separates this from sibling tools like hyreflow_dataset_read and hyreflow_dataset_export.

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?

Explains when datasets exist ('any search or enrichment over 50 rows, and every workflow run's output') and clarifies the scoping choice between session_id and whole-workspace listing. It does not explicitly name alternatives such as dataset_read for fetching contents, so routing is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_enrich_jobA

Read-only

Inspect

Fetch an async enrichment job by provider and job id (the job handle on a still_enriching row). Returns status (pending | settled | failed | expired), credits charged, the email when settled, and the result. A still_enriching row is NOT a miss: its job usually settles within 1-2 minutes, so a pending status means check again later. A job that settles with no email skipped the chain's later providers for that row. Free.

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes
`provider`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/safe, but the description adds substantial context beyond them: the credit cost (free), the credits-charged field, the full status lifecycle (pending | settled | failed | expired), and the meaning of a settled-but-empty result. This is exactly the added behavioral value the dimension rewards.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with verb and resource, and each sentence carries operational value (polling guidance, no-email interpretation, cost). It is dense and somewhat long, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description itself documents the return shape (status, credits charged, email when settled, result) plus lifecycle and cost, so an agent knows both how to call it and what to expect. Nothing essential is missing for a two-parameter read tool.

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 coverage is 0% and both params are required, so the description must compensate. It explains job_id well as the `job` handle from a still_enriching row, but provider is left entirely unqualified with no accepted values or format, so half the parameter semantics remain undocumented.

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?

Specific verb (Fetch) plus resource (async enrichment job) and the identifying parameters (provider, job id). It further anchors the resource as 'the `job` handle on a `still_enriching` row', which distinguishes it from the job-creating sibling hyreflow_enrich_run without ambiguity.

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?

Gives strong operational context: a pending status means check again later, and a still_enriching row is not a miss. It stops short of explicitly naming the alternative tool or the exact polling cadence, but the when-to-use situation is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_enrich_runA

Destructive

Inspect

Run ordered enrichment steps over a list of rows, each row independently (the CSV-style, per-column executor). Returns a summary with a cost estimate, not raw rows. Rows come from rows, or from a stored dataset via input (its ds_ id), in which case the whole dataset is enriched into a NEW dataset (_meta.dataset_id). Enrichment adds data only; it does not screen or filter rows. The call waits about 20s: a longer run returns _meta.status: "running" and a run_id, and a call with only run_id returns its progress at no charge. A row still processing at the provider reads still_enriching, which ends that row's chain, and carries a job_id, a resume {tool, method, id_arg} and, when fetchable, a job {provider, job_id} handle. A still_enriching row is NOT a miss: its email is still being fetched and usually arrives within 1-2 minutes. _meta.pending counts such rows and _meta.instruction says how to re-check them (free) every _meta.poll_after_s seconds until _meta.pending is 0. Resending an identical run within 15 minutes returns the first one, charged 0. The quote's expected_credits is the typical cost; total_max_credits the worst case.

ParametersJSON Schema

Name	Required	Description
`rows`	No
`input`	No	A ds_ dataset id to enrich instead of `rows`.
`steps`	No	Ordered per-column steps: direct specs, wrapped with specs, or waterfall groups.
`run_id`	No	The `run_id` of an earlier call that returned running. Sent alone, it returns that run's progress (with user_prompt). Free.
`dry_run`	No
`user_prompt`	Yes	The user's request that drove this call, verbatim as they phrased it. Recorded with the run so its trace reads as the ask followed by the calls it drove.
`confirm_token`	No	The `confirm_token` returned by a previous identical call that came back `confirmation_required`. Required to run a call above the workspace's confirmation threshold.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations it discloses substantial behavior: the ~20s wait, the running/run_id return shape, the free run_id progress re-check, the still_enriching semantics and why it is not a miss, pending/poll_after_s polling, the 15-minute idempotency dedup charged at 0, and the expected_credits vs total_max_credits cost model. This is exactly the behavioral depth an agent needs for a long-running, billing-sensitive call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, output shape, and data source before the operational details, and each sentence carries real information. It is a dense single block with no formatting, which slightly taxes readability, but little could be cut without losing behavioral value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, open-world, credit-spending tool with no output schema, the description covers sourcing, mutation scope, timing/async behavior, partial-result semantics, polling, idempotency, and cost. Nothing essential to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 71% schema coverage the baseline is 3, and the description adds genuine meaning beyond the schema: `input` (ds_ id) enriches the whole dataset into a NEW dataset, and a run_id-only call yields free progress. It does not elaborate the steps spec structure (direct/with/waterfall), which remains largely schema-only.

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?

Opens with a specific verb and resource ('Run ordered enrichment steps over a list of rows') and self-differentiates as 'the CSV-style, per-column executor', which separates it from sibling job/workflow tools. It also immediately clarifies the output shape ('Returns a summary with a cost estimate, not raw rows'). An agent can identify this tool 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context: rows come from `rows` or a stored dataset via `input`, and a run_id-only call returns progress for free. However, it never names an alternative (e.g. hyreflow_enrich_job, hyreflow_workflow_run) or states when-not-to-use, so the selection guidance is 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.

hyreflow_extract_image

Read-only

Inspect

Turn AI Ark and LinkedIn profile-photo links into small embedded images (64px JPEG data URIs) for a hyreflow artifact page, which can't load images from other sites. Up to 100 links a call. Returns photos (link to image) and skipped (link to reason, such as an expired link). Free.

ParametersJSON Schema

Name	Required	Description	Default
`urls`	Yes

hyreflow_feedbackAInspect

Send feedback or a bug report to the Hyreflow team. Files a tracked issue that people on the team read, and returns its URL. A submission cannot be withdrawn. Free.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No
`message`	Yes
`repro_query`	No

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare it is not read-only, is open-world, and is non-destructive; the description adds meaningful context beyond that: the issue is read by humans on the team, a URL is returned, and critically 'A submission cannot be withdrawn' plus 'Free' (cost). The irreversibility disclosure is exactly the kind of behavioral trait an agent needs before submitting on a user's behalf.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the action, followed by outcome, durability, and cost. Every sentence carries information; 'Free.' is a terse fragment but communicates a real constraint.

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?

There is no output schema, and the description appropriately notes that a URL is returned, and annotations cover the safety profile. The gap is the wholly undescribed 'repro_query' parameter, which an agent on a bug-report path would plausibly need to fill correctly.

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 0% and the description compensates only marginally: 'feedback or a bug report' loosely maps to the 'kind' enum, but 'repro_query' is never explained and 'message' semantics are left implicit. With three undocumented parameters, the description does not fill the gap left by the schema.

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?

States a specific verb and resource ('Send feedback or a bug report to the Hyreflow team') and clarifies the mechanism: it files a tracked issue and returns its URL. No sibling tool overlaps with this function, so an agent can route to it unambiguously.

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?

Usage is implied by the description – an agent should call this when it or the user wants to submit feedback or a bug. However, there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives (there are none among siblings), leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_onet_lookupA

Read-only

Inspect

Resolve a job title to O*NET-SOC occupation codes, each with its official title and description. Matches marked loose ('rank dropped', 'root word') are approximate. The predictleads discover_job_openings method requires these codes as onet_codes. Free.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`title`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/openWorld/destructive, so the bar is lower. The description adds meaningful context beyond them: that some matches are approximate ('rank dropped', 'root word') and that the call is free, both of which affect how an agent should treat and cost the results.

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?

Purpose is front-loaded in the first clause, followed by match-quality caveat, downstream usage, and cost in three tight sentences with no redundancy. Every sentence carries distinct information.

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 read-only, 2-param lookup with no output schema, the description covers purpose, result shape, match reliability, and downstream usage well enough to call it correctly. The only real gap is the undocumented `limit` parameter.

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 0% for both parameters. `title` is self-evident from the purpose statement, but `limit` is never mentioned anywhere -- not in the schema, not in the description -- so its meaning and default must be guessed. The description does not compensate for the coverage gap.

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?

States a specific verb (Resolve) and resource (job title → O*NET-SOC occupation codes), plus what each result contains (official title and description). This is unambiguous and distinguishable from enrichment/skill siblings.

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?

Explains a concrete use case -- feeding `onet_codes` into predictleads discover_job_openings -- and notes the call is free, which helps an agent decide to invoke it. It gives no explicit alternatives or when-not-to-use conditions, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_shortlistA

Destructive

Inspect

Bulk-screen candidates against a job description: one structured decision per candidate, ranked by score, with a tier (tier_1 | tier_2 | no_fit | unscored) and per-category scores. Takes job_spec plus either candidates (up to 1000 row objects, e.g. what a CRM/ATS search returned) or input (a ds_ dataset id, for a larger pool). Rows need work history; a pool of sourcing stubs without it is refused. The question set is generated from the job spec once and reused for every later screen of it. The call waits about 20s: a finished screen returns the top 25 ranked rows (name, row, shortlist cell); an unfinished one (including every first screen of a new job spec, which also writes its questions) returns {run_id, status, progress, poll_after_s}, and a call with only run_id returns the ranking once ready, at no charge. Every row, full profile included, is stored in the dataset at _meta.dataset_id. Resending an identical screen within 15 minutes returns the first one, charged 0. dry_run: true quotes the cost without running. Charges credits.

ParametersJSON Schema

Name	Required	Description
`input`	No	A ds_ dataset id to screen instead of `candidates`.
`run_id`	No	The `run_id` of an earlier screen that returned unfinished. Sent alone, it returns that screen's progress or ranking. Free.
`dry_run`	No
`job_spec`	No	The job description text.
`min_score`	No
`questions`	No	A custom question set to use instead of the generated one.
`candidates`	No
`must_haves`	No	Hard requirements, each a pass/fail gate.
`user_prompt`	Yes	The user's request that drove this call, verbatim as they phrased it. Recorded with the run so its trace reads as the ask followed by the calls it drove.
`confirm_token`	No	The `confirm_token` returned by a previous identical call that came back `confirmation_required`. Required to run a call above the workspace's confirmation threshold.
`allow_thin_profiles`	No
`regenerate_questions`	No	Replace this job spec's stored question set.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavior beyond the annotations: it charges credits, `dry_run` quotes without running, identical resends within 15 minutes are deduped and charged 0, calls block ~20s then either return top 25 or a run_id polling handle, run_id-only calls are free, and every row is persisted at `_meta.dataset_id`. This is far more context than destructive/openWorld hints alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the core purpose and output shape come first, then input modes, then async/cost/idempotency behavior. Nearly every sentence carries distinct operational information, though the single-paragraph density is heavier than ideal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of explaining returns and does so (top 25 ranked rows with name/row/shortlist cell, versus run_id/status/progress/poll_after_s), plus the async and billing model. For a 12-parameter, nested, side-effecting tool this is unusually complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 67% schema coverage, the description meaningfully enriches the key parameters: `candidates` (up to 1000 row objects, e.g. CRM/ATS output), `input` (ds_ dataset id for larger pools), `run_id` (sent alone returns ranking free), and `dry_run` (cost quote). It leaves `min_score`, `must_haves`, `allow_thin_profiles`, and the confirm_token flow largely to the schema.

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?

States a specific verb and resource ('bulk-screen candidates against a job description') and immediately pins down the output shape (one structured decision per candidate, ranked by score, with a tier and per-category scores). This is far more specific than the sibling tools (enrich_job, skill_search, dataset_read) and lets an agent distinguish it without opening the schema.

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?

Gives explicit scenario guidance: pass `candidates` for CRM/ATS rows vs `input` for a larger ds_ dataset pool, send `run_id` alone to poll free, and note that a first screen of a new job spec always returns unfinished. It also states a when-not condition (thin sourcing stubs are refused). It does not name sibling alternatives, so it falls 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.

hyreflow_skill_readA

Read-only

Inspect

Return one skill document in full. skill alone returns that skill's SKILL.md; path selects a specific document (e.g. 'provider-playbooks/apollo.md'). Free.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No
`skill`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds a genuinely non-obvious behavioral trait — 'Free' (no billing/credit impact) — plus the scope of what is returned (the document in full).

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?

Three short sentences, front-loaded with the core action, then the parameter behavior, then the cost note. No filler; the terse 'Free.' earns its place.

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 two-parameter read tool with no output schema and annotations covering safety, this is nearly complete: it covers the action, parameter interaction, path format, and cost. Missing only the valid value domain for `skill` and whether `path` is relative to the skill root.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the load, and it does: it explains that `skill` alone resolves to that skill's SKILL.md while `path` selects a specific document, with a concrete format example ('provider-playbooks/apollo.md'). It stops short of saying what valid `skill` values look like (id, slug, name).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Return one skill document in full,' with the word 'one' implicitly scoping it against the sibling list/search tools. It does not name hyreflow_skill_search or hyreflow_skills_list explicitly, so the differentiation is inferable rather than stated.

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 explains the parameter combination (`skill` alone vs `skill` + `path`), which is useful operational guidance, but gives no explicit when-to-use-this-vs-siblings statement (e.g. read one known document vs search for one).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_skill_searchA

Read-only

Inspect

Search every Hyreflow skill document for a term (a provider name, a field, a capability). Returns the documents that mention it, with their matching lines. Free.

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes
`limit`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds beyond that: full-corpus scope ('every ... document'), the shape of the result ('matching lines'), and a cost disclosure ('Free') that matters given the hyreflow_billing_balance sibling. Missing details like ranking or pagination behavior keep it from a 5.

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 tight sentences with the verb and scope front-loaded, followed by the return contract and cost note. No filler; every clause carries information.

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?

There is no output schema, so the description correctly supplies the return shape (matching documents plus matching lines). It is nearly complete for a simple 2-parameter search tool, with the only gap being the undocumented limit parameter.

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 description coverage is 0%, so the description must carry parameter meaning. It does explain what q should contain (a provider name, a field, a capability), which is genuinely useful, but the limit parameter is left entirely unexplained in both schema and description.

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?

States a specific verb (Search) and resource (every Hyreflow skill document) with the searchable term types and the return shape ('documents that mention it, with their matching lines'). This functionally separates it from hyreflow_skills_list (enumerate) and hyreflow_skill_read (fetch one), so an agent can route correctly 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical examples ('a provider name, a field, a capability') imply when the tool is appropriate, and 'Free' hints at cost trade-offs versus the billing sibling. But no explicit when-to-use, when-not-to-use, or named alternative (e.g., skill_read for a known doc) is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_skills_listA

Read-only

Inspect

List the Hyreflow skill documents: recruiting playbooks, one provider playbook per vendor (access rules, payload shapes, known limits), pipeline recipes and sub-agent prompts. Free.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, covering the safety profile. The description adds that it is free and characterizes the documents, but says nothing about pagination, size, or format of the list. Adequate but not rich beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence front-loads the action and then enumerates the content, with 'Free' tacked on. Efficient, though the parenthetical is dense.

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 zero-parameter, read-only listing tool with annotations covering safety and openness, the description tells the agent what will be returned. Adequate; only return format details are absent, which is minor for a simple list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to explain; baseline 4 applies. The enumeration of document categories is content context rather than parameter guidance.

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?

States a specific verb (List) and resource (Hyreflow skill documents) and enumerates the content categories, which distinguishes it from siblings like hyreflow_skill_read and hyreflow_skill_search.

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?

Implies a discovery/enumeration use case and notes it is free, but does not say when to prefer this over hyreflow_skill_search or hyreflow_skill_read. No exclusions or conditions given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_tools_describeA

Read-only

Inspect

Describe one Hyreflow tool and its methods, or one method in full: expected payload, credit cost, usage notes, and the skill document that covers it. Free.

ParametersJSON Schema

Name	Required	Description	Default
`tool`	Yes
`method`	No

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description usefully adds that the call is free (no credit cost) and what the response contains, including the machine-consumable payload and the covering skill doc. It does not discuss auth or rate limits, but for a read-only descriptor that is a minor omission.

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?

A single front-loaded sentence with a colon-delimited list of return contents. No filler, no redundancy, and the core action precedes the payload enumeration.

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 two-parameter, read-only descriptor with no output schema, the description covers what is returned and the cost. The notable gap is not telling the agent where valid tool/method identifiers originate, which matters given a sibling tools_search exists.

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 description coverage is 0% for both parameters, so the description must carry the load. It partially does: 'one Hyreflow tool and its methods' implies the required `tool` selects the tool and the optional `method` narrows to a single method. It gives no format or sourcing hints (e.g., that tool/method names come from tools_search), so the coverage gap is only partly closed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (describe) and resource (a Hyreflow tool / one method), and enumerates the payload returned: expected payload, credit cost, usage notes, and covering skill document. It is clearly distinguishable from tools_execute or tools_search by intent, though it never names those siblings explicitly.

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 'tool and its methods, or one method in full' phrasing implies when to use the whole-tool form vs the method form, and 'Free' hints at cost considerations. However, it never states when to reach for this over hyreflow_tools_search or hyreflow_skill_read, leaving the routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_tools_executeA

Destructive

Inspect

Execute a Hyreflow tool method against live data providers. Charges credits at the described cost; dry_run: true returns a quote without running. Waterfall tools such as people_search take only payload. Enrichment waterfalls (email_enrichment, personal_email, linkedin_profile, phone_enrichment) also accept rows: up to 100 row objects enriched in one call, in place of payload and method. A row still processing at the provider comes back as still_enriching with a job_id, a resume {tool, method, id_arg} and, when the job is fetchable, a job {provider, job_id} handle. A still_enriching row is NOT a miss: its email is still being fetched and usually arrives within 1-2 minutes. _meta.pending counts such rows and _meta.instruction says how to re-check them (free) every _meta.poll_after_s seconds until _meta.pending is 0. A multi-row call stores its rows in a dataset (_meta.dataset_id), and a pending row completes in that dataset when its job finishes. Resending identical rows within about 15 minutes returns the first call's dataset at no charge (_meta.replayed); resending one pending row's payload starts and bills a new job. A call above the workspace's confirmation threshold returns confirmation_required with a cost estimate and a confirm_token instead of running.

ParametersJSON Schema

Name	Required	Description
`rows`	No
`tool`	Yes
`method`	No
`channel`	No	Pipeline the call serves: `work_email` (BD) or `personal` / `candidate`. A work-email-only finder (bettercontact) is refused on the personal channel.
`dry_run`	No
`payload`	No
`user_prompt`	Yes	The user's request that drove this call, verbatim as they phrased it. Recorded with the run so its trace reads as the ask followed by the calls it drove.
`confirm_token`	No	The `confirm_token` returned by a previous identical call that came back `confirmation_required`. Required to run a call above the workspace's confirmation threshold.

TDQS

A4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With destructiveHint=true and readOnlyHint=false already covered by annotations, the description still adds substantial behavioral context a caller needs: credits are charged at the described cost, dry_run is free, an identical rows payload replays free within ~15 minutes while a single pending row re-bills, and above-threshold calls return confirmation_required instead of executing. This is exactly the extra context the lower annotation bar rewards.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Core purpose and the dry_run/credits constraint are front-loaded in the first sentence, and the dense clauses each carry distinct operational facts. It is long and clause-heavy, so it is efficient rather than elegant, but nothing is padding.

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 complex 8-parameter dispatcher with no output schema, the description covers the important return shapes: still_enriching rows with job_id/resume/job handles, _meta.pending/instruction/poll_after_s, _meta.dataset_id, _meta.replayed, and confirmation_required. Little is left unexplained, though the role of the top-level tool/method pair relative to the rows path could be clearer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 38% over 8 parameters, so the description carries real weight. It explains that rows (up to 100) substitutes for payload and method on enrichment waterfalls, clarifies dry_run's quoting behavior, and contextualizes confirm_token via the confirmation_required flow. It leaves tool and method largely undefined and only lightly touches channel beyond the schema's own description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: 'Execute a Hyreflow tool method against live data providers.' That is far more than a restatement of the name, and the following sentences sharpen the scope (waterfall vs enrichment variants, rows vs payload). It stops short of 5 because it never distinguishes itself from execution-flavored siblings such as hyreflow_enrich_run or hyreflow_workflow_run, leaving the agent to guess which runner applies.

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?

It gives solid in-tool usage rules: dry_run returns a quote, waterfall tools take only payload, enrichment waterfalls accept rows, and above-threshold calls require confirm_token. What it lacks is explicit routing guidance against alternatives (enrich_run, workflow_run, dataset_read) or a when-not-to-use statement, so the agent must infer which entry point fits.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_tools_searchA

Read-only

Inspect

Search the Hyreflow tool catalog by intent (e.g. 'find software engineers at startups'). Returns matching tool names with their credit cost and whether they have side effects. Free. The catalog is in English: describe the intent in English whatever language the user wrote in.

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	The intent in English, e.g. 'find finance directors at fintech companies'.
`limit`	No

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds genuinely new context: the operation is free, and results include credit cost and a side-effect flag, which helps the agent reason about downstream calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core purpose, then return shape, then the language constraint. Each sentence carries information; only the English constraint is slightly repeated between description and schema.

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?

With no output schema, the description correctly explains what comes back (matching tool names with credit cost and side-effect flags). For a two-parameter read-only search tool this is nearly complete; only the limit parameter's behavior is unaddressed.

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 coverage is 50%: q is documented in the schema, but limit is undocumented in both schema and description. The description reinforces the English-intent constraint on q (already in the schema) and adds the cross-language nuance, but does not compensate for the unexplained limit parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search the Hyreflow tool catalog by intent') and gives a concrete example query, so the agent knows exactly what this does. It does not explicitly differentiate itself from siblings like hyreflow_tools_describe or hyreflow_tools_execute, which would be needed for a 5.

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?

Provides a real usage constraint ('describe the intent in English whatever language the user wrote in') and cost information ('Free'), which imply this is the entry point of a search→describe→execute flow. However, it never states when to use this versus hyreflow_tools_describe or hyreflow_tools_execute, leaving the routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_workflow_runA

Destructive

Inspect

Queue a run of a saved workflow in this workspace, by name or id. Returns the run id and initial status. A live run charges credits for the tools it calls.

ParametersJSON Schema

Name	Required	Description
`mode`	No
`input`	No
`workflow`	Yes
`user_prompt`	Yes	The user's request that drove this call, verbatim as they phrased it. Recorded with the run so its trace reads as the ask followed by the calls it drove.

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the description is not obliged to re-state the safety profile. It adds genuinely new behavior: a live run charges credits for the tools it calls, and it returns the run id plus initial status. It does not explain what dry_run or smoke_test actually do.

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?

Three short sentences, no filler, with the core action front-loaded and the cost caveat placed last where it matters most.

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?

The description covers the queued-run model, the accepted workflow identifiers, and the return shape, and there is no output schema to explain. However, for a destructive, credit-charging, open-world mutation with an unexplained mode enum, the omission of dry_run/smoke_test semantics and of what 'input' does leaves a real gap before an agent can call it correctly.

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 coverage is only 25%, so the description must carry the load, and it mostly does not. It clarifies that 'workflow' accepts a name or id, but the mode enum (live vs dry_run vs smoke_test) — the single most consequential parameter choice — and the nested 'input' object are left entirely unexplained; the credit note only obliquely implies what live means.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Queue a run of a saved workflow in this workspace, by name or id'), which is clearly distinct from the sibling hyreflow_workflow_runs list tool. It stops short of naming that sibling explicitly, so it is clear but not fully self-differentiating.

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 reader can infer this is the tool for kicking off an existing workflow rather than listing or defining one, and the credit caveat hints at cost trade-offs. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., preferring dry_run first, or using hyreflow_workflow_runs to poll).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_workflow_runsB

Read-only

Inspect

List recent runs of a workflow with their status and timing. Free.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`workflow`	Yes

TDQS

B3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description does add one behavioral fact not in structured data — the call is free — and hints at return content ('status and timing'), but says nothing about pagination, limits, or how 'recent' is bounded.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the resource and scope front-loaded and no filler. The terse 'Free' fragment is unconventional but does convey cost information efficiently.

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?

For a simple read-only list tool whose annotations carry the safety profile, the description covers purpose but leaves the required 'workflow' identifier format and limit semantics unspecified, and no output schema exists to fill the return-shape gap.

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 0%, so the description must carry the parameter burden and does not: it never explains whether 'workflow' is a name, ID, or slug, nor what 'limit' defaults to or caps at. Only the loosely implied association between the workflow and its runs is conveyed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource ('List recent runs of a workflow') and adds scope detail ('status and timing'). It is clearly distinct from the singular sibling hyreflow_workflow_run and from hyreflow_workflows_list, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus hyreflow_workflow_run or hyreflow_workflows_list, and no prerequisites or exclusions are stated. The only usage signal is the implied cost note 'Free', which is about pricing, not selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hyreflow_workflows_listA

Read-only

Inspect

List the cloud workflows saved in this Hyreflow workspace. Free.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the cost signal ('Free'), which is genuinely extra information not present in structured fields, but says nothing about result size, ordering, or pagination.

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 short sentences with the resource front-loaded and zero filler. Every clause earns its place, including the cost note.

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 zero-parameter, read-only list tool with no output schema, the description covers what is being listed and that it is free. It could be slightly more complete by noting ordering or result scope, but nothing critical for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. Nothing in the description is needed to compensate for schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('cloud workflows saved in this Hyreflow workspace'), so the agent knows exactly what it retrieves. It does not explicitly contrast itself with siblings like hyreflow_workflow_run or hyreflow_workflow_runs, but the 'saved workflows' scope is clear enough to distinguish it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus the sibling run-related tools, and no stated prerequisites or exclusions. The only contextual signal is 'Free', which hints at cost but not usage conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 8, 2026
- Addedhyreflow_extract_image

2 tool updatesOct 6, 2026

Changedhyreflow_enrich_run1 field changed

changedInput schema / properties / steps / items / oneOf

Previous value: -[
-  {
-    "properties": {
-      "alias": {
-        "type": "string"
-      },
-      "extract_js": {
-        "type": "string"
-      },
-      "method": {
-        "type": "string"
-      },
-      "payload": {
-        "type": "object"
-      },
-      "tool": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "alias",
-      "tool"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "kind": {
-        "const": "with"
-      },
-      "spec": {
-        "properties": {
-          "alias": {
-            "type": "string"
-          },
-          "extract_js": {
-            "type": "string"
-          },
-          "method": {
-            "type": "string"
-          },
-          "payload": {
-            "type": "object"
-          },
-          "tool": {
-            "type": "string"
-          }
-        },
-        "required": [
-          "alias",
-          "tool"
-        ],
-        "type": "object"
-      }
-    },
-    "required": [
-      "kind",
-      "spec"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "kind": {
-        "const": "waterfall"
-      },
-      "name": {
-        "type": "string"
-      },
-      "specs": {
-        "items": {
-          "properties": {
-            "alias": {
-              "type": "string"
-            },
-            "extract_js": {
-              "type": "string"
-            },
-            "method": {
-              "type": "string"
-            },
-            "payload": {
-              "type": "object"
-            },
-            "tool": {
-              "type": "string"
-            }
-          },
-          "required": [
-            "alias",
-            "tool"
-          ],
-          "type": "object"
-        },
-        "minItems": 1,
-        "type": "array"
-      }
-    },
-    "required": [
-      "kind",
-      "name",
-      "specs"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "alias": {
+        "type": "string"
+      },
+      "extract_js": {
+        "type": "string"
+      },
+      "method": {
+        "type": "string"
+      },
+      "payload": {
+        "description": "Request body for a provider tool, with {{column}} templates filled per row, e.g. {\"linkedin_url\": \"{{linkedin_url}}\"}. Required for a provider tool. A waterfall capability (linkedin_profile, personal_email, …) may omit it and runs on the row itself.",
+        "type": "object"
+      },
+      "tool": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "alias",
+      "tool"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "kind": {
+        "const": "with"
+      },
+      "spec": {
+        "properties": {
+          "alias": {
+            "type": "string"
+          },
+          "extract_js": {
+            "type": "string"
+          },
+          "method": {
+            "type": "string"
+          },
+          "payload": {
+            "description": "Request body for a provider tool, with {{column}} templates filled per row, e.g. {\"linkedin_url\": \"{{linkedin_url}}\"}. Required for a provider tool. A waterfall capability (linkedin_profile, personal_email, …) may omit it and runs on the row itself.",
+            "type": "object"
+          },
+          "tool": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "alias",
+          "tool"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "kind",
+      "spec"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "kind": {
+        "const": "waterfall"
+      },
+      "name": {
+        "type": "string"
+      },
+      "specs": {
+        "items": {
+          "properties": {
+            "alias": {
+              "type": "string"
+            },
+            "extract_js": {
+              "type": "string"
+            },
+            "method": {
+              "type": "string"
+            },
+            "payload": {
+              "description": "Request body for a provider tool, with {{column}} templates filled per row, e.g. {\"linkedin_url\": \"{{linkedin_url}}\"}. Required for a provider tool. A waterfall capability (linkedin_profile, personal_email, …) may omit it and runs on the row itself.",
+              "type": "object"
+            },
+            "tool": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "alias",
+            "tool"
+          ],
+          "type": "object"
+        },
+        "minItems": 1,
+        "type": "array"
+      }
+    },
+    "required": [
+      "kind",
+      "name",
+      "specs"
+    ],
+    "type": "object"
+  }
+]

Changedhyreflow_tools_search1 field changed

addedInput schema / properties / q / description

Added value: +"The intent in English, e.g. 'find finance directors at fintech companies'."

4 tool updatesOct 5, 2026

Changedhyreflow_enrich_run3 fields changed

changedInput schema / properties / confirm_token / description

Previous value: -"Echo of the `confirm_token` a previous identical call returned with `confirmation_required`, after the user approved the quoted cost."New value: +"The `confirm_token` returned by a previous identical call that came back `confirmation_required`. Required to run a call above the workspace's confirmation threshold."

changedInput schema / properties / run_id / description

Previous value: -"Poll a run an earlier call handed back running — send only this (and user_prompt). Free."New value: +"The `run_id` of an earlier call that returned running. Sent alone, it returns that run's progress (with user_prompt). Free."

changedInput schema / properties / user_prompt / description

Previous value: -"The user's request that drove this call, verbatim as they phrased it. Never a paraphrase, and never ask the user for it."New value: +"The user's request that drove this call, verbatim as they phrased it. Recorded with the run so its trace reads as the ask followed by the calls it drove."

Changedhyreflow_shortlist5 fields changed

changedInput schema / properties / confirm_token / description

Previous value: -"Echo of the `confirm_token` a previous identical call returned with `confirmation_required`, after the user approved the quoted cost."New value: +"The `confirm_token` returned by a previous identical call that came back `confirmation_required`. Required to run a call above the workspace's confirmation threshold."

changedInput schema / properties / must_haves / description

Previous value: -"Hard requirements, each a pass/fail gate. Confirm them with the user first."New value: +"Hard requirements, each a pass/fail gate."

changedInput schema / properties / questions / description

Previous value: -"Your own question set instead of the generated one — shapes in shortlist.md."New value: +"A custom question set to use instead of the generated one."

changedInput schema / properties / run_id / description

Previous value: -"Poll a screen an earlier call handed back unfinished — send only this (and user_prompt). Free."New value: +"The `run_id` of an earlier screen that returned unfinished. Sent alone, it returns that screen's progress or ranking. Free."

changedInput schema / properties / user_prompt / description

Previous value: -"The user's request that drove this call, verbatim as they phrased it. Never a paraphrase, and never ask the user for it."New value: +"The user's request that drove this call, verbatim as they phrased it. Recorded with the run so its trace reads as the ask followed by the calls it drove."

Changedhyreflow_tools_execute2 fields changed

changedInput schema / properties / confirm_token / description

Previous value: -"Echo of the `confirm_token` a previous identical call returned with `confirmation_required`, after the user approved the quoted cost. Only then does an above-threshold call run."New value: +"The `confirm_token` returned by a previous identical call that came back `confirmation_required`. Required to run a call above the workspace's confirmation threshold."

changedInput schema / properties / user_prompt / description

Previous value: -"The user's request that drove this call, verbatim as they phrased it. Never a paraphrase, and never ask the user for it."New value: +"The user's request that drove this call, verbatim as they phrased it. Recorded with the run so its trace reads as the ask followed by the calls it drove."

Changedhyreflow_workflow_run1 field changed

changedInput schema / properties / user_prompt / description

Previous value: -"The user's request that drove this call, verbatim as they phrased it. Never a paraphrase, and never ask the user for it."New value: +"The user's request that drove this call, verbatim as they phrased it. Recorded with the run so its trace reads as the ask followed by the calls it drove."

1 tool updateOct 1, 2026

Changedhyreflow_enrich_run2 fields changed

addedInput schema / properties / run_id

Added value: +{
+  "description": "Poll a run an earlier call handed back running — send only this (and user_prompt). Free.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "steps",
-  "user_prompt"
-]New value: +[
+  "user_prompt"
+]

1 tool updateOct 1, 2026

Changedhyreflow_enrich_run2 fields changed

addedInput schema / properties / input

Added value: +{
+  "description": "A ds_ dataset id to enrich instead of `rows`.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "rows",
-  "steps",
-  "user_prompt"
-]New value: +[
+  "steps",
+  "user_prompt"
+]

1 tool updateSep 30, 2026

Changedhyreflow_shortlist2 fields changed

addedInput schema / properties / run_id

Added value: +{
+  "description": "Poll a screen an earlier call handed back unfinished — send only this (and user_prompt). Free.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "job_spec",
-  "user_prompt"
-]New value: +[
+  "user_prompt"
+]

1 tool updateSep 29, 2026
- Changedhyreflow_shortlist2 fields changed
  - removedInput schema / properties / async
```
Removed value: -{
-  "type": "boolean"
-}
```
  - addedInput schema / properties / regenerate_questions
```
Added value: +{
+  "description": "Replace this job spec's stored question set.",
+  "type": "boolean"
+}
```
1 tool updateSep 28, 2026
- Addedhyreflow_shortlist

2 tool updatesSep 22, 2026

Changedhyreflow_enrich_run1 field changed

addedInput schema / properties / confirm_token

Added value: +{
+  "description": "Echo of the `confirm_token` a previous identical call returned with `confirmation_required`, after the user approved the quoted cost.",
+  "type": "string"
+}

Changedhyreflow_tools_execute1 field changed

addedInput schema / properties / confirm_token

Added value: +{
+  "description": "Echo of the `confirm_token` a previous identical call returned with `confirmation_required`, after the user approved the quoted cost. Only then does an above-threshold call run.",
+  "type": "string"
+}

Related MCP Connectors

Instalent MCPOAuth
io.instalent
Recruiting tools for candidate sourcing, enrichment, ATS workflows, campaigns, and outreach.
CRM Search Email
1
Lead Enrichment & AI Cold Email PersonalizerOAuth
com.ranovam
Lead enrichment plus AI-written cold emails in one run.
Web Scraping Browser Automation
1
Recruiter by Agent RailsOAuth
so.rails
Paste a role; get candidates with evidence per requirement and outreach drafts you approve.
Search Email
1
kolveraOAuth
io.kolvera
AI sales & BD platform for Australian recruiters: search, enrich, campaign, research, reports.
CRM Search Research & Data
3

Related MCP Servers

Job Outreach MCP Server
Email Web Scraping AI & Machine Learning
ajayranwa
F
license
A
quality
D
maintenance
Automates job outreach by finding companies, discovering contacts, generating personalized emails with AI, and tracking campaigns.
Updated 9 months ago (2026-01-04 18:32 UTC)
9
-
linkedin-prospection-mcp
Marketing CRM Social Media
gomessoaresemmanuel-cpu
A
license
A
quality
D
maintenance
LinkedIn prospection automation — find leads, score (fit+intent+urgency), qualify, personalize messages, run full pipeline, manage sales funnel. 7 MCP tools.
Updated 6 months ago (2026-03-26 07:45 UTC)
7
11 npm
MIT
openoutreach
Email Marketing Autonomous Agents
YAlegend
A
license
Not graded
quality
B
maintenance
Enables automated B2B lead generation and personalized cold email outreach with self-improving campaign monitoring.
Updated 9 days ago (2026-09-29 14:56 UTC)
MIT
Job Lead Converter MCP
CRM Search
adeeljames
F
license
Not graded
quality
D
maintenance
Transforms job postings into qualified sales leads by searching for active jobs, enriching company data, and identifying decision-maker contact information.
Updated 6 months ago (2026-03-26 06:58 UTC)
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources