Skip to main content
Glama

List form presets

list_forms
Read-only

List available upload forms with their size limits, pixel rules, and official sources, then use the returned ID as the form parameter for fit_file.

Instructions

The upload forms FitFileSize has presets for (visa photos, Indian exam and bank applications, and more), each with its size limit, minimum and pixel size, and the official source of those rules. Pass an id to fit_file as form.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds what each returned entry contains (size limit, minimum and pixel size, official source of rules), which goes beyond the annotations. It says nothing about pagination, result count, or how the preset set is maintained, so it is a modest rather than rich addition.

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?

Two sentences, no filler. The content of the listing is stated first and the handoff instruction last, so the most decision-relevant information is front-loaded.

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 parameters and no output schema, the description carries the burden of describing results, and it does so by enumerating the fields each preset exposes plus the official source. The one omission is that the `id` field itself is only implied by the handoff sentence rather than named as part of each entry.

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?

The tool takes zero parameters, so the baseline is 4. The description still adds cross-tool semantic value by identifying that an id from these results maps to fit_file's `form` parameter, giving the agent a reason to read the output.

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 description states a clear resource and scope: the upload form presets FitFileSize supports, with examples (visa photos, Indian exam and bank applications). It also distinguishes this catalog tool from its only sibling by explaining that an id from the results is passed to fit_file as `form`. The verb 'list' is only implied by the title rather than stated in the description, which keeps it just short of a 5.

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?

The closing sentence 'Pass an id to fit_file as `form`' implies the workflow — call this first to discover a valid form id, then pass it to fit_file — but never states that directly. There is no explicit when-to-use/when-not framing or mention of any alternative beyond fit_file. Adequate but inferential.

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

Deploy Server

Other Tools