Skip to main content
Glama

Find free LLM models and their rate limits

find_models
Read-only

Which free API tiers serve an LLM model, with the published free-tier rate limits (RPM, RPD, TPM, TPD, requests/month), context window, tool calling and JSON mode (structured output). Same rows and ranking (most requests per day first) as the free LLM API picker. Search by model or provider name, optionally by family.

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

NameRequiredDescriptionDefault
limitNo
queryNoModel or provider name, e.g. "gpt-oss 120b", "gemini 2.5 flash", "groq"; every word must match
familyNoModel family slug, e.g. "gemini", "llama", "qwen", "gpt"
noCardNotrue = only offers that never ask for a card
visionNo
toolCallingNotrue = only models documented with tool calling
structuredOutputNotrue = only models documented with JSON mode or structured output (response_format)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / structuredOutput
      Added value: +{
      +  "description": "true = only models documented with JSON mode or structured output (response_format)",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real behavioral context: the result set mirrors the picker, is ranked most-requests-per-day first, and includes which fields come back. It stops short of stating pagination behavior or what happens when nothing matches.

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?

The core payload (what is returned, how it is ranked) is front-loaded in the first sentence, with filtering guidance following. Dense but every clause carries information; only the 'same rows and ranking as the free LLM API picker' aside is slightly oblique.

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 seven optional parameters and no output schema, the description does the necessary work of naming the returned fields and their ordering. It leaves the limit parameter and default result count unaddressed, which is a minor but real gap for a search tool.

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?

Coverage is 71%, and the description compensates by mapping semantics: query covers model or provider name, family is the optional narrowing, and it explains that tool calling and JSON mode (structured output) are filter dimensions over documented capabilities. vision, noCard and limit go unexplained in prose, keeping it below a 5.

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 a specific resource (free API tiers serving an LLM model) and enumerates exactly what the record contains: rate limits, context window, tool calling, JSON mode. An agent can tell it is a search over free-tier model offers, though it does not explicitly contrast with siblings like list_free_llm_apis or search_free_ai_offers beyond a vague reference to 'the free LLM API picker'.

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?

'Search by model or provider name, optionally by family' implies how to drive the tool, but there is no when-to-use/when-not guidance and no named alternative among the five sibling search/list tools. Usage is inferable rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.