llmledger

Overview Schema Source Related Servers Discussions Admin

Find Models

find_models

Read-onlyIdempotent

Lists AI models by task, price, context size, capabilities, and maker, showing each model's cheapest host and rating; or looks up a model by name to list every hosting provider.

Instructions

List the highest rated models for a kind of work within price, prompt size, ability and maker limits, each at its cheapest listing with its rating; or, with name, look one model up and list every host that offers it. Use when browsing or filtering the catalogue, or to find a model's exact name. Not for choosing between named models (compare_models), for a prompt you have in hand (suggest_for_project), or for a budget (estimate_cost).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_models"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	Look up one model by name instead of browsing: all its listings
`task`	No	The kind of work, as Arena rates it	overall
`limit`	No	How many models to list (up to 200 for the whole catalogue)
`maker`	No	Only this maker, for example anthropic or openai
`needs`	No	What the model must be able to do
`min_context`	No	Smallest prompt size the model must take, in tokens
`max_output_price`	No	Highest answer price, dollars per 1M tokens

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.22.0Oct 23, 2026

addedInput schema / properties / limit / description

Added value: +"How many models to list (up to 200 for the whole catalogue)"

changedInput schema / properties / limit / maximum
```
Previous value: -20New value: +200
```

addedInput schema / properties / name

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Look up one model by name instead of browsing: all its listings"
+}

First observedv0.1.7Oct 20, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: browsing returns highest-rated models at their cheapest listing with ratings, while passing `name` switches to a lookup that lists every host offering that model. It does not add much beyond that, but with annotations and an output schema present, this is appropriately informative.

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?

The description is front-loaded with the primary behavior, then usage guidance, then exclusions. Every sentence earns its place, and there is no redundant repetition.

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 7-parameter read-only catalogue tool with a complete input schema, output schema, and explicit annotations, the description gives enough about modes, filters, and alternatives for an agent to call it correctly. Return-value details are correctly left to the output schema.

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%, so all seven parameters are already documented in the input schema. The description reinforces the key filters (price, prompt size, ability, maker limits, and `name` mode) but does not add syntax or edge-case semantics beyond what the schema provides; baseline 3 is appropriate.

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 description states a specific verb and resource: list/filter models, or look up one model by name and list every host offering it. It clearly distinguishes the browse mode from the name-lookup mode, so an agent can tell what the tool does without opening the schema.

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

Usage Guidelines5/5

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

It explicitly says to use this when browsing or filtering the catalogue, or to find a model's exact name. It also names alternatives and exclusions: compare_models for choosing between named models, suggest_for_project for a prompt in hand, and estimate_cost for a budget.

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

Deploy Server