Skip to main content
Glama

Gingr MCP by usefulapi

List recent report card files

gingr_list_report_card_files
Read-only

List recently uploaded report card files (photos and videos shared with pet parents), newest first. Gingr: GET /api/v1/report_card_files.

Input Schema

NameRequiredDescriptionDefault
limitNoReturn at most this many files (1-200, default 50).
location_idNoLocation id (from gingr_list_locations).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/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 safety and external data access are covered. The description adds the sort order ('newest first') and content types, but doesn't disclose pagination behavior, rate limits, or what 'recently' means. With annotations covering the safety profile, a 3 is appropriate for the modest additional context.

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 concise sentences with no waste, front-loading the core purpose and then providing the API endpoint and sort order. Every element earns its place.

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?

For a simple read-only list tool with a complete schema and annotations, the description covers the essentials: what it lists, content types, sort order, and the API path. It doesn't need to explain return values (no output schema) or safety (annotations cover it). It could mention pagination or what 'recently' means, but it's largely complete.

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 schema already documents both parameters with their ranges and defaults. The description doesn't add any parameter-specific information beyond what's in the schema, which is the correct baseline when the schema is complete.

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 specific verb and resource ('List recently uploaded report card files') and clarifies the content scope ('photos and videos shared with pet parents'), plus the sort order. It distinguishes itself from sibling list tools like gingr_list_owners or gingr_list_invoices by naming the resource, though it doesn't explicitly contrast with the other list siblings.

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 description implies usage through 'recently uploaded' and 'newest first', but offers no explicit when-to-use guidance or alternatives. There's no mention of when to filter by location_id versus not, though the schema parameter clarifies it comes from gingr_list_locations.

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.