Specialist tools for any job — a lead, an image, a song, live data, and more.
Scored across 7 tools
Each tool targets a distinct step of the pay-per-call lifecycle (discover → quote → call → get_result, plus balance/rate/feedback), and the descriptions explicitly hand off edge cases between quote/call and rate/feedback. The only fuzziness is between `call` (which also polls async jobs) and `get_result` (which recovers timed-out calls), where an agent must read carefully to pick the right recovery path.
All names are lowercase snake_case with single, concrete verbs (balance, call, discover, quote, rate, feedback, get_result). Only `get_result` uses a verb_noun form while the rest are bare words, a minor deviation that is still readable.
Seven tools cleanly map to the gateway's workflow without redundancy: catalog search, price check, paid execution, result retrieval, balance, rating, and feedback. Nothing feels padded or missing at this scale.
The core purchase lifecycle and both feedback channels are covered, including result recovery after timeouts and job-status polling. Minor gaps exist around account funding/top-up, a durable transaction/usage history beyond the 60-minute result window, and browsing the catalog by category rather than only keyword or domain.
The connected account's remaining prepaid balance in USD, and what it has spent so far. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds a genuinely useful trait not present in structured data: the call itself is "Free", which matters for cost-aware planning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the returned resource (remaining balance) and appends the secondary fact (spend so far) plus the cost note. No filler, no redundancy with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly names both returned values (remaining balance and spend). It omits minor details such as freshness/refresh behavior or whether balance can go negative, but it is adequate for a no-argument read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters (100% schema coverage, empty object), so the baseline is 4; there is nothing parameter-related to document or clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"The connected account's remaining prepaid balance in USD, and what it has spent so far" names a concrete resource and its scope, and the title supplies the missing verb ("Check"). It does not need sibling differentiation since none of call/discover/feedback/get_result/quote/rate touch balance, but it also never states that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the trailing "Free." hints this is a zero-cost probe an agent can run before paid operations, but there is no explicit when-to-use, prerequisite, or alternative named. An agent can infer the intent but is given no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call one of the discovered endpoints and pay for it from the user's balance. This is the only tool here that spends anything. quote the same request first to read the real price off the endpoint's HTTP-402 challenge, then repeat it here with max_amount_usd set to that quote — always send it, so a repriced endpoint cannot charge more than the price you read. Calls above $10 are refused; max_amount_usd can tighten that ceiling further. Charged only when the endpoint delivers: a rejection before the call and an upstream error are free. A successful call is charged even when its answer is empty or useless; no refund follows, so rate the endpoint down with a report and check balance if a paid response looks wrong. An async job is one purchase: polling its task id to a terminal status belongs to the submit, approved or not, and counts toward the task budget. Poll its status URL with this tool too: the job belongs to the wallet that paid for it, so a direct request is refused. Polls can be charged: poll at the documented cadence, or every 20 seconds past the typical completion time. After 30 polls, stop and tell the user the job is still running. Resubmitting buys it twice.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | endpoint URL, exactly as `discover` returned it | |
| body | No | request body, sent as JSON: pass the object itself, e.g. {"prompt": "a cat"}, not a JSON-encoded string | |
| model | No | your own model id, e.g. claude-opus-5. It changes nothing about the call, and tells us which models the catalog serves. Skip it if you are not sure. | |
| method | No | HTTP method (default GET) | |
| dry_run | No | quote the real price without paying, same as `quote` | |
| headers | No | extra request headers, no auth headers needed | |
| max_amount_usd | No | your spend ceiling for this call, in USD. Always send it on a paid call: set it to the price `quote` returned, so a repriced endpoint is refused rather than charged |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say non-readonly, open-world, non-idempotent; the description carries the real cost model: $10 hard ceiling, max_amount_usd as a tightening cap, free on pre-call rejection or upstream error, charged even for empty/useless answers, no refunds. Async-job ownership (wallet-bound, direct requests refused) is context no annotation could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then a dense chain of constraints where nearly every sentence adds a distinct rule (ceiling, free failures, no refunds, async ownership, poll cadence). It is long and unsegmented relative to typical descriptions, but the payment complexity justifies most of the length; bullets would improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the hard parts — spend ceiling, failure billing, async job lifecycle, polling budget — for a 7-param open-world tool. The one gap is that with no output schema, the description never says what a successful call returns (the endpoint's raw response/body), which an agent must infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics for `max_amount_usd` (set it to the quoted price, always send it so repricing fails closed) and ties `url` to the discover output. The remaining params (method, headers, model, dry_run) are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Call one of the discovered endpoints and pay for it from the user's balance,' and it immediately separates itself from siblings ('the only tool here that spends anything'). It also names `quote`, `balance`, and a report/rate action, so an agent can route between tools without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sequencing: quote first, then repeat with max_amount_usd set to that quote; always send it. Polling rules are spelled out (documented cadence, every 20s past typical completion, stop after 30 polls), plus the exclusion 'resubmitting buys it twice.' This is when/when-not/alternatives at full strength.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a paid endpoint for a capability you lack: image, video, music or speech generation, transcription, email finding and verification, people and company enrichment, social and market data, travel, OCR, translation, sending email, phone calls or letters. Free: searching the catalog costs nothing. Keyword search is the fastest path from a task to an endpoint: pass query. No results is a real answer: nothing offers that term. Read an endpoint's full docs before its first call: a search hit is a one-line summary, required parameters and their allowed values are only in the docs, and a guessed value the endpoint accepts is charged at that value's price. Pass domain to list one service's endpoints, url + method together for one endpoint's full docs (parameters, request-body schema), or no arguments at all for the allowed service domains.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | an endpoint URL. With `method`, returns its full docs | |
| query | No | keywords to search every service's endpoints | |
| domain | No | restrict to one service domain, e.g. 2s.io | |
| method | No | HTTP method, required alongside `url` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing cost semantics (catalog search is free; a guessed value the endpoint accepts is billed at that value's price) and negative-result semantics ('no results is a real answer'). It does not mention result caps, pagination, or how many hits a query returns, which is the remaining behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then cost, then the argument recipes — a sensible order with no filler sentences. The capability enumeration is long but arguably load-bearing for a discovery tool; the colon-and-dash stacking makes it denser than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-format burden and largely meets it: a search hit is a one-line summary, while `url`+`method` yields full docs including parameter schema. Minor omission is what a domain listing or empty-argument response actually contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining the combination rules the schema cannot express — that `url` and `method` must be supplied together and what that pair yields (parameters, request-body schema), and that all-empty arguments returns the allowed service domains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find a paid endpoint for a capability you lack') and enumerates the capability space so an agent knows the coverage boundary immediately. It is clearly distinguishable from siblings like `call`, `quote`, and `balance`, which operate on endpoints already known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes between the three calling modes: `query` for keyword search ('the fastest path from a task to an endpoint'), `domain` to list one service's endpoints, `url`+`method` for full docs, and no arguments for allowed domains. It also imposes a sequencing rule — read full docs before the first call — with the reason (search hits are one-line summaries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell taskfuel (the gateway, not any provider) what worked and what got in the way: setup or connection trouble, discovery that found nothing or the wrong things, billing or balance confusion, wrong docs, a capability missing from the catalog, or one failure pattern you hit across several endpoints. A problem with a single endpoint's own behavior belongs in rate instead. Send it when you actually hit something, once per problem; do not include secrets or response data.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | what happened and what you expected, briefly and concretely. Up to 2000 characters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (not read-only, not destructive, not idempotent, closed-world), and the description reinforces the non-idempotent nature with 'once per problem' while adding data-handling constraints ('do not include secrets or response data'). It does not say who consumes the feedback or what happens after submission, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all earning their place, with the routing constraint and the `rate` alternative front-loaded. The middle enumeration of feedback categories is long but each item is a distinct actionable trigger, so it is informative rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A single-parameter, no-output-schema tool whose annotations already declare the mutation profile. The description supplies purpose, triggers, exclusions, the sibling alternative, and data-handling rules -- everything an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and schema coverage is 100%, with the schema already carrying type, min/max length, and a description. The description reinforces intent ('briefly and concretely') and adds an exclusion (no secrets or response data), but adds little syntax beyond what the schema states -- baseline 3 is right when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Tell taskfuel ... what worked and what got in the way') and immediately disambiguates the target ('the gateway, not any provider'). It also names the sibling `rate` and the condition that separates the two, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use triggers (setup/connection trouble, empty or wrong discovery, billing confusion, wrong docs, missing capability, a repeated failure pattern), an explicit when-not with the alternative ('a single endpoint's own behavior belongs in `rate`'), and cadence guidance ('once per problem'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the response from a paid call you already made. Free: the call is already paid for. Use it when call never returned. A long generative endpoint can outrun your client's own request timeout, and the call is charged and completed regardless, so the result is yours. Do NOT repeat the call in that situation: that is a second charge for work already bought. Call this with no arguments to list your recent paid calls, newest first, and pass the request_id of the one you want. Results are kept for 60 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | the call to fetch. Omit to list your recent paid calls and their request ids |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/idempotentHint already declaring the safety profile, the description still adds real value: it is free (no additional charge), results expire after 60 minutes, and omitting the argument lists recent calls newest-first. It does not describe the response payload shape, though that is partly inferred from the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tight, front-loaded prose: what it does, when to use it, the costly mistake to avoid, then the invocation pattern and retention limit. Every sentence carries operative information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter read tool with no output schema, the description covers the call pattern, the listing fallback, the cost model, and the 60-minute retention window. Nothing an agent needs to invoke it correctly or decide between it and `call` is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds ordering semantics ('newest first') and the purpose of the omitted-argument mode that the schema field description only gestures at. It clarifies intent rather than merely restating the property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('get the response from a paid call you already made') and immediately separates itself from the sibling `call` by framing it as a post-hoc fetch. An agent can distinguish it from `call`, `quote`, `balance`, and `rate` 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the trigger condition ('use it when `call` never returned'), explains the mechanism (client timeout while the call still completes and charges), and states the exclusion with a reason ('Do NOT repeat the `call`... that is a second charge'). Alternatives and non-usage are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what one request would cost, without paying. Free: it sends the real request and stops at the endpoint's HTTP-402 challenge, so the price it returns is the authoritative price for that exact payload rather than an estimate. Send the identical arguments to call afterwards, with max_amount_usd set to the quote. It never executes anything: an endpoint whose spec declares no price is refused with not_quotable and nothing is sent. Call it directly if you mean to run it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | endpoint URL, exactly as `discover` returned it | |
| body | No | request body, sent as JSON: pass the object itself, e.g. {"prompt": "a cat"}, not a JSON-encoded string | |
| model | No | your own model id, e.g. claude-opus-5. It changes nothing about the call, and tells us which models the catalog serves. Skip it if you are not sure. | |
| method | No | HTTP method (default GET) | |
| headers | No | extra request headers, no auth headers needed | |
| max_amount_usd | No | your spend ceiling for this call, in USD. Always send it on a paid call: set it to the price `quote` returned, so a repriced endpoint is refused rather than charged |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it is free, it actually transmits the request and halts at the endpoint's HTTP-402 challenge, so the price is authoritative rather than an estimate, and nothing is ever executed (no-price endpoints return `not_quotable` with nothing sent). The only mild oddity is that the annotations mark idempotentHint=false, which the description does not explain given the read-only framing, but this is not a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core value proposition ('read what one request would cost, without paying') and every sentence carries operational content. Slightly redundant in restating non-execution twice ('stops at the HTTP-402 challenge' and 'It never executes anything'), which costs it the top mark.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no output schema, the description covers the return value (the authoritative price), the free/non-charging behavior, the error branch, and the pairing with `call`. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all six parameters, including the `max_amount_usd` ceiling semantics and the `model` no-op. The description reinforces the quote→call handoff ('identical arguments', ceiling set to the returned price) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource ('Read what one request would cost') and immediately contrasts with the paid alternative ('without paying'), naming `call` as the follow-up. An agent can distinguish `quote` from `rate`, `balance`, and `call` 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit workflow: send the identical arguments to `call` afterwards with `max_amount_usd` set to the quote, and 'Call it directly if you mean to run it.' It also names the failure branch (endpoints with no declared price are refused with `not_quotable`), leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate a documented endpoint you called, using the method and url exactly as discover returns them: vote up if you got the expected/useful result, down if it didn't work or wasn't worth the price. Rate it against its own docs, from a call you made. Not down-votes: a missing catalog entry, your own bad arguments, or an endpoint that worked but wasn't what your task needed. Vote and report must agree. Add report to describe what concretely disrupted usage: an unexpected response code, ignored arguments, an empty or low-quality response (it doesn't change the rating). One vote per endpoint, changeable at any time: voting again replaces your previous vote. For problems with taskfuel itself rather than one endpoint, use feedback.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | the endpoint URL, as `discover` returned it | |
| vote | Yes | up = you got the expected/useful result; down = it didn't work or wasn't worth the price | |
| method | Yes | HTTP method of the endpoint, as `discover` returned it | |
| report | No | what concretely disrupted usage (unexpected response code, ignored arguments, low-quality response); do not include secrets or response data. Up to 2000 characters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true, so the mutation/idempotency profile is partly structured. The description still adds real operational context beyond them: re-voting replaces the prior vote, vote and report must agree, and `report` does not affect the rating. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and scoping before the exceptions, and each clause does work. It is longer than strictly necessary, with some redundancy between the vote definition in the description and the schema's `vote` description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter mutation tool with no output schema, the description covers the full decision surface: rating criteria, anti-patterns to avoid, report semantics, re-vote behavior, and the correct sibling for off-topic issues. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented, making 3 the baseline. The description reinforces that `method`/`url` must match `discover` output exactly and explains the intent of `report`, but adds little syntactic detail the schema does not already carry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('rate a documented endpoint you called') and immediately anchors the identifiers to how `discover` returns them. It is clearly distinguishable from siblings like `feedback`, which it names as the tool for taskfuel-level problems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use both directions (up for expected/useful, down for broken or not worth the price), plus a negative list of things that must NOT be down-voted (missing catalog entry, own bad arguments, worked-but-wrong-fit) and an explicit routing rule to `feedback` for platform issues. One-vote-per-endpoint and changeability are also stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
call2 fields changedInput schema / properties / dry_run / descriptionPrevious value: -"quote the real price without paying"New value: +"quote the real price without paying, same as `quote`"Input schema / properties / max_amount_usd / descriptionPrevious value: -"your own spend ceiling for this call, in USD"New value: +"your spend ceiling for this call, in USD. Always send it on a paid call: set it to the price `quote` returned, so a repriced endpoint is refused rather than charged"quoteget_resultfeedback6 fields changedInput schema / properties / messageAdded value: +{
+ "description": "what happened and what you expected, briefly and concretely. Up to 2000 characters",
+ "maxLength": 2000,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / methodRemoved value: -{
- "description": "HTTP method of the endpoint, as `discover` returned it",
- "minLength": 1,
- "type": "string"
-}Input schema / properties / reportRemoved value: -{
- "description": "what concretely disrupted usage (unexpected response code, ignored arguments, low-quality response); do not include secrets or response data. Up to 2000 characters",
- "maxLength": 2000,
- "minLength": 1,
- "type": "string"
-}Input schema / properties / urlRemoved value: -{
- "description": "the endpoint URL, as `discover` returned it",
- "minLength": 1,
- "type": "string"
-}Input schema / properties / voteRemoved value: -{
- "description": "up = you got the expected/useful result; down = it didn't work or wasn't worth the price",
- "enum": [
- "up",
- "down"
- ],
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "method",
- "url",
- "vote"
-]New value: +[
+ "message"
+]ratecall1 field changedInput schema / properties / modelAdded value: +{
+ "description": "your own model id, e.g. claude-opus-5. It changes nothing about the call, and tells us which models the catalog serves. Skip it if you are not sure.",
+ "type": "string"
+}feedback1 field changedInput schema / properties / report / descriptionPrevious value: -"what concretely disrupted usage (unexpected response code, ignored arguments, low-quality response); do not include secrets or response data"New value: +"what concretely disrupted usage (unexpected response code, ignored arguments, low-quality response); do not include secrets or response data. Up to 2000 characters"call2 fields changedInput schema / properties / body / descriptionPrevious value: -"request body, sent as JSON — pass the object itself, e.g. {\"prompt\": \"a cat\"}, not a JSON-encoded string"New value: +"request body, sent as JSON: pass the object itself, e.g. {\"prompt\": \"a cat\"}, not a JSON-encoded string"Input schema / properties / headers / descriptionPrevious value: -"extra request headers — no auth headers needed"New value: +"extra request headers, no auth headers needed"discover1 field changedInput schema / properties / url / descriptionPrevious value: -"an endpoint URL — with `method`, returns its full docs"New value: +"an endpoint URL. With `method`, returns its full docs"feedbackbalance2 fields changedInput schema / properties / contextRemoved value: -{
- "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "context"
-]call2 fields changedInput schema / properties / contextRemoved value: -{
- "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "url",
- "context"
-]New value: +[
+ "url"
+]discover2 fields changedInput schema / properties / contextRemoved value: -{
- "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "context"
-]balance2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]call2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "url"
-]New value: +[
+ "url",
+ "context"
+]discover2 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "context"
+]balancecalldiscover
Add one secure layer between your agents and this server.