Skip to main content
Glama

Find tools for a goal

find_tools
Read-only

Search AgentGid for agents, coding tools, APIs, models and stacks that fit a goal, e.g. 'Solana LP copy-trading bot', 'web search API for a research agent under $50/month', 'animate a 2D game UI', 'free fonts for a mobile app'. Returns candidates grouped by kind (libraries and tools, content assets, agents, APIs, guides) with Gid Score, prices, licenses and links. Use this first, then get_tool / get_asset / get_api / get_agent for the full card.

Input Schema

NameRequiredDescriptionDefault
goalYesWhat the user wants to build or do, in plain words
limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  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 declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds the return shape (candidates grouped by kind, with Gid Score, prices, licenses and links), which is real added value. It stops short of mentioning result count, limit behavior, or what an empty result looks like.

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 purpose and the 'use this first' routing are front-loaded, and the example list earns its space by demonstrating query phrasing. The example list is slightly long and the return-value sentence could be tighter, but nothing is filler.

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?

For a read-only search with no output schema, the description covers what comes back, how it is grouped, and the follow-up path. Only the behavior of 'limit' and empty/zero-result handling are left unstated.

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 50% and 'limit' has only bounds/default with no prose; the description partly compensates by showing the style of 'goal' input through four concrete example queries, which clarifies phrasing and granularity better than the schema's 'in plain words'.

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 (Search) and resource (AgentGid catalog) plus the item kinds covered, and the worked examples ('Solana LP copy-trading bot', 'free fonts for a mobile app') pin down the scope far better than an abstract noun could.

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 'Use this first, then get_tool / get_asset / get_api / get_agent for the full card', naming the sibling tools and the ordering condition, so the agent knows both when to call this and what to call next.

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