Skip to main content
Glama

Search production companies

search_companies
Read-onlyIdempotent

Find production companies by name substring (q) or category slug from get_taxonomies. Returns name, categories, description, website, url. For a company's productions, follow with get_company.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
pageNo
limitNo
categoryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, which the description doesn't need to repeat. The description adds the return fields, useful context. But it says nothing about pagination behavior despite page/limit params, which is the main behavioral gap.

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?

Three tight sentences, front-loaded with the search axes, then returns, then the follow-up routing. Every sentence 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?

Returns and follow-up are covered; the main omission is pagination semantics for page/limit and default page size, which an agent needs for a list tool. Otherwise complete for a simple read search.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning. It explains q (name substring) and category (slug from get_taxonomies), but page and limit are left entirely unexplained in both schema and description. Two of four params are undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (find) and resource (production companies) with the search axis (name substring via q, or category slug). Clearly distinguishes from search_productions by naming the entity searched.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says how to get valid category values (get_taxonomies) and names get_company as the follow-up for a company's productions, routing the agent across siblings. No ambiguity about when to use this versus the other tools.

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.

Resources