Web3 jobs: 4,500+ companies, 22,000+ roles (12,100+ last 30d). Free stats, paid x402 queries.
Scored across 7 tools
The tools mostly target distinct query dimensions: company, sector, keyword search, rankings, taxonomy, stats, and health. There is some overlap because search_jobs can filter by sector and match company names, but the descriptions make the primary use cases reasonably clear.
Names are readable but mix conventions: verb_noun forms like list_sectors and search_jobs coexist with noun-based forms like company_jobs, sector_jobs, market_stats, and top_companies. The inconsistency is minor but noticeable.
Seven tools is well-scoped for a Web3 jobs market data server. Each tool covers a distinct query mode or metadata need without excessive surface area.
The set covers keyword search, company jobs, sector jobs, top companies, sector taxonomy, market stats, and health checks. A dedicated job-detail or browse-all-jobs operation is missing, but the core market-data workflows are well supported.
查某家 Web3 公司当前全部在招岗位。示例: company_jobs(company='Binance') → 返回该公司所有岗位的 title/location/url/posted/sector。公司名支持部分匹配（不区分大小写）。按次计费 $0.05 USDC。
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | ||
| max_age_days | No | ||
| include_stale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add genuinely useful behavior: per-call cost ($0.05 USDC), case-insensitive partial matching, and the exact return fields. However it never explains what 'stale' means, how the default 90-day window affects results, or whether results are paginated/capped — the filtering behavior most likely to surprise an agent is undisclosed.
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?
Four short sentences with the purpose front-loaded, followed by a concrete example, a matching rule, and a cost note; nothing is padding. The example could arguably be trimmed, but each sentence adds usable information.
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 three-parameter read tool with no annotations and no output schema, the description is adequate on the happy path — it names the return fields and pricing. It falls short on the two filtering parameters and on result-set size, which are the gaps an agent most needs closed before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only covers one of three parameters: `company` (partial match, case-insensitive). `max_age_days` (default 90) and `include_stale` (default false) are undocumented in both schema and description, leaving the agent to guess what 'stale' means and how the age cutoff selects postings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('查某家 Web3 公司当前全部在招岗位') and even gives a concrete example call with its return fields, so the agent knows exactly what this returns. It implicitly differs from search_jobs and sector_jobs (company-scoped vs. keyword/sector-scoped) but never names those siblings, so the differentiation is left to inference.
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?
Usage is implied by 'company=' scoping — use this when you know the company name — but there is no explicit when-to-use, when-not, or naming of search_jobs/sector_jobs as alternatives for keyword or sector lookups. The agent must infer routing from the tool name against the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
免费列出 18 个赛道/行业分类及各自岗位数，付费查询时 sector 参数要用这里的准确写法。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While there are no annotations, the description clearly defines the tool as a crucial reference point (a lookup/taxonomy tool) for utilizing parameters in other tools, which is a key behavioral characteristic beyond just 'listing'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly efficient, dedicating every word to explaining the tool's purpose and its vital role in parameter selection for other tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool acts as a reference list for critical sibling tools like `sector_jobs`, providing the accurate sector terminology and structure is the most complete information needed for the agent to successfully interact with the ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and 100% schema coverage (baseline 3). The description compensates by explaining the semantic value of the output (the exact nomenclature for the sectors) which guides the agent in future actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The tool explicitly states its function: listing 18 industry/sector classifications and their corresponding job counts. This is immediately clear and specific.
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 provides explicit instructions on how the output should be used: the terminology derived from this tool must be used when providing the 'sector' parameter in paid queries or other related tool calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
免费看全库规模：岗位总数、公司数、更新时间、18 个赛道的岗位分布、工作性质 / 办公方式 / 数据来源分布。付费查询前先调这个确认覆盖范围。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It does disclose that this call is free and that it serves as a coverage check before paid queries, which is useful cost/behavior context. However it does not state the read-only nature explicitly, rate limits, or return shape — though an output schema exists and covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, with the content listing front-loaded and the usage directive second. Every sentence earns its place with no repetition.
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 zero-parameter tool with an output schema covering return values, the description is nearly complete: it explains scope, contents, and the pre-paid-query use case. Only minor gaps (explicit read-only framing) remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline 4 case. The description correctly implies a parameterless full-database snapshot with no filtering options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (database-wide statistics) and enumerates the exact contents: total job count, company count, update time, distribution across 18 sectors, and work-type/office-mode/data-source breakdowns. This clearly separates it from sibling list/search tools, though it does not explicitly name an alternative.
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 an explicit when-to-use directive: call before paid queries to confirm coverage. It provides clear context but does not state when-not to use or name specific alternative tools to call instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
健康检查，免费。返回服务状态、收款地址、网络与价目表。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 it does disclose two useful behavioral facts: the call has no cost and it exposes a payment address, which matters for an agent in a paid marketplace. It says nothing about whether the call has side effects, whether it requires authentication, or about rate limits or latency, which leaves gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the operation and its cost profile. The second half enumerates return fields that the output schema already covers, which is mild redundancy rather than waste, since it still helps an agent pick the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values do not need spelling out, and the description still adds the two things the schema cannot: that the call is free and that it surfaces a payment address. What is missing is guidance on when in a workflow to call it, which for a health-check tool would be genuinely useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not invent parameter discussion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific operation ("健康检查") and enumerates what it returns (service status, payment address, network, price list). It is unmistakably different from every sibling (gpu_history, gpu_price, list_gpu_models, market_movers, platform_reliability), though it never explicitly contrasts itself with any of 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?
Saying the call is "免费" (free) implies it is a cheap pre-flight/connectivity check, and the way it is framed suggests calling it before spending money on the paid data tools. However, the description never states when to use this tool rather than a sibling, and it gives no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按关键词搜在招岗位，可叠加赛道/地点/工作性质/办公方式过滤。示例: search_jobs(q='solidity', sector='公链 / L1', limit=10) → 返回 title/company/location/url/posted/salary/sector。q 匹配职位名与公司名（不区分大小写）。按次计费 $0.05 USDC。
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| limit | No | ||
| sector | No | ||
| location | No | ||
| work_mode | No | ||
| employment | No | ||
| max_age_days | No | ||
| include_stale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses per-call pricing ($0.05 USDC), the exact return fields (title/company/location/url/posted/salary/sector), and that q matches job titles and company names case-insensitively. It omits pagination behavior beyond limit and any auth/payment flow details.
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?
Four dense sentences, each carrying distinct information: scope, filter stacking, a concrete call example with expected return fields, matching semantics, and pricing. Nothing is redundant and the scope statement is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no annotations and no output schema, the description supplies the return shape and billing model, which are the highest-risk unknowns. The remaining shortfall is the unexplained staleness/age parameters that an agent could easily set wrongly.
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 0%, so the description must compensate, and it covers q's matching semantics and names the sector/location/work-mode/employment filters, with limit demonstrated in the example. However, max_age_days and include_stale — two non-obvious parameters with defaults — are never explained anywhere, leaving a real gap for 8 parameters.
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 ('按关键词搜在招岗位') plus the stackable filter dimensions, so the agent knows this is a keyword-based listing search. It does not explicitly contrast itself with the near-siblings company_jobs or sector_jobs, which is the only thing keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'by keyword' plus optional filters, but never states when to prefer this over company_jobs/sector_jobs, nor any exclusion or prerequisite. Usage is inferable rather than instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查某个赛道/行业的在招岗位，按发布时间倒序。sector 写法必须与 list_sectors 一致。示例: sector_jobs(sector='RWA / 资产代币化', limit=20)。按次计费 $0.05 USDC。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sector | Yes | ||
| max_age_days | No | ||
| include_stale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description still discloses two important behaviors: results are sorted by posting time descending and each call costs $0.05 USDC. It does not cover payment/auth handling, pagination, or how max_age_days/include_stale affect results, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose and sort order first, then the sector-value constraint, then an example and billing note. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no annotations, and no output schema, the description is only partially complete. It covers sector semantics and billing, but omits two parameters and does not clarify return behavior or payment mechanics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the four parameters. It clarifies the required sector format and shows limit in the example, but it does not explain max_age_days or include_stale at all, leaving most parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: querying active job postings for a sector/industry, sorted by posting time descending. It clearly differs from company-oriented siblings by scoping to sector, though it does not explicitly name alternatives such as company_jobs or search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a useful prerequisite: the sector value must match list_sectors, and it includes a concrete example. However, it does not explain when to use this tool instead of search_jobs or company_jobs, so usage guidance is implied rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
岗位数最多的公司排行榜，可选按赛道过滤。示例: top_companies(limit=30) → [(公司, 在招岗位数, 主赛道)]。按次计费 $0.05 USDC。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add real value by disclosing per-call pricing ($0.05 USDC) and the returned tuple shape. It says nothing about authentication, rate limits, maximum limit values, or whether sector values are validated, leaving gaps for a paid tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences: purpose, filter, example, cost. No filler, and the example does double duty as parameter and return-format documentation.
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 two-parameter read tool with no output schema, the description supplies the return shape via an example and discloses cost. Remaining gaps are the valid sector values (linkable to list_sectors) and any cap on limit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: 'limit' is shown via the example call limit=30, and 'sector' is explained as an optional filter. It does not state a maximum for limit or enumerate valid sector strings, which is a notable omission given a list_sectors sibling exists.
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 resource and ranking semantics: companies ordered by number of open job postings, with an optional sector filter. The example output tuple (company, open job count, main sector) makes the resource concrete. It stops short of explicitly distinguishing itself from siblings like company_jobs or sector_jobs, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The optional sector filter is framed clearly, implying usage when a sector breakdown is wanted, but no when-not conditions or alternative tools are named. An agent must infer on its own that company_jobs is for a single company's postings and sector_jobs for jobs within a sector rather than a company ranking.
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.
company_jobs2 fields changedInput schema / properties / include_staleAdded value: +{
+ "default": false,
+ "title": "Include Stale",
+ "type": "boolean"
+}Input schema / properties / max_age_daysAdded value: +{
+ "default": 90,
+ "title": "Max Age Days",
+ "type": "integer"
+}search_jobs2 fields changedInput schema / properties / include_staleAdded value: +{
+ "default": false,
+ "title": "Include Stale",
+ "type": "boolean"
+}Input schema / properties / max_age_daysAdded value: +{
+ "default": 90,
+ "title": "Max Age Days",
+ "type": "integer"
+}sector_jobs2 fields changedInput schema / properties / include_staleAdded value: +{
+ "default": false,
+ "title": "Include Stale",
+ "type": "boolean"
+}Input schema / properties / max_age_daysAdded value: +{
+ "default": 90,
+ "title": "Max Age Days",
+ "type": "integer"
+}company_jobslist_sectorsmarket_statspingsearch_jobssector_jobstop_companiesTrack public job boards: free snapshot, paid hiring-growth intel via x402 USDC.
Web3 intelligence: actors, chains, sectors, narratives, hiring, funding, events and daily metrics.
Open roles from public Greenhouse, Lever, Ashby, Workable job boards as clean data. Winters Works.
HireHeat: who's hiring? Open and new roles per company domain by function, seniority, location.
Add one secure layer between your agents and this server.