Relevés de la rubrique Apprendre de Meridal

Prix et caractéristiques d'un modèle

prix_du_modele

Read-onlyIdempotent

Cherche un modèle de langage par nom, identifiant d'API ou fournisseur, et rend son prix par million de tokens (entrée, sortie, entrée en cache, en dollars), sa fenêtre de contexte, sa licence, ses données d'hébergement en Europe et ses sources, à la date du relevé.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "modele": "<modele>"
    },
    "name": "prix_du_modele"
  }
}

Input Schema

Name	Required	Description	Default
`limite`	No	Nombre maximal de modèles rendus (10 par défaut)
`modele`	Yes	Un morceau du nom, de l'identifiant d'API ou du fournisseur : « sonnet », « gpt-6 », « mistral »

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value by noting results are a snapshot 'à la date du relevé', a temporal caveat not in the annotations. It does not mention pagination behavior or result cardinality beyond the schema's limite.

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 front-loaded sentence starting with the verb, with no filler. It is somewhat dense because of the long list of returned fields, but every clause carries information.

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 no output schema, the description correctly carries the burden of describing returns — prices in dollars per million tokens (input/output/cached), context window, license, European hosting and sources. Combined with the read-only annotations, an agent has what it needs; only sibling routing is missing.

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 both parameters are already documented (modele as name/API-id/provider fragment, limite as max results). The description restates the searchable fields but adds no syntax, matching rules, or formatting detail beyond the schema, so baseline 3 applies.

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 (cherche) plus resource (un modèle de langage) and enumerates the returned attributes, so the agent knows this is a model-lookup/price tool. It does not, however, explicitly distinguish itself from siblings like comparer_les_abonnements, which could otherwise seem related.

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 and no named alternative or exclusion. The search-by-name/API-id/provider phrasing implies how to use it, but an agent gets no explicit routing between this tool and comparer_les_abonnements or classement_d_un_test.

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

All Relevés de la rubrique Apprendre de Meridal 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?