agentic.no

Find inference providers

find_provider

Find online sellers serving a model, cheapest first. A seller's priceUsdPerCall is a flat fee charged per call; for chat and embedding it already includes maxTokensCap, so you pay the same whether or not you use the full token budget. baseUrl is an OpenAI-compatible REST endpoint scoped to this model, for example baseUrl + /v1/chat/completions; mcpUrl is the same seller over MCP. probeScore is how many of the directory's last 20 test calls to the seller passed; sellers failing three in a row are hidden until they pass again. Rows with operator agentic-pool run on agentic.no's pool, on machines rented through vast.ai (country given for sellers): avoid them for sensitive data. Rows with operator agentic are agentic.no's own always-on machines, not rented. After the sellers comes the pool row (slug pool, sellerId null) when the pool lists the model: capacity agentic.no starts on demand. If no seller suits you and pool.disabled is false, call the pool row's baseUrl like any other. A call that has to start capacity answers 503 capacity_starting with Retry-After and is not charged: retry after that many seconds, possibly more than once. 503 capacity_unavailable means nothing can start now (the reason is given) and is not charged either. get_pricing does not apply to the pool row. Payment is x402 (USDC on Base) and happens automatically when you call baseUrl or mcpUrl.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum number of sellers to return, cheapest first; the pool row, if any, is added after them
`model`	Yes	Catalog model id, e.g. qwen2.5-7b-instruct-q4
`maxPriceUsd`	No	Only return offers at or below this USD price per call

Output Schema

TableJSON Schema

Name	Required	Description	Default
`providers`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.6/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 richly: probeScore pass/fail semantics and the three-strikes hiding rule, operator distinctions (agentic-pool vs agentic), 503 capacity_starting/capacity_unavailable behavior with Retry-After, explicit 'not charged' guarantees, and automatic x402 USDC-on-Base payment.

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 core purpose, then dense with operational detail. It is long and spends several sentences explaining response fields (baseUrl, mcpUrl, probeScore) despite an output schema existing, which is slightly over-budget, but each sentence is substantive rather than filler.

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

Completeness5/5

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

For a tool with a fallback pool tier, async capacity startup, retry protocol and automatic payment, the description covers everything an agent needs to act: pricing model, endpoint construction, failure modes, and cost implications of retries.

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 100%, so the baseline is 3. The description nonetheless adds meaning the schema cannot supply: priceUsdPerCall is a flat per-call fee that already includes maxTokensCap, which is exactly the semantics an agent needs to interpret maxPriceUsd correctly.

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?

The first sentence states a specific verb, resource and ordering rule: 'Find online sellers serving a model, cheapest first.' It also implicitly separates itself from get_pricing by explicitly declaring 'get_pricing does not apply to the pool row,' so an agent can tell the two apart 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.

Usage Guidelines4/5

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

Gives concrete routing guidance: avoid agentic-pool rows 'for sensitive data', fall back to the pool row when 'no seller suits you', and how to react to 503 responses. It lacks an explicit comparison to the sibling get_pricing for the normal seller case, only noting where that tool does not apply.

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

All agentic.no tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?