Skip to main content
Glama

get_smart_recommendations

Get freelance gig recommendations by skills and budget, with win probability and suggested pricing to prioritize which projects to pursue.

Instructions

Get AI-powered gig recommendations with success prediction and optimal pricing

Args:
    skills: List of skills to match against
    max_budget: Maximum budget filter
    min_budget: Minimum budget filter
    platforms: Platforms to search
    top_n: Number of recommendations to return
    use_real_api: Use real API or mock data

Returns:
    AI-powered recommendations with win probability, optimal pricing, and strategy

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
top_nNo
skillsYes
platformsNo
max_budgetNo
min_budgetNo
use_real_apiNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that the tool can operate against real or mock data ('use_real_api') and that results include win probability, optimal pricing, and strategy. It does not state cost, latency, rate limits, or whether recommendations are persisted, leaving real behavioral gaps for a 6-param analysis tool.

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 lands in the first sentence, and the Args/Returns blocks are compact with no filler. The list-style formatting is slightly mechanical but appropriately sized for a six-parameter tool.

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

Completeness3/5

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

An output schema exists, so the Returns sentence is largely redundant, and the definition never routes the agent between this tool and its many siblings in the recommendation/pricing family. The bare one-line argument glosses leave the highest-complexity decisions (platform selection, budget semantics) underspecified.

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?

Schema description coverage is 0%, so the description must compensate and it does partially: it glosses all six parameters, e.g. top_n as 'Number of recommendations to return'. However the glosses largely restate the parameter names, and it omits meaningful semantics such as what a null platforms/budget means (all platforms, no bound) or the units/currency of the budgets.

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 and resource ('Get AI-powered gig recommendations') plus the differentiating payload (success prediction, optimal pricing). It is distinguishable from search_gigs at a high level, but never explicitly contrasts itself with that sibling, so a 4 rather than a 5.

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

Usage Guidelines2/5

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

There is no indication of when to use this tool versus search_gigs, calculate_pricing_strategy, or analyze_skill_demand, and no prerequisites or exclusions are stated. The only usage-adjacent hint is the use_real_api flag, which is a mode switch rather than guidance.

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