Skip to main content
Glama
ponisha-mcp

ponisha-mcp

by sepehr071

Skill market

pn_market
Read-onlyIdempotent

Summarize demand and supply for one Ponisha skill, including open projects, budgets, competition, and related skills, to assess whether bidding is worthwhile.

Instructions

Summarize demand and supply for one skill on Ponisha: open projects, budgets, competition, related skills.

Use for "is it worth bidding on X", "what do X projects pay" or "how crowded is X". Based on the 50 newest open projects with that skill (budgets in Toman, medians of the project budget midpoints) and the freelancer count for the skill.

Input Schema

NameRequiredDescriptionDefault
skillYesOne skill name, slug or id from pn_skills.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The description adds critical methodology not found in the annotations or schema. It specifies the data scope ('50 newest open projects'), the measurement currency ('Toman'), and the aggregation type ('medians'), providing deep behavioral context about how the summary is constructed.

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 extremely concise, front-loading the purpose in the first sentence and immediately following up with clear, practical use cases. There is no wasted space and every clause serves a functional role.

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 that the input is minimal (a single skill name), the description provides maximal context by detailing the data sources, metrics (Toman/medians), and specific application scenarios, leaving nothing necessary for correct invocation or user expectation management missing.

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?

With 100% schema description coverage, the parameter 'skill' is fully defined by the schema. The description adds minor semantic reinforcement ('for one skill') but does not elaborate on the parameter's function beyond what is already provided by the structured fields. Baseline score 3 is 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?

The description clearly identifies the tool's function: to summarize demand and supply for a specific skill. It distinguishes itself from simple project searches (like pn_search_projects) by providing a synthesis of multiple market indicators.

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?

It provides explicit use cases, guiding the agent to use the tool when the user asks questions related to viability ('is it worth bidding on X'), pay levels, or market competition ('how crowded is X'). This high degree of scenario mapping reduces ambiguity.

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