Skip to main content
Glama

Hermoso

by io.github.hermoso-ai

Run any Hermoso tool by name

call_tool
Destructive

Run ANY Hermoso tool by name — including the paid-campaign, analytics and channel-admin tools that are not in this session's starting list — with the same permissions, the same account and the same result as calling it directly. Get the exact name and its args from find_tools first. This is the route on hosts that cannot reload their tool list mid-conversation (claude.ai, ChatGPT): enable_tools switches a group on server-side, but such a host keeps the list it fetched at connect time. Arguments are validated against the tool's own schema and a mistake is answered with the expected parameters, not a silent default. Refused by name, with the way out, when the tool needs a connector this workspace has not made or is withheld by the host's own policy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNothe tool's arguments as an object, exactly as its own schema takes them
nameYesthe tool name exactly as find_tools returned it, e.g. create_meta_lead_form

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already mark destructiveHint=true and readOnlyHint=false, so mutation risk is known. The description adds valuable behavior: same permissions/account/result as direct call, validation against the target tool's schema with error responses rather than silent defaults, and refusal-with-reason behavior. Each of these goes beyond the annotation booleans.

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?

Four sentences, dense but each adds a distinct fact: capability, provenance, host limitation, validation and refusal behavior. Slightly longer than necessary but well organized and front-loaded with the core capability.

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?

Covers invocation source, host limitation, validation behavior, and failure modes. No output schema exists, so return format is not documented, but for a dynamic dispatcher the critical unknowns (how to find the name, when to use it, what happens on error) are addressed.

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?

Schema coverage is 100% and both parameters are described. The description reinforces 'exact name from find_tools' and 'args exactly as its own schema takes them', which adds practical guidance about provenance and format beyond the schema's generic object description.

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?

The description clearly states it runs any Hermoso tool by name, gives the exact use case (hosts that can't reload tool lists), and differentiates it from enable_tools. It names the resource (any tool by name) and the action (run) with specific scope.

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 to get name/args from find_tools first, explains when this route is needed (claude.ai, ChatGPT hosts that can't reload tool lists mid-conversation), and contrasts with enable_tools. Also discloses refusal cases: missing connectors or host policy.

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

All Hermoso toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation3/5

The descriptions are exceptionally detailed and cross-reference one another (e.g. post_edit vs finish_video vs edit_video), which genuinely helps, but 168 tools still contain tight clusters—video creation/editing, scheduling, and post-publishing—where misselection is easy. Many tools also reference hidden companions not in the visible set, adding ambiguity.

Naming Consistency4/5

The overwhelming majority follow a clear verb_noun snake_case convention (post_to_x, search_x, list_x, create_x, update_x). Minor deviations like store_get, billing_status, error_detail, and the hermoso_ prefix break the pattern slightly but do not obscure it.

Tool Count1/5

At 168 tools this is far beyond the 50+ threshold, and regardless of how broad the platform's purpose is, the sheer number makes the set hard to navigate. The server mitigates with groups and find_tools/call_tool, but the count itself is extreme.

Completeness4/5

The set covers a full marketing lifecycle—research, planning, creation, publishing, scheduling, measurement, billing, and file management—with no major workflow gaps. Some referenced tools like list_shopify_products and manage_meta_post are not in the visible list, but find_tools and call_tool are explicitly designed to close that gap.

Resources