Skip to main content
Glama
cotletdev

PeoplePerHour MCP Server

Get freelancer

get_freelancer
Read-onlyIdempotent

Retrieve a freelancer's public PeoplePerHour profile—rate, stats, skills, portfolio, and recent reviews—from a freelancer ID or profile URL.

Instructions

A freelancer's public profile: rate, stats, skills, portfolio and the latest reviews on the page.

Returns a freelancer's public profile: short name, job title, location, hourly rate, CERT level, rating in percent, review and project counts, skills, languages, full About text, up to 30 portfolio items, and the reviews the profile page shows (usually the latest few, with the project they came from). reviews is the total count; PeoplePerHour does not let older reviews be paged, so only recent_reviews come with text. Times are UTC. Pass a freelancer_id from search_freelancers or an Offer, or the profile URL.

Input Schema

NameRequiredDescriptionDefault
freelancer_idYesfreelancer_id from search_freelancers or an Offer, or the freelancer's profile URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, and open-world safety, and the description adds real behavioral context on top: reviews cannot be paged so only recent_reviews carry text, the reviews field is a total count, portfolio is capped at 30 items, and all times are UTC. These are constraints an agent could not infer from structured fields.

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 opening one-line summary is front-loaded and the detail flows from it, with every clause covering a distinct aspect of the return value. It is slightly redundant, since the lead line and the 'Returns a freelancer's public profile' sentence restate the same scope before getting to specifics.

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?

With no output schema, the description carries the full burden of describing return values, and it does so field-group by field-group including the review-pagination caveat. An agent knows what to expect back and how to interpret the reviews versus recent_reviews distinction.

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 coverage is 100% and the sole parameter's description already explains the accepted ID sources, so the description only restates that same information. A baseline 3 is appropriate since the schema does the heavy lifting and the description adds no new format or syntax detail.

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 and resource and enumerates exactly what comes back: rate, CERT level, rating, skills, About text, portfolio items, and reviews. It is clearly the single-profile counterpart to search_freelancers, so an agent can distinguish it from all listed siblings without opening a schema.

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?

Tells the agent where the required identifier comes from (search_freelancers, an Offer, or a profile URL), which is the practical gating condition for calling it. It does not explicitly say when not to use it or name a competing tool for a given scenario, so it falls short of full routing guidance.

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