Skip to main content
Glama

Crovia — verifiable silence (TACET) and Crovia Seal

Page of model ids

search_models
Read-only

A page of observed model ids whose id contains query, compared case-insensitively, in catalog order, not a ranking. query omitted or empty matches the whole catalog and still returns at most limit rows. limit follows the historical rule: a missing, empty, zero or other falsy value is 25; any value int() accepts is then clamped into 1..100 (500 becomes 100, a negative becomes 1); a value int() cannot parse is an error and nothing is searched. returned and its compatibility alias count are the rows in this page. matched is how many ids match before the limit. catalog_total and its compatibility alias total_records are every record in the catalog, matching or not. limit is the limit actually applied. count is not the match count, and total_records is not the match count. This is not a verdict and not a proof. Reads published files only.

Input Schema

NameRequiredDescriptionDefault
limitNoPage size. Omitted, empty, 0 or any other falsy value means 25. A value int() accepts is clamped into 1..100: 500 is fetched as 100 and a negative as 1. There is no schema minimum or maximum, because those would reject the values the server clamps. A value int() cannot parse is an error and nothing is searched.
queryNoSubstring of the model id. Omit it, or pass an empty string, to match the whole catalog. The page is still capped by limit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / limit / default
      Added value: +25
    • addedInput schema / properties / limit / description
      Added value: +"Page size. Omitted, empty, 0 or any other falsy value means 25. A value int() accepts is clamped into 1..100: 500 is fetched as 100 and a negative as 1. There is no schema minimum or maximum, because those would reject the values the server clamps. A value int() cannot parse is an error and nothing is searched."
    • removedInput schema / properties / limit / maximum
      Removed value: -100
    • removedInput schema / properties / limit / minimum
      Removed value: -1
    • addedInput schema / properties / query / description
      Added value: +"Substring of the model id. Omit it, or pass an empty string, to match the whole catalog. The page is still capped by limit."
  2. First observed

TDQS

A3.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint; the description goes well beyond them by disclosing the limit coercion rules (falsy -> 25, clamp into 1..100, unparseable -> hard error with no search performed), the catalog-vs-match ordering, and the read scope ('published files only'). This is exactly the kind of behavioral detail annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the middle of the description is a dense run-on chain of return-field disambiguations and defensive restatements ('count is not the match count, and total_records is not the match count. This is not a verdict and not a proof.'). Several sentences repeat the same caveat rather than adding 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 spends its budget documenting return fields (returned/count, matched, catalog_total/total_records, limit) and the limit failure mode. It is nearly complete for a two-parameter search, though it omits how to page past the first result set and gives no sibling routing.

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 coverage is 100%, so the baseline is 3; the description's limit and query sentences largely restate the schema text verbatim rather than adding syntax or format meaning. It adds no parameter information the schema does not already contain.

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?

The opening sentence names the resource (observed model ids), the matching rule (case-insensitive substring on id) and the ordering (catalog order, not a ranking), which is enough to distinguish this from a scoring/verdict tool. It stops short of naming the obvious alternative (lookup_model) for exact-id retrieval, so sibling differentiation is only partial.

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?

It tells the agent what the tool is not ('not a ranking', 'not a verdict and not a proof') and that it 'Reads published files only', but never states when to choose this over lookup_model or the other siblings, nor any prerequisites. Usage has to be inferred entirely from the matching semantics.

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.