Skip to main content
Glama

recommend

Hand over a user's situation and get the best-matched picks from a Top 11 list. Describe the problem in plain language (e.g. 'startup that needs to get fundraise-ready' or 'reduce no-shows for a dental practice'); optionally add a persona/segment, a budget band ($, $$, $$$), and a max_risk ceiling to exclude firms with higher verified public risk signals. No slug needed. Top 11 auto-picks the most relevant list. Returns the top matches with the reason each was chosen and each pick's risk level.

Input Schema

NameRequiredDescriptionDefault
slugNoOptional list slug. Defaults to the most relevant published list.
limitNoHow many picks to return (default 3).
budgetNoOptional budget band: '$', '$$', or '$$$'.
problemYesThe specific problem or need the user wants solved.
segmentNoOptional persona or vertical, e.g. 'seed-stage SaaS', 'bootstrapped business'.
max_riskNoOptional. Exclude firms whose verified public risk signals exceed this level.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the return content (top matches, the reason each was chosen, each pick's risk level) and the filtering behavior (max_risk excludes firms with higher verified public risk signals). It omits any auth/permission or rate-limit notes, which is a minor gap for a read-only lookup.

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?

Front-loaded with the core action and scope, then optional parameters, then the return shape. The parenthetical examples add length but earn their place by showing expected input style; overall dense but not wasteful.

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 6-parameter, enum-bearing tool with 100% schema coverage and no output schema, the description covers invocation, filtering semantics, and return contents, so an agent can call it correctly. The main unfilled gap is sibling disambiguation against recommend_across_lists.

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%, so baseline is 3, but the description adds genuine meaning beyond the schema: budget band syntax ('$', '$$', '$$$'), the semantics of max_risk as a ceiling that excludes higher-risk firms, and examples of 'problem' phrasing. This exceeds the schema's terse field descriptions.

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

Purpose4/5

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

States a specific verb+resource ('hand over a user's situation and get the best-matched picks') and clarifies scope via the Top 11 list and auto list-selection. It does not, however, differentiate itself from the very similar sibling 'recommend_across_lists', leaving the agent to infer which to call.

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?

Gives clear invocation context — describe the problem in plain language with concrete examples, and notes 'No slug needed' since the list is auto-picked. There are no explicit when-not conditions or named alternatives (e.g. vs recommend_across_lists or pick_one).

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