Freelance MCP Server

analyze_skill_demand

Analyze market demand for specific skills to help freelancers with insights on demand, rates, and trends.

Instructions

Analyze market demand for specific skills

Args:
    skills: List of skills to analyze
    use_real_api: Use real API or mock data

Returns:
    Market insights for each skill including demand, rates, and trends

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "skills": "<skills>"
    },
    "name": "analyze_skill_demand"
  }
}

Input Schema

Name	Required	Description	Default
`skills`	Yes
`use_real_api`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.1.0Sep 13, 2026

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It implies a read-only analysis but never states that changes are non-destructive, what data source/credentials are needed, or how the real-vs-mock API mode behaves operationally. Only the mock/real toggle hints at any behavioral trait.

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?

Docstring structure is compact and front-loads the purpose ahead of Args/Returns. Every line is short, though the Args section adds little beyond the schema field names.

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?

An output schema exists, so return-value documentation is not strictly required, and the description still sketches the shape (demand, rates, trends). For a two-parameter, one-required analysis tool this is largely complete; only usage routing and behavioral context are thin.

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 is the only source for both parameters. It briefly explains 'use_real_api' as real vs mock data (adding some meaning over the bare schema) but restates 'skills' trivially as 'List of skills to analyze' without format, count, or example expectations.

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 ('Analyze market demand for specific skills'), which is concrete and actionable. It doesn't however distinguish itself from adjacent siblings like calculate_pricing_strategy or analyze_profile_fit, so an agent must infer which analysis tool fits.

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?

No when-to-use guidance, no prerequisites, and no named alternatives. With 17 siblings that overlap in the analytics space (analyze_profile_fit, calculate_pricing_strategy, research_client_intel), the description leaves routing entirely to inference.

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

Deploy Server