Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Find a Hermoso tool by name or task

find_tools
Read-onlyIdempotent

Search all available tools by name, task, or group to uncover missing marketing features. View parameters, credit cost, and health status for each.

Instructions

Search EVERY Hermoso tool — your starting list is deliberately short, and everything else in the product is here — by name, task or group. Each row gives the tool's PARAMETERS in one line, its CREDIT COST (free means free on every plan; a tool that runs a model quotes the live per-model figure) and its recent HEALTH on this server (failure rate and typical duration, or "no recent calls", which means unseen and not broken). Use it the moment the user asks for something you do not see a tool for (a campaign, an ad set, a lead form, a click-to-WhatsApp ad, a report, keywords, audiences): a tool missing from your list is NEVER proof the feature is missing. Then run the tool with call_tool. A tool that is failing or needs a connector this workspace has not made is ranked last and marked, never hidden — pass onlyHealthy:true if you want those left out. Free, read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupNolimit to one group: core, research, create, channels, channel_admin, analytics, ads, files, workspace
limitNohow many to return (default 12, max 40)
queryNowords from the task or the tool name, e.g. "lead form", "whatsapp", "google ads keyword", "meta insights"
onlyHealthyNoleave out tools that are failing their recent calls or that need a connector this workspace has not made. Default false — nothing is hidden unless you ask, because a missing row reads as a missing capability.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.252
    • addedInput schema / properties / onlyHealthy
      Added value: +{
+  "description": "leave out tools that are failing their recent calls or that need a connector this workspace has not made. Default false — nothing is hidden unless you ask, because a missing row reads as a missing capability.",
+  "type": "boolean"
+}
  2. Addedv0.1.209

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses meaningful behaviors: failing tools or those needing missing connectors are 'ranked last and marked, never hidden,' and the meaning of 'no recent calls' is explained. It also clarifies how credit cost is presented (free vs. live per-model figure). This is rich behavioral context beyond the annotations.

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 dense but efficient, covering purpose, usage trigger, output contents, and behavioral nuances in a few sentences. It uses dashes to pack information without redundancy. Slightly long, but every sentence serves a purpose and the key scoping statement is front-loaded.

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

Completeness5/5

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

There is no output schema, but the description compensates by stating exactly what each returned row contains (parameters, credit cost, health). It also covers the critical next step (call_tool) and the onlyHealthy filter. For a discovery tool with optional parameters, this is complete context for an agent to use it correctly.

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?

The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description itself does not add parameter-level semantics beyond what the schema already provides; it only reiterates the onlyHealthy behavior in prose. No additional meaning is given for group, limit, or query beyond their schema descriptions.

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 states a clear verb and resource: 'Search EVERY Hermoso tool ... by name, task or group.' It distinguishes itself from the short default tool list and from siblings by emphasizing that it covers the full tool set and returns metadata (parameters, cost, health). This leaves no ambiguity about what the tool does.

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

Usage Guidelines4/5

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

The description gives an explicit trigger condition: 'Use it the moment the user asks for something you do not see a tool for' and provides concrete examples (campaign, ad set, lead form). It also instructs to follow up with call_tool. It does not explicitly name when-not-to-use alternatives like the list_* tools, so it stops short of a perfect 5.

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