A
licenseA
qualityA
maintenancePDF extraction that actually works. The only extractor that audits every page. #2 on opendataloader-bench. 5 MCP tools for AI agents: metadata, convert, analyze, batch, structured extraction.
7
105 PyPI
86
MIT
Dirtsmith outside-tools rate sheet
Server Details
Free no-login MCP tools: pdf_tables (PDF tables to CSV), table_to_csv, read_page, tool price router.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- throttler300/dirtsmith-rate-sheet
- GitHub Stars
- 0
- ChatGPT
- –
- Claude
- –
TDQS
B3.4/5.0
Scored across 15 tools
Disambiguation4/5
Each tool targets a distinct resource or action: contractor job flow, seller listing flow, buyer discovery, and standalone utilities are clearly separated. The only mild overlap is between pdf_tables and table_to_csv (both table extraction) and between get_quote and find_tool (both about pricing), but descriptions make the boundaries clear.
Naming Consistency4/5
All tool names use consistent snake_case, which is predictable and readable. Most follow a verb_noun pattern (claim_job, submit_job, list_jobs, find_tool), though a handful are noun_phrases (cost_estimate, json_validate, listing_stats, pdf_tables), which is a minor deviation rather than an inconsistency.
Tool Count4/5
15 tools sit at the upper end of the typical 3–15 range but are justified by the server supporting multiple distinct roles: contractor jobs, seller listings, buyer quotes, search, and several utility tools. The count is reasonable for a multi-sided rate-sheet platform, though it could feel slightly heavy for a single agent.
Completeness4/5
Core workflows are well covered: contractors can list, claim, submit, and check credits; sellers can list, verify, and track stats; buyers can search and get quotes. Minor gaps exist, such as no update/delete for seller listings and no 'list all my listings' view, but these are workable for an early-stage marketplace.
Available Tools
15 toolscheck_creditCInspect
Contractors/buyers: how many calls are left on a credit pass.
| Name | Required | Description | Default |
|---|---|---|---|
| credit | Yes |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It only states that it reports remaining calls; it omits auth requirements, read-only nature (implied), error behavior, return format, and rate limits.
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 zero waste. The audience and core function are immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter coverage, the description is too sparse. It should at least clarify what the 'credit' parameter is and what the response contains, beyond a bare count.
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 explain the single 'credit' string parameter. It hints at 'credit pass' but gives no format, source, or meaning, leaving the parameter effectively undocumented.
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 query about remaining calls on a credit pass, which is clear enough to distinguish it from generic job/listing siblings. However, it lacks an explicit verb and does not contrast with any similar sibling tool.
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?
Identifies the intended audience (contractors/buyers) but provides no when-to-use guidance, prerequisites, or alternatives to consider. The agent is left to infer the context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claim_jobAInspect
Contractors: claim one open job for 2 hours. Returns a claim token for submit_job. Max 2 open claims per caller.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | Your bot name (optional) | |
| job_id | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose real behavioral traits: a 2-hour claim window, a per-caller cap of 2 open claims, and an emitted token required by submit_job. It omits what happens if the job is already claimed or whether the claim is exclusive/locking, which matters for a contention-prone operation.
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, zero filler, with the core action and the consumer of the token front-loaded. Every clause 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 2-param mutation with no annotations and no output schema, the description covers the essential contract: duration, cap, and the token consumed by submit_job. Missing failure/exclusivity behavior keeps it from being fully complete.
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%: agent is self-described, but job_id has no schema description. The description implies job_id refers to an open job (linking to list_jobs) but adds no format or sourcing detail, so it only marginally compensates for the 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 (claim) and resource (open job) with scope (2 hours) and return value (claim token for submit_job). An agent can distinguish this from list_jobs and submit_job without opening any 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?
Names the intended caller ('Contractors') and the downstream handoff to submit_job, which gives clear context for when this applies. It does not state exclusions or that job ids should first come from list_jobs, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cost_estimateCRead-onlyInspect
Dirtsmith-built free utility: token count (chars/4 estimate) and USD cost for a prompt at your model prices.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| calls | No | ||
| input_tokens | No | ||
| output_tokens | No | ||
| usd_per_mtok_in | No | ||
| usd_per_mtok_out | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| next | No | |
| note | No | |
| calls | No | |
| built_by | No | |
| usd_total | No | |
| house_tool | No | |
| input_tokens | No | |
| usd_per_call | No | |
| output_tokens | No |
TDQS
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds one genuinely useful behavioral trait: the count is a 'chars/4 estimate' rather than an exact tokenizer result, warning the agent that output is approximate. It says nothing about determinism, limits, or pricing defaults.
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 tight sentence, front-loaded with the core function. It is well-sized for the task, though the 'Dirtsmith-built free utility' branding adds little value for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. However, for a 6-parameter tool with 0% schema description coverage and no required fields, the description is too thin to guide correct invocation: it omits the 'calls' parameter, the in/out token and price split, and any usage context.
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% across 6 parameters, so the description must compensate, and it only partially does. It maps loosely to text ('prompt'), the token inputs ('token count'), and prices ('your model prices'), but never mentions the 'calls' multiplier or the in/out price distinction, leaving key parameters undocumented everywhere.
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 states a specific function: it computes a token count and a USD cost for a prompt given model prices. That is a clear verb-plus-output statement. It does not, however, distinguish itself from potentially overlapping siblings such as price_advisor, so it stops short of 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the 24 sibling tools. The agent is left to infer that this is a pre-flight estimation utility from the words 'utility' and 'estimate' alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fedreg_searchCRead-onlyInspect
Dirtsmith-built. Search the U.S. Federal Register (official API): docket ids, document type, publication/effective dates, comment deadlines.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| type | No | RULE|PRORULE|NOTICE | |
| limit | No | ||
| since | No | ||
| agency | No | slug, e.g. agricultural-marketing-service | |
| credit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| quota | Yes | |
| total | Yes | |
| source | Yes | |
| results | Yes | |
| built_by | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and open-world nature are covered by structured data. The description adds only '(official API)', which signals an authoritative external source but discloses nothing about pagination, rate limits, auth, or result volume - the things an agent actually needs for a search call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence keeps it tight and the resource is front-loaded after the branding fragment. However 'Dirtsmith-built' earns nothing, and the colon-separated fragment list reads as feature-stuffing rather than structured guidance.
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?
An output schema exists so return values need not be explained, and one required param plus annotations cover the basics. Still, with 6 parameters at 33% schema coverage, the semantics of limit, since, and credit are missing from both the schema and the description, leaving gaps for a multi-filter search 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 only 33% - type and agency are documented in the schema, while q, limit, since, and credit are bare. The description gestures at 'document type', 'publication/effective dates', and 'comment deadlines', which loosely maps to type and since, giving partial compensation, but limit and credit remain unexplained in both places.
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 (Search) and resource (U.S. Federal Register) and enumerates the returnable content (docket ids, document type, dates, comment deadlines). Siblings are almost entirely unrelated marketplace/tooling helpers, so no differentiation is needed; the only blemish is the leading 'Dirtsmith-built' branding, which is noise rather than purpose.
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 statement of when to use this tool versus any alternative, nor any prerequisites. The use case (querying the Federal Register) is only implied by the resource name. An agent gets no routing guidance at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_toolARead-onlyInspect
Dirtsmith-built (house tool): search this rate sheet by keyword; returns matching outside tools cheapest-first with use_url. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Keywords, e.g. search, weather |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| miss | No | |
| note | No | |
| query | No | |
| ranking | No | |
| results | No | |
| builders | No | |
| built_by | No | |
| house_tool | No |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint; the description adds real behavioral context beyond them — it is a house tool ('Dirtsmith-built'), costs nothing ('Free'), and returns results ordered cheapest-first exposing a use_url field. That ordering and cost disclosure is exactly the value-add the annotations 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?
A single compact sentence with no filler, front-loading provenance, action, and return shape in order of relevance. Every clause 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?
With an output schema present the description need not explain return values, and it goes further by disclosing the cheapest-first ordering and use_url field. It is complete enough to call correctly; only the sibling-routing context is 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?
Schema description coverage is 100% and there is only one parameter, so the schema already documents q fully (with its own example). The description restates 'by keyword' without adding format, syntax, or multi-keyword guidance, so baseline 3 is appropriate.
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 ('search') and resource ('this rate sheet' of outside tools) plus the return shape (matching tools cheapest-first with use_url). It is clear what the tool does, but it does not differentiate itself from near-siblings like similar_tools, match_tool, or list_tools, so an agent still has to infer which search-family tool to pick.
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?
The description gives no when-to-use guidance, no exclusions, and names none of the many search/lookup siblings. 'Free' hints at cost preference but never states that this is the keyword-search entry point versus list_tools or match_tool, leaving usage to inference at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quoteAInspect
Buyers: price and how to pay for one tool. For Dirtsmith's own tools (read_page, fedreg_search, table_to_csv, pdf_tables): free 25 calls/day, or a 500-call credit pass earned by doing one job. Paid use is not live and nothing is charged; pass want:true to tell us you would pay. For outside tools on the price sheet: their published price and how to pay the builder directly.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Exact tool name, e.g. pdf_tables or Exa | |
| want | No | true = you would pay for this when paid use is live (counted, no charge) | |
| calls | No | How many calls you expect (optional) | |
| max_usd_per_call | No | Optional: the most you would pay per call |
TDQS
A4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so unusually well: it discloses the free tier (25 calls/day), the 500-call credit pass and how it is earned, that paid use is not live, that nothing is charged even when want:true is passed, and that outside-tool prices are paid directly to the builder. These are exactly the behavioral facts an agent needs before calling.
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 the audience ('Buyers:') and the deliverable, then the two pricing branches. Dense but information-rich; every clause carries a distinct fact, though the run-on pricing sentence could be split for scanability.
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 must characterize the return, and it does explain what comes back (price plus how to pay) for both tool categories. The main residual gap is the exact form/shape of the quote and whether max_usd_per_call or calls change the output, but the behavioral picture is otherwise 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?
Schema description coverage is 100%, so 3 is the baseline. The description adds real meaning on top by clarifying the intent behind want:true ('tell us you would pay', counted but not charged), which the schema alone does not convey, and by framing 'tool' as either a Dirtsmith tool or an outside tool 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 resource and scope: the price and payment path for exactly one tool, split into Dirtsmith-owned tools vs outside tools on the price sheet. It gives concrete examples (pdf_tables, Exa) so the agent knows the input shape. It does not, however, differentiate itself from the sibling cost_estimate, which an agent could easily confuse with a quote.
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 'Buyers:' framing and by the instruction to pass want:true to signal willingness to pay, which is actionable context. But there is no explicit when-to-use vs. when-not, and the closest sibling (cost_estimate) is never named or contrasted, leaving the agent to infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
json_validateBRead-onlyInspect
Dirtsmith-built free utility: validate JSON data against a JSON Schema subset; returns errors with paths.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| schema | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| note | No | |
| valid | No | |
| errors | No | |
| built_by | No | |
| house_tool | No |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two genuine behavioral facts: the schema support is only a 'subset' (a real limitation to warn about) and errors come back with paths. It does not say whether validation short-circuits or reports all errors at once.
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 well-formed sentence that front-loads the core action. The only dead weight is the 'Dirtsmith-built free utility' vendor tag, which does nothing for tool selection.
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 2-required-param validator with an output schema (so return values need no explanation) and annotations covering safety, the description is nearly adequate. The gap is the unsupported-schema-subset detail and the format ambiguity of 'data', both of which affect whether a call succeeds.
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% and the 'data' property is an untyped empty schema, so the description must carry the load. It does map the two required params to their roles (validation payload vs. JSON Schema), but leaves the critical ambiguity of whether 'data' should be a JSON string, an object, or raw text.
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 ('validate JSON data against a JSON Schema subset') plus the output ('returns errors with paths'), which is far more than the name alone conveys. It is trivially distinguishable from all siblings, but the leading 'Dirtsmith-built free utility' promo clause dilutes an otherwise precise statement.
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 reach for this tool, what prerequisites exist (e.g. which schema dialect/subset must the schema conform to), or when to prefer it over manually checking a payload. The reader must infer the use case from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listing_statsCRead-onlyInspect
Per-listing stats for a seller listing: reads, attempted_use, confirmed_want.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No |
TDQS
C2.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the metric names, but those are return-value details already covered by the output schema, so it contributes essentially no behavioral context beyond what structured fields provide.
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 with the resource stated first and the metrics last; nothing is padded. It is efficiently front-loaded, though extremely terse at the cost of missing guidance.
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?
An output schema exists, so the description need not explain return values, and read-only semantics are covered by annotations. What remains missing is any hint about what the required 'id' refers to and when this tool is the right choice, which is a meaningful gap for a listing-oriented tool within a crowded sibling set.
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 single 'id' parameter has no description in the schema. The phrase 'a seller listing' faintly implies the id is a listing identifier, but the description never clarifies whether it expects a listing id, a seller id, or an internal tool id — a real ambiguity given siblings like get_tool, get_card, and get_result.
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 the resource (per-listing stats for a seller listing) and enumerates the specific metrics returned (reads, attempted_use, confirmed_want), so the agent knows exactly what it retrieves. It does not, however, distinguish itself from adjacent siblings like listing_check or verify_my_listing, which also operate on listings.
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 when-to-use guidance whatsoever: no prerequisites, no indication of when to call this versus listing_check, verify_my_listing, or get_result. The agent must infer the trigger from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_jobsBInspect
Contractors: open data jobs you can do to earn a 500-call, 30-day credit pass for Dirtsmith's own tools. Jobs are Dirtsmith's own real data needs (no outside client is paying yet). Each job says exactly what to submit and how it is checked.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | default open |
TDQS
B3.2/5.0
Behavior3/5
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 genuine context: jobs are Dirtsmith's own data needs, each job specifies deliverables and how it is checked, and there is a 500-call/30-day credit incentive. It nonetheless omits auth requirements, pagination, and result volume, which matter for a listing endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with little outright waste, but the leading 'Contractors:' audience label delays the action, and the incentive/payment-explanation sentence is promotional rather than selection-relevant.
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 compensates by explaining what a returned job contains ('exactly what to submit and how it is checked'). It stops short of describing ordering, counts, or pagination, but covers the essential shape of the response.
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 100% with a single enum parameter (open/all, default open), so the schema already documents the only input. The description adds no syntax or behavioral meaning beyond that, making the baseline 3 appropriate.
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 makes clear this surfaces open data jobs a contractor can perform, and 'open data jobs' implicitly conveys the default status. However, it never states the verb 'list' explicitly and doesn't mention the open/all filter, so an agent must infer that this is the retrieval endpoint for job listings rather than something like claim_job or submit_job.
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 explicit when-to-use guidance and no routing to siblings such as claim_job, submit_job, or check_credit, which are the obvious next steps in this workflow. The mention of earning a credit pass implies motivation but not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_toolAInspect
Sellers: list your own agent-callable tool on the Dirtsmith rate sheet. Free, no login, no payment. Goes into a public pending queue labeled 'unverified, seller-submitted'. To verify ownership, publish the returned verification code as a public text file at https:///.well-known/dirtsmith-verify.txt, then call verify_my_listing. Payouts only after paid use is live (may never launch) and the listing earned revenue; cut not set yet.
| Name | Required | Description | Default |
|---|---|---|---|
| does | Yes | ||
| name | Yes | ||
| source | No | Optional public pricing URL | |
| contact | No | Optional email or URL | |
| payment | No | e.g. x402 (USDC), pay-as-you-go plan | |
| endpoint | Yes | https URL | |
| price_published | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and openWorldHint=false; the description goes well beyond, disclosing that the listing lands in a public pending queue labeled 'unverified, seller-submitted', that verification requires a public well-known text file, and that payouts are conditional and may never launch with the cut unset. This is exactly the side-effect and consequence context an agent needs before submitting.
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?
Purpose is front-loaded in the first clause, and each subsequent sentence carries distinct information (cost, queue state, verification flow, payout caveats). It is dense but not padded, though the payout caveats make it longer than strictly necessary for invocation.
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 an output schema present, return values need not be restated, and the description still mentions the returned verification code appropriately. The workflow, side effects, and monetization caveats are covered; the only meaningful gap is semantic meaning for undocumented required parameters.
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 57%, and the description only illuminates the endpoint parameter indirectly ('https://<your endpoint host>/.well-known/dirtsmith-verify.txt'). Required fields like does and price_published get no explanation in either place, so the description does not fully 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 and resource plus the audience: 'Sellers: list your own agent-callable tool on the Dirtsmith rate sheet.' This cleanly distinguishes it from discovery siblings (find_tool, list_tools) and from the follow-up step verify_my_listing. An agent knows immediately this is the seller-side listing submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Scopes usage to sellers and explicitly names the follow-up tool and its trigger: publish the returned code, then call verify_my_listing. It also removes cost friction ('Free, no login, no payment'), so an agent can decide to invoke without further inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pdf_tablesARead-onlyInspect
Dirtsmith-built (beta). Extract tables from a text-layer PDF URL as CSV, up to 5 pages per call. No OCR: scanned image PDFs return an error. Free 25/day; a /work/v2 credit unlocks 500 calls.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| pages | No | e.g. 1-3 | |
| credit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | Yes | |
| via | Yes | |
| pages | Yes | |
| quota | Yes | |
| tables | Yes | |
| num_pages | Yes | |
| text_layer | Yes | |
| checked_job | Yes |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely useful behavior: a hard 5-page-per-call limit, failure on scanned/image PDFs, a 25/day free quota, and a credit-based upgrade. It does not explain what happens with PDFs longer than 5 pages (pagination/continuation), which is the main remaining gap.
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 core action and format, then constraints, then cost. The '(beta)' branding is minor filler, but every other clause delivers operational information an agent needs.
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 an output schema present, return-value explanation is not required, and the description instead covers the constraints that actually matter (OCR limitation, page cap, quotas). It is close to complete for a 3-parameter extraction tool; only the >5-page 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 low (33%): 'url' and 'credit' have no schema descriptions and 'pages' only has 'e.g. 1-3'. The description partially compensates by clarifying that the URL must point to a text-layer PDF and by explaining that a /work/v2 credit unlocks 500 calls, but the 'pages' range syntax and the credit parameter's accepted values remain largely undocumented in prose.
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?
It names a specific verb and resource ('Extract tables from a ... PDF URL as CSV'), which is unambiguous. It does not, however, differentiate itself from the very similar sibling 'table_to_csv' or from 'read_page', so an agent choosing between them gets no routing help from the name or description.
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 implicitly scopes usage ('text-layer PDF URL', 'No OCR: scanned image PDFs return an error'), which tells the agent when this tool will fail, but it never states when to prefer it over table_to_csv or other siblings. Usage is implied rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_pageBRead-onlyInspect
Dirtsmith-built. Fetch a URL and return clean markdown text (actually executes). Respects robots.txt and noai opt-outs; free failover for PDFs. Free 25/day; a /work credit unlocks 500 calls.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| credit | No | ||
| max_chars | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ms | Yes | |
| ok | Yes | |
| url | Yes | |
| via | Yes | |
| text | Yes | |
| chars | Yes | |
| quota | Yes | |
| title | Yes | |
| format | Yes | |
| built_by | Yes | |
| final_url | Yes | |
| total_chars | Yes | |
| content_type | No | |
| safety_flags | No | |
| untrusted_data | No | |
| cut_at_max_chars | Yes | |
| source_truncated_at_2MB | No |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only and open-world; the description adds genuinely useful behavior the schema cannot express: robots.txt and noai opt-out compliance, PDF failover, and a concrete quota (25/day free, 500 with credit). It does not disclose failure modes or what happens when opt-outs block a fetch, keeping it below 5.
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 dense sentences that front-load the core action, with quota and compliance details trailing. The leading 'Dirtsmith-built.' is arguably dead weight and the parenthetical '(actually executes)' is awkward, but overall there is little waste.
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?
An output schema exists, so return values need not be re-explained, and quotas/compliance are covered. The real gap is parameter meaning: max_chars is undocumented in both schema and description, leaving the agent guessing on an optional-but-useful control.
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 burden for three parameters. It indirectly explains the 'credit' parameter via the 500-call unlock, but 'max_chars' is never mentioned and the url parameter gains nothing beyond the obvious name. Partial compensation for a low-coverage schema.
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: 'Fetch a URL and return clean markdown text', which is unambiguous and distinct from siblings like pdf_tables or json_validate. The '(actually executes)' aside is odd but does convey the tool performs a real network fetch rather than planning one. No sibling is named, so it stops short of 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?
'free failover for PDFs' hints at when to prefer this over the pdf_tables sibling and the quota line implies a cost decision, but there is no explicit when-to-use or when-not-to-use guidance. The agent must infer the routing from the PDF clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_jobAInspect
Contractors: submit a claimed job. Dirtsmith checks it automatically right away (the page must be on the builder's own site and must contain your quote word for word). Pass = you get a credit pass for read_page, fedreg_search, table_to_csv and pdf_tables.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | https page on the builder's own domain that states the price | |
| claim | Yes | ||
| price | Yes | The price as written, e.g. '$0.01 per request' | |
| quote | Yes | Exact sentence from that page that states the price (8-400 chars) |
TDQS
A4.1/5.0
Behavior4/5
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 that validation is automatic and immediate, states the two validation conditions (own-domain page, word-for-word quote), and describes the reward on success (credit passes for four sibling tools). What happens on failure (error shape, retry, rejection handling) is left unstated.
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 tight sentences with the action and audience front-loaded, followed by validation criteria and the reward. No filler and no repetition of the name or title.
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 four-required-parameter mutation with no annotations and no output schema, the description covers purpose, validation, and the success outcome. The main gap is the failure path and any response detail, but what an agent needs to submit correctly is largely present.
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 75% and the description reinforces two of the documented parameters meaningfully: 'url' must be on the builder's own site and 'quote' must match the page word for word, which adds constraint detail beyond the schema text. The 'claim' parameter remains undocumented in both the schema and the 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?
States a specific verb and resource ('submit a claimed job') and names the audience ('Contractors'), so it is distinguishable from the reference and listing siblings. It never names a sibling like claim_job or check_credit to clarify the boundary, so it stops short of full differentiation.
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 context and prerequisites for use (you must have a claimed job whose page sits on the builder's own site and quotes the price verbatim). It does not state when NOT to use it or point to an alternative such as claim_job, so no exclusions are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
table_to_csvBRead-onlyInspect
Dirtsmith-built. Convert the HTML tables on a web page to CSV. HTML only.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| index | No | ||
| credit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| url | Yes | |
| note | Yes | |
| quota | Yes | |
| tables | Yes | |
| built_by | Yes | |
| tables_found | 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 and openWorldHint=true, so the safety and network profile is covered. The description adds a useful scoping constraint (HTML only, implying non-HTML pages yield nothing) but says nothing about pagination, multiple-table handling, or the meaning of the credit parameter. 'Dirtsmith-built' is branding noise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and the operative instruction is clear, but the leading 'Dirtsmith-built' fragment is pure waste and the extreme terseness leaves the two optional parameters unaddressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation. But for a tool with an undocumented index selector and a credit parameter, the description is far too thin to let an agent invoke it correctly beyond the basic URL case.
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 three parameters. The description only loosely implies that 'url' is a web page address; 'index' and 'credit' are entirely unexplained, so an agent cannot tell that index likely selects which table to convert or what credit is for. It fails to compensate for the coverage gap.
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 states a specific verb and resource ('Convert the HTML tables on a web page to CSV'), so the transform is unambiguous. The 'HTML only' qualifier implicitly separates it from the pdf_tables sibling, though the sibling is never named.
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?
'HTML only' implies a boundary condition (don't use it on PDFs), which nudges the agent toward pdf_tables. However, no alternative is named explicitly and there is no guidance on required preconditions or when conversion would fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_my_listingBInspect
Verify a seller listing by endpoint handshake: Dirtsmith reads the public file https:///.well-known/dirtsmith-verify.txt and checks it contains your verification code.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and openWorldHint=true; the description adds genuinely useful behavior beyond that by disclosing the outbound fetch to the endpoint host, the exact path checked, and the content comparison performed. It does not explain why the operation is flagged non-read-only (e.g. whether the listing is marked verified), which is a minor gap.
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?
One front-loaded sentence that leads with the verb and then the mechanism; every clause earns its place. The embedded URL template makes it dense but still readable.
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?
An output schema exists, so return values need not be described, and the handshake mechanism is covered. However, preconditions (a registered/published verification code, the id's identity) and the post-verification state change implied by readOnlyHint=false are left unstated.
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 0% and the single required 'id' parameter is never explained in the description. The text mentions a verification code and an endpoint host, neither of which maps to a declared parameter, so it does not compensate for the undocumented 'id'.
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 names a specific verb (verify) and resource (seller listing) and even states the mechanism (endpoint handshake against a .well-known file). An agent can distinguish it from read-style siblings like listing_check or listing_stats. It stops short of explicitly naming which sibling to prefer, so it isn't 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?
Usage is implied rather than stated: the reference to 'your verification code' and the well-known path implies the caller must already own a listing and have published a code. There is no explicit when/when-not guidance and no named alternative, so it falls short of a 4.
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.
20 tool updates
- Removed
build_or_buy - Added
check_credit - Added
claim_job - Removed
confirm_want - Removed
demand_gaps - Removed
get_card - Added
get_quote - Removed
get_result - Removed
get_tool - Added
list_jobs - Removed
list_tools - Removed
listing_check - Removed
match_tool - Removed
price_advisor - Removed
signal_would_list - Removed
signal_would_use - Removed
similar_tools - Added
submit_job - Removed
tool_status - Removed
use_tool
25 tool updates
- Changed
build_or_buy1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "candidates": { + "items": { + "properties": { + "aggregate_tries": { + "type": [ + "number", + "null" + ] + }, + "aggregate_wants": { + "type": [ + "number", + "null" + ] + }, + "cheaper_than_your_forecast": { + "type": [ + "boolean", + "null" + ] + }, + "checked": { + "type": [ + "string", + "null" + ] + }, + "does": { + "type": [ + "string", + "null" + ] + }, + "endpoint": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "payment": { + "type": [ + "string", + "null" + ] + }, + "per_call_usd_published": { + "type": [ + "number", + "null" + ] + }, + "price_published": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": [ + "string", + "null" + ] + }, + "total_usd_for_calls": { + "type": [ + "number", + "null" + ] + }, + "use_url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "inputs": { + "properties": { + "calls": { + "type": [ + "number", + "null" + ] + }, + "est_tokens": { + "type": [ + "number", + "null" + ] + }, + "task": { + "type": [ + "string", + "null" + ] + }, + "usd_per_mtok": { + "type": [ + "number", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "measure": { + "type": [ + "string", + "null" + ] + }, + "miss": { + "type": [ + "boolean", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "query": { + "type": [ + "string", + "null" + ] + }, + "usage": { + "type": [ + "string", + "null" + ] + }, + "your_forecast_usd": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" +}
- Changed
confirm_want1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "disclosure": { + "type": [ + "string", + "null" + ] + }, + "forwarded_to_tool": { + "type": [ + "boolean", + "null" + ] + }, + "identify": { + "type": [ + "string", + "null" + ] + }, + "internal": { + "type": [ + "boolean", + "null" + ] + }, + "listing_status": { + "type": [ + "string", + "null" + ] + }, + "message": { + "type": [ + "string", + "null" + ] + }, + "next": { + "properties": { + "would_list_here_for_a_cut": { + "type": [ + "string", + "null" + ] + }, + "would_use_at_this_price": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "paid_use_live": { + "type": [ + "boolean", + "null" + ] + }, + "payment_taken": { + "type": [ + "boolean", + "null" + ] + }, + "purchased": { + "type": [ + "boolean", + "null" + ] + }, + "quote": { + "properties": { + "builder_host": { + "type": [ + "string", + "null" + ] + }, + "checked": { + "type": [ + "string", + "null" + ] + }, + "payment_rail_at_builder": { + "type": [ + "string", + "null" + ] + }, + "price": { + "type": [ + "string", + "null" + ] + }, + "price_detail": { + "properties": { + "amount": { + "type": [ + "number", + "null" + ] + }, + "as_published": { + "type": [ + "string", + "null" + ] + }, + "asset": { + "type": [ + "string", + "null" + ] + }, + "checked_at": { + "type": [ + "string", + "null" + ] + }, + "rail": { + "type": [ + "string", + "null" + ] + }, + "source_url": { + "type": [ + "string", + "null" + ] + }, + "unit": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "price_source": { + "type": [ + "string", + "null" + ] + }, + "terms": { + "type": [ + "string", + "null" + ] + }, + "tool": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "recorded": { + "type": [ + "boolean", + "null" + ] + }, + "stage": { + "type": [ + "string", + "null" + ] + }, + "use_directly_today": { + "properties": { + "endpoint": { + "type": [ + "string", + "null" + ] + }, + "how": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + } + }, + "type": "object" +}
- Changed
cost_estimate1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "calls": { + "type": [ + "number", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "input_tokens": { + "type": [ + "number", + "null" + ] + }, + "next": { + "type": [ + "string", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "output_tokens": { + "type": [ + "number", + "null" + ] + }, + "usd_per_call": { + "type": [ + "number", + "null" + ] + }, + "usd_total": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" +}
- Changed
demand_gaps1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "gaps": { + "items": { + "properties": { + "days_missed": { + "type": [ + "number", + "null" + ] + }, + "query": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "list_yours": { + "type": [ + "string", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "total_distinct": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" +}
- Changed
fedreg_search1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "quota": { + "properties": { + "limit": { + "type": [ + "number", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "tier": { + "type": [ + "string", + "null" + ] + }, + "used": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" + }, + "results": { + "items": { + "properties": { + "abstract": { + "type": [ + "string", + "null" + ] + }, + "agencies": { + "items": { + "type": [ + "string", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "comments_close_on": { + "type": [ + "string", + "null" + ] + }, + "docket_ids": { + "items": { + "type": [ + "string", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "document_number": { + "type": [ + "string", + "null" + ] + }, + "effective_on": { + "type": [ + "string", + "null" + ] + }, + "html_url": { + "type": [ + "string", + "null" + ] + }, + "pdf_url": { + "type": [ + "string", + "null" + ] + }, + "publication_date": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "type": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "source": { + "type": [ + "string", + "null" + ] + }, + "total": { + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "ok", + "source", + "total", + "results", + "built_by", + "quota" + ], + "type": "object" +}
- Changed
find_tool1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "builders": { + "type": [ + "string", + "null" + ] + }, + "built_by": { + "type": [ + "string", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "miss": { + "type": [ + "boolean", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "query": { + "type": [ + "string", + "null" + ] + }, + "ranking": { + "type": [ + "string", + "null" + ] + }, + "results": { + "items": { + "properties": { + "aggregate_tries": { + "type": [ + "number", + "null" + ] + }, + "aggregate_wants": { + "type": [ + "number", + "null" + ] + }, + "checked": { + "type": [ + "string", + "null" + ] + }, + "does": { + "type": [ + "string", + "null" + ] + }, + "endpoint": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "payment": { + "type": [ + "string", + "null" + ] + }, + "price_published": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": [ + "string", + "null" + ] + }, + "use_url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Added
get_card - Changed
get_result1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "alternatives": { + "items": { + "properties": { + "name": { + "type": [ + "string", + "null" + ] + }, + "price_published": { + "type": [ + "string", + "null" + ] + }, + "uptime_7d": { + "type": [ + "number", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "best": { + "properties": { + "endpoint": { + "type": [ + "string", + "null" + ] + }, + "how_to_call": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "payment": { + "type": [ + "string", + "null" + ] + }, + "per_call_usd_published": { + "type": [ + "number", + "null" + ] + }, + "price_published": { + "type": [ + "string", + "null" + ] + }, + "uptime_7d": { + "type": [ + "number", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "built_by": { + "type": [ + "string", + "null" + ] + }, + "free_now": { + "properties": { + "mcp": { + "type": [ + "string", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "tools": { + "properties": { + "build_or_buy": { + "type": [ + "string", + "null" + ] + }, + "cost_estimate": { + "type": [ + "string", + "null" + ] + }, + "find_tool": { + "type": [ + "string", + "null" + ] + }, + "get_result": { + "type": [ + "string", + "null" + ] + }, + "json_validate": { + "type": [ + "string", + "null" + ] + }, + "tool_status": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "miss": { + "type": [ + "boolean", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "optional_feedback": { + "type": [ + "string", + "null" + ] + }, + "receipt": { + "properties": { + "basis": { + "type": [ + "string", + "null" + ] + }, + "calls": { + "type": [ + "number", + "null" + ] + }, + "chosen": { + "type": [ + "string", + "null" + ] + }, + "created": { + "type": [ + "string", + "null" + ] + }, + "est_build_usd": {}, + "est_buy_usd": { + "type": [ + "number", + "null" + ] + }, + "est_savings_usd": {}, + "id": { + "type": [ + "string", + "null" + ] + }, + "intent": { + "type": [ + "string", + "null" + ] + }, + "paid_use_live": { + "type": [ + "boolean", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "receipt_note": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" +}
- Changed
get_tool1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "call_to_action": { + "properties": { + "do_this_next": { + "type": [ + "string", + "null" + ] + }, + "sellers": { + "properties": { + "mcp_tool": { + "type": [ + "string", + "null" + ] + }, + "method": { + "type": [ + "string", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "use": { + "properties": { + "body": { + "properties": { + "tool": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "mcp_tool": { + "type": [ + "string", + "null" + ] + }, + "method": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "want": { + "properties": { + "body": { + "properties": { + "contact": { + "type": [ + "string", + "null" + ] + }, + "tool": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "mcp_tool": { + "type": [ + "string", + "null" + ] + }, + "method": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "why": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "disclaimer": { + "type": [ + "string", + "null" + ] + }, + "next": { + "properties": { + "arguments": { + "properties": { + "tool": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "mcp": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "tool": { + "properties": { + "builder_host": { + "type": [ + "string", + "null" + ] + }, + "buy_vs_build": { + "properties": { + "basis": { + "type": [ + "string", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "verdict": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "category": { + "type": [ + "string", + "null" + ] + }, + "checked": { + "type": [ + "string", + "null" + ] + }, + "compatibility": { + "properties": { + "auth": { + "type": [ + "string", + "null" + ] + }, + "networks": { + "items": { + "type": [ + "string", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "transports": { + "items": { + "type": [ + "string", + "null" + ] + }, + "type": [ + "array", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "does": { + "type": [ + "string", + "null" + ] + }, + "endpoint": { + "type": [ + "string", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "payers_30d_reported": { + "type": [ + "number", + "null" + ] + }, + "payment": { + "type": [ + "string", + "null" + ] + }, + "price": { + "properties": { + "amount": { + "type": [ + "number", + "null" + ] + }, + "as_published": { + "type": [ + "string", + "null" + ] + }, + "asset": { + "type": [ + "string", + "null" + ] + }, + "checked_at": { + "type": [ + "string", + "null" + ] + }, + "rail": { + "type": [ + "string", + "null" + ] + }, + "source_url": { + "type": [ + "string", + "null" + ] + }, + "unit": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "price_published": { + "type": [ + "string", + "null" + ] + }, + "probe": { + "properties": { + "last_probe_at": { + "type": [ + "string", + "null" + ] + }, + "last_status": { + "type": [ + "number", + "null" + ] + }, + "latency_ms_p50": { + "type": [ + "number", + "null" + ] + }, + "latency_ms_p95": { + "type": [ + "number", + "null" + ] + }, + "measures": { + "type": [ + "string", + "null" + ] + }, + "probes_7d": { + "type": [ + "number", + "null" + ] + }, + "stale": { + "type": [ + "boolean", + "null" + ] + }, + "uptime_7d_pct": { + "type": [ + "number", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "provenance": { + "properties": { + "builder_host": { + "type": [ + "string", + "null" + ] + }, + "endpoint_host_matches_builder": { + "type": [ + "boolean", + "null" + ] + }, + "mcp_namespace_verified": {}, + "openssf_score": {}, + "pkg_provenance": {}, + "repo": {} + }, + "type": [ + "object", + "null" + ] + }, + "purpose": { + "type": [ + "string", + "null" + ] + }, + "signal_confidence": { + "properties": { + "buy_vs_build": { + "type": [ + "string", + "null" + ] + }, + "compatibility": { + "type": [ + "string", + "null" + ] + }, + "house_tool": { + "type": [ + "string", + "null" + ] + }, + "price": { + "type": [ + "string", + "null" + ] + }, + "probe": { + "type": [ + "string", + "null" + ] + }, + "provenance": { + "type": [ + "string", + "null" + ] + }, + "purpose": { + "type": [ + "string", + "null" + ] + }, + "test_vectors": { + "type": [ + "string", + "null" + ] + }, + "usage": { + "type": [ + "string", + "null" + ] + }, + "work_for_access": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "source": { + "type": [ + "string", + "null" + ] + }, + "test_vectors": { + "properties": { + "count": { + "type": [ + "number", + "null" + ] + }, + "last_verified_at": {}, + "mode": { + "type": [ + "string", + "null" + ] + }, + "pass_rate_7d": {}, + "vectors_url": {} + }, + "type": [ + "object", + "null" + ] + }, + "usage": { + "properties": { + "payers_30d": { + "type": [ + "number", + "null" + ] + }, + "source": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "work_for_access": { + "properties": { + "note": { + "type": [ + "string", + "null" + ] + }, + "offered": { + "type": [ + "boolean", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + } + }, + "type": "object" +}
- Changed
json_validate1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "errors": { + "type": [ + "array", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "valid": { + "type": [ + "boolean", + "null" + ] + } + }, + "type": "object" +}
- Changed
list_my_tool1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "error": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + } + }, + "type": "object" +}
- Changed
list_tools1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "call_to_action": { + "properties": { + "do_this_next": { + "type": [ + "string", + "null" + ] + }, + "sellers": { + "properties": { + "mcp_tool": { + "type": [ + "string", + "null" + ] + }, + "method": { + "type": [ + "string", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "use": { + "properties": { + "body": { + "properties": { + "tool": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "mcp_tool": { + "type": [ + "string", + "null" + ] + }, + "method": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "want": { + "properties": { + "body": { + "properties": { + "contact": { + "type": [ + "string", + "null" + ] + }, + "tool": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "mcp_tool": { + "type": [ + "string", + "null" + ] + }, + "method": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "why": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "count": { + "type": [ + "number", + "null" + ] + }, + "disclaimer": { + "type": [ + "string", + "null" + ] + }, + "generated": { + "type": [ + "string", + "null" + ] + }, + "next_action": { + "properties": { + "arguments": { + "properties": { + "tool": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "mcp": { + "type": [ + "string", + "null" + ] + }, + "optional": { + "type": [ + "boolean", + "null" + ] + }, + "why": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "tools": { + "items": { + "properties": { + "builder_host": { + "type": [ + "string", + "null" + ] + }, + "buy_vs_build": { + "properties": { + "basis": { + "type": [ + "string", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "verdict": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "category": { + "type": [ + "string", + "null" + ] + }, + "checked": { + "type": [ + "string", + "null" + ] + }, + "compatibility": { + "properties": { + "auth": { + "type": [ + "string", + "null" + ] + }, + "networks": { + "type": [ + "array", + "null" + ] + }, + "transports": { + "type": [ + "array", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "does": { + "type": [ + "string", + "null" + ] + }, + "endpoint": { + "type": [ + "string", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "payers_30d_reported": { + "type": [ + "number", + "null" + ] + }, + "payment": { + "type": [ + "string", + "null" + ] + }, + "price": { + "properties": { + "amount": { + "type": [ + "number", + "null" + ] + }, + "as_published": { + "type": [ + "string", + "null" + ] + }, + "asset": { + "type": [ + "string", + "null" + ] + }, + "checked_at": { + "type": [ + "string", + "null" + ] + }, + "rail": { + "type": [ + "string", + "null" + ] + }, + "source_url": { + "type": [ + "string", + "null" + ] + }, + "unit": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "price_published": { + "type": [ + "string", + "null" + ] + }, + "probe": { + "properties": { + "last_probe_at": { + "type": [ + "string", + "null" + ] + }, + "last_status": { + "type": [ + "number", + "null" + ] + }, + "latency_ms_p50": { + "type": [ + "number", + "null" + ] + }, + "latency_ms_p95": { + "type": [ + "number", + "null" + ] + }, + "measures": { + "type": [ + "string", + "null" + ] + }, + "probes_7d": { + "type": [ + "number", + "null" + ] + }, + "stale": { + "type": [ + "boolean", + "null" + ] + }, + "uptime_7d_pct": { + "type": [ + "number", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "provenance": { + "properties": { + "builder_host": { + "type": [ + "string", + "null" + ] + }, + "endpoint_host_matches_builder": { + "type": [ + "boolean", + "null" + ] + }, + "mcp_namespace_verified": {}, + "openssf_score": {}, + "pkg_provenance": {}, + "repo": {} + }, + "type": [ + "object", + "null" + ] + }, + "purpose": { + "type": [ + "string", + "null" + ] + }, + "signal_confidence": { + "properties": { + "buy_vs_build": { + "type": [ + "string", + "null" + ] + }, + "compatibility": { + "type": [ + "string", + "null" + ] + }, + "house_tool": { + "type": [ + "string", + "null" + ] + }, + "price": { + "type": [ + "string", + "null" + ] + }, + "probe": { + "type": [ + "string", + "null" + ] + }, + "provenance": { + "type": [ + "string", + "null" + ] + }, + "purpose": { + "type": [ + "string", + "null" + ] + }, + "test_vectors": { + "type": [ + "string", + "null" + ] + }, + "usage": { + "type": [ + "string", + "null" + ] + }, + "work_for_access": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "source": { + "type": [ + "string", + "null" + ] + }, + "test_vectors": { + "properties": { + "count": { + "type": [ + "number", + "null" + ] + }, + "last_verified_at": {}, + "mode": { + "type": [ + "string", + "null" + ] + }, + "pass_rate_7d": {}, + "vectors_url": {} + }, + "type": [ + "object", + "null" + ] + }, + "usage": { + "properties": { + "payers_30d": { + "type": [ + "number", + "null" + ] + }, + "source": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "work_for_access": { + "properties": { + "note": { + "type": [ + "string", + "null" + ] + }, + "offered": { + "type": [ + "boolean", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
listing_check1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "fixes": { + "items": { + "type": [ + "string", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "max": { + "type": [ + "number", + "null" + ] + }, + "median_ms": { + "type": [ + "number", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "score": { + "type": [ + "number", + "null" + ] + }, + "tool": { + "type": [ + "string", + "null" + ] + }, + "uptime_7d": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" +}
- Changed
listing_stats1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "error": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + } + }, + "type": "object" +}
- Added
match_tool - Changed
pdf_tables1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "checked_job": { + "properties": { + "optional": { + "type": [ + "boolean", + "null" + ] + }, + "page": { + "type": [ + "string", + "null" + ] + }, + "post_json": { + "properties": { + "fields": { + "properties": { + "email": { + "type": [ + "string", + "null" + ] + }, + "need": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": [ + "string", + "null" + ] + }, + "use_case": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "to": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "what": { + "type": [ + "string", + "null" + ] + }, + "when": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "num_pages": { + "type": [ + "number", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "pages": { + "type": [ + "string", + "null" + ] + }, + "quota": { + "properties": { + "limit": { + "type": [ + "number", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "tier": { + "type": [ + "string", + "null" + ] + }, + "used": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" + }, + "tables": { + "items": { + "properties": { + "cols": { + "type": [ + "number", + "null" + ] + }, + "csv": { + "type": [ + "string", + "null" + ] + }, + "fill": { + "type": [ + "number", + "null" + ] + }, + "numeric_share": { + "type": [ + "number", + "null" + ] + }, + "page": { + "type": [ + "number", + "null" + ] + }, + "rows": { + "type": [ + "number", + "null" + ] + }, + "table": { + "type": [ + "number", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "text_layer": { + "type": [ + "boolean", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + }, + "via": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "ok", + "url", + "pages", + "num_pages", + "text_layer", + "tables", + "checked_job", + "via", + "quota" + ], + "type": "object" +}
- Changed
price_advisor1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "build_vs_buy": { + "properties": { + "assumption": { + "properties": { + "est_tokens": { + "type": [ + "number", + "null" + ] + }, + "override": { + "type": [ + "string", + "null" + ] + }, + "usd_per_mtok": { + "type": [ + "number", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "diy_token_cost_usd": { + "type": [ + "number", + "null" + ] + }, + "savings_per_call_usd": { + "type": [ + "number", + "null" + ] + }, + "say_it": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "built_by": { + "type": [ + "string", + "null" + ] + }, + "comparable_median_per_call_usd": { + "type": [ + "number", + "null" + ] + }, + "comparables": { + "items": { + "properties": { + "name": { + "type": [ + "string", + "null" + ] + }, + "per_call_usd": { + "type": [ + "number", + "null" + ] + }, + "price_published": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "position": { + "type": [ + "string", + "null" + ] + }, + "tool": { + "type": [ + "string", + "null" + ] + }, + "your_per_call_usd": { + "type": [ + "number", + "null" + ] + }, + "your_price_published": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" +}
- Changed
read_page1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "chars": { + "type": [ + "number", + "null" + ] + }, + "content_type": { + "type": [ + "string", + "null" + ] + }, + "cut_at_max_chars": { + "type": [ + "boolean", + "null" + ] + }, + "final_url": { + "type": [ + "string", + "null" + ] + }, + "format": { + "type": [ + "string", + "null" + ] + }, + "ms": { + "type": [ + "number", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "quota": { + "properties": { + "limit": { + "type": [ + "number", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "tier": { + "type": [ + "string", + "null" + ] + }, + "used": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" + }, + "safety_flags": { + "type": [ + "array", + "null" + ] + }, + "source_truncated_at_2MB": { + "type": [ + "boolean", + "null" + ] + }, + "text": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "total_chars": { + "type": [ + "number", + "null" + ] + }, + "untrusted_data": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + }, + "via": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "ok", + "url", + "final_url", + "title", + "via", + "format", + "chars", + "total_chars", + "cut_at_max_chars", + "ms", + "built_by", + "text", + "quota" + ], + "type": "object" +}
- Changed
signal_would_list1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "internal": { + "type": [ + "boolean", + "null" + ] + }, + "kind": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "recorded": { + "type": [ + "boolean", + "null" + ] + } + }, + "type": "object" +}
- Changed
signal_would_use1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "internal": { + "type": [ + "boolean", + "null" + ] + }, + "kind": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "recorded": { + "type": [ + "boolean", + "null" + ] + } + }, + "type": "object" +}
- Changed
similar_tools1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "similar": { + "items": { + "properties": { + "aggregate_tries": { + "type": [ + "number", + "null" + ] + }, + "aggregate_wants": { + "type": [ + "number", + "null" + ] + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "price_published": { + "type": [ + "string", + "null" + ] + }, + "use_url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "tool": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" +}
- Changed
table_to_csv1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "quota": { + "properties": { + "limit": { + "type": [ + "number", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "tier": { + "type": [ + "string", + "null" + ] + }, + "used": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" + }, + "tables": { + "items": { + "properties": { + "cols": { + "type": [ + "number", + "null" + ] + }, + "csv": { + "type": [ + "string", + "null" + ] + }, + "index": { + "type": [ + "number", + "null" + ] + }, + "rows": { + "type": [ + "number", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + }, + "tables_found": { + "type": [ + "number", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "ok", + "url", + "tables_found", + "tables", + "note", + "built_by", + "quota" + ], + "type": "object" +}
- Changed
tool_status1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "built_by": { + "type": [ + "string", + "null" + ] + }, + "count": { + "type": [ + "number", + "null" + ] + }, + "house_tool": { + "type": [ + "boolean", + "null" + ] + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "tools": { + "items": { + "properties": { + "endpoint": { + "type": [ + "string", + "null" + ] + }, + "last_checked": { + "type": [ + "string", + "null" + ] + }, + "last_status": { + "type": [ + "number", + "null" + ] + }, + "median_ms": { + "type": [ + "number", + "null" + ] + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "probes_7d": { + "type": [ + "number", + "null" + ] + }, + "uptime_7d": { + "type": [ + "number", + "null" + ] + }, + "use_url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "type": [ + "array", + "null" + ] + } + }, + "type": "object" +}
- Changed
use_tool1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "disclosure": { + "type": [ + "string", + "null" + ] + }, + "forwarded_to_tool": { + "type": [ + "boolean", + "null" + ] + }, + "identify": { + "type": [ + "string", + "null" + ] + }, + "internal": { + "type": [ + "boolean", + "null" + ] + }, + "listing_status": { + "type": [ + "string", + "null" + ] + }, + "message": { + "type": [ + "string", + "null" + ] + }, + "next": { + "properties": { + "want_this": { + "properties": { + "mcp_tool": { + "type": [ + "string", + "null" + ] + }, + "means": { + "type": [ + "string", + "null" + ] + }, + "params": { + "properties": { + "contact": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "url": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "would_list_here_for_a_cut": { + "type": [ + "string", + "null" + ] + }, + "would_use_at_this_price": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + }, + "paid_use_live": { + "type": [ + "boolean", + "null" + ] + }, + "payment_taken": { + "type": [ + "boolean", + "null" + ] + }, + "purchased": { + "type": [ + "boolean", + "null" + ] + }, + "quote": { + "properties": { + "builder_host": { + "type": [ + "string", + "null" + ] + }, + "checked": { + "type": [ + "string", + "null" + ] + }, + "payment_rail_at_builder": { + "type": [ + "string", + "null" + ] + }, + "price": { + "type": [ + "string", + "null" + ] + }, + "price_detail": { + "properties": { + "amount": { + "type": [ + "number", + "null" + ] + }, + "as_published": { + "type": [ + "string", + "null" + ] + }, + "asset": { + "type": [ + "string", + "null" + ] + }, + "checked_at": { + "type": [ + "string", + "null" + ] + }, + "rail": { + "type": [ + "string", + "null" + ] + }, + "source_url": { + "type": [ + "string", + "null" + ] + }, + "unit": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "price_source": { + "type": [ + "string", + "null" + ] + }, + "terms": { + "type": [ + "string", + "null" + ] + }, + "tool": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + }, + "recorded": { + "type": [ + "boolean", + "null" + ] + }, + "stage": { + "type": [ + "string", + "null" + ] + }, + "use_directly_today": { + "properties": { + "endpoint": { + "type": [ + "string", + "null" + ] + }, + "how": { + "type": [ + "string", + "null" + ] + } + }, + "type": [ + "object", + "null" + ] + } + }, + "type": "object" +}
- Changed
verify_my_listing1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "error": { + "type": [ + "string", + "null" + ] + }, + "ok": { + "type": [ + "boolean", + "null" + ] + } + }, + "type": "object" +}
1 tool update
- Added
pdf_tables
3 tool updates
- Added
fedreg_search - Added
read_page - Added
table_to_csv
1 tool update
- Changed
list_my_tool1 field changed- changed
Input schema / properties / payment / descriptionPrevious value: -"e.g. x402 (USDC), API key + card"New value: +"e.g. x402 (USDC), pay-as-you-go plan"
7 tool updates
- Added
cost_estimate - Added
demand_gaps - Added
get_result - Added
json_validate - Added
listing_check - Added
price_advisor - Added
similar_tools
3 tool updates
- Added
build_or_buy - Added
find_tool - Added
tool_status
3 tool updates
- Added
list_my_tool - Added
listing_stats - Added
verify_my_listing
6 tool updates
- First observed
confirm_want - First observed
get_tool - First observed
list_tools - First observed
signal_would_list - First observed
signal_would_use - First observed
use_tool
Related MCP Connectors
MCP tools for AI agents: render URLs to image/PDF, check link health, convert HTML/CSV/JSON.
Free, no-key MCP server: token estimates, JSON Schema conversion, MCP configs, tool search.
500+ free tools over MCP: dev, text and security utilities, 230+ calculators. No sign-up.
Open-source developer, PDF, image, SEO and security tools over a stateless HTTP MCP server. No key.
Related MCP Servers
- AlicenseAqualityCmaintenanceAn open-source MCP server bundling 50+ local utility tools for PDF processing, web scraping, OCR, data transformation, and more, with zero configuration and no API keys required.5151 npmMIT
- AlicenseAqualityAmaintenanceSix local CPU MCP tools for Markdown/HTML-to-PDF conversion, PDF text extraction, safe SVG-to-PNG rendering, and PDF link and chapter inspection. Linux/WSL2; no GPU, hosted inference API, or model download required.6MIT
- AlicenseNot gradedqualityDmaintenanceWeb scraping MCP server for Al agents. 6 tools: extract clean text/markdown from any URL, structured scraping with CSS selectors, full-page screenshots via Playwright, link extraction with regex filtering, metadata extraction (OG tags, Twitter cards), and Google search. Free tier: 50 requests/IP/day.8MIT
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.