Skip to main content
Glama

Find drawing references

find_references
Read-onlyIdempotent

SVG Lab's reference pictures for one planned illustration (illustration, query): Creative Commons first, each with its licence, no stock-agency previews; candidates are for you only.

Input Schema

NameRequiredDescriptionDefault
countNoHow many candidates, 4 to 10 (default 8).
queryYesIts subject, pose and view, e.g. "warehouse with open loading bay".
styleNoclipart (default) for flat and cartoon illustration, lineart for line drawings.
illustrationYesThe planned illustration this search is for, by its name in plan_illustrations.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already disclose read-only, open-world, idempotent, non-destructive behavior; the description adds useful extra traits: Creative Commons prioritization, per-candidate licence information, exclusion of stock-agency previews, and that candidates are 'for you only.' It still does not describe result format or limits, so it is not a 5.

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 description is a single front-loaded sentence with no filler, and the key scope and licensing constraints come early. The parenthetical '(illustration, query)' is slightly awkward but not harmful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search tool with rich annotations and fully described parameters, the description covers purpose and content policy. However, with no output schema and no description of what a candidate result contains or how it relates to plan_illustrations, some context is still 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 all four parameters are already documented in the schema. The description only calls out illustration and query and adds no syntax or meaning for count/style beyond the schema, making the baseline 3 appropriate.

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 names a specific resource—'reference pictures for one planned illustration'—and scopes it with 'Creative Commons first' and 'no stock-agency previews,' which distinguishes it from stock-photo search. It lacks an explicit verb and does not name the sibling alternative, so it falls 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?

It implies the usage context ('one planned illustration') and content policy (Creative Commons first, no stock-agency previews), but never explicitly says when to choose this over search_photos or generate_illustration. The alternative-selection guidance is inferable rather than explicit.

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.