Skip to main content
Glama

Search Skills

search_skills
Read-onlyIdempotent

Find skills across EVERY Heista skill library at once — image craft, fleet foundations and model briefings, Heista DNA creative playbooks, creative agents, and agent skills. Describe the SITUATION you need a skill for in your own words (a brief, a job, a problem) rather than a keyword — results are ranked by how well each skill fits that situation. Optionally restrict to specific libraries. Use this BEFORE load_skill (for disk-backed image/fleet skills) or the get_*_preset tools (for database-backed playbooks, agents and agent skills). Free, read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many skills to return. Default 15.
queryYesThe SITUATION you need a skill for, in your own words — a brief, a job, a problem. Not a keyword. "a packshot of a serum bottle on white for a marketplace listing" finds far more than "product".
familiesNoRestrict to these libraries. Omit to search everything. "image" = Image craft — how a KIND of image is made well. "fleet" = Fleet skills — foundations, registers and model briefings. "playbook" = Heista DNA — creative playbooks a chat agent wears as a lens. "agent" = Creative agents — callable workspace agents with their own character. "agent-skill" = Agent skills — additive craft stacked on top of an agent identity.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rankedYes
skillsYes
took_msYes
returnedYes
unavailableYes
families_searchedYes

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint and idempotentHint, and the description reinforces this with 'read-only' while adding new context: 'Free', the ranking logic, and the distinction between disk-backed and database-backed tools. No contradiction, but the read-only phrase is redundant with annotations.

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?

The description is five sentences, each with a distinct job: scope listing, query style, ranking, optional restriction, and usage context. It is front-loaded with purpose and contains no filler or redundant phrasing.

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?

Given the tool's moderate complexity (three parameters, one required), the description covers purpose, usage, restrictions, cost, and relationships to alternatives. An output schema exists, so explaining return values is unnecessary, and the description fully situates the tool within its ecosystem.

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 input schema already documents all three parameters in detail (including the situation-based query example and family enum meanings), so the description adds little new parameter semantics. It briefly mentions optional restriction to libraries, but schema coverage is 100%, making the baseline 3 appropriate.

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?

Clearly states it finds skills across all Heista skill libraries, enumerating them, and distinguishes itself from sibling tools by naming load_skill and get_*_preset as follow-ups. The description provides specific verb 'Find' and resource 'skills across EVERY Heista skill library'.

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 instructs to use this tool before load_skill or the get_*_preset tools, providing clear alternatives. Also describes the query style (situation, not keyword) and optional library restriction, giving the agent actionable guidance for when and how to invoke it.

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.

TDQS

A3.7/5.0
Disambiguation4/5

Despite the high tool count, most tools have distinct purposes with thorough descriptions that specify when to use each. Some overlap exists among creative direction tools (call_creative_worlds vs chat_with_creative_worlds), but the descriptions clarify usage patterns.

Naming Consistency3/5

Naming conventions are inconsistent overall: some follow verb_noun (create_powersource_url, decode_ad), others use noun_verb or compound names (adformula_intelligence, fleet_analytics_overview). However, subgroups like dispatch_* and list_*_presets maintain internal consistency.

Tool Count2/5

112 tools is far beyond the typical 3-15 range for well-scoped servers. While the server covers a broad domain, the sheer number likely overwhelms agents and suggests insufficient consolidation of related operations.

Completeness4/5

The tool set covers core creative intelligence workflows: brand analysis, ad decoding, script generation, creative direction, and research. Minor gaps exist (e.g., no social media publishing tools), but the main use cases are well-supported.