aukro-mcp

Get Seller / User Profile, Ratings Breakdown & Business Info

aukro_get_user_profile

Read-onlyIdempotent

Inspect an Aukro.cz seller or user by username or numeric ID to retrieve registration, ratings, feedback, negative reason counts, absence status, shipping threshold, and seller company/return terms.

Instructions

Inspect an Aukro.cz seller or user by username or numeric userId. Returns registration date, last login, rating score, positive feedback percentage, 4-criteria star averages, detailed negative feedback reason counts, vacation/absence status, free shipping threshold, and (for sellers) company registration details (IČO, DIČ, contact info, warranty/complaint rules, and return policy).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aukro_get_user_profile"
  }
}

Input Schema

Name	Required	Description
`userId`	No	Numeric user ID (provide either `username` or `userId`)
`username`	No	Aukro username (e.g. 'Alza_prodej' or 'Mobilovka')
`includeSellerTerms`	No	When true, fetches company identifiers (IČO/DIČ) and return/complaint policies
`includeFullLegalText`	No	When true, returns full untruncated legal/complaint/return texts (by default truncated to 500 chars for token efficiency)
`includeNegativeReasonBreakdown`	No	When true, fetches detailed negative rating sub-reason breakdown

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 7, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower. The description nonetheless adds substantive behavior: results vary by account type (seller-only company identifiers, warranty/complaint rules, return policy) and presence of vacation status. It omits what happens when neither identifier resolves or whether authentication raises the detail level.

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?

Two sentences, front-loaded with the verb and the two lookup keys, then a single dense payload enumeration. Every clause names a distinct returned field group; nothing is repeated from the title or restated. The length is justified by the absence of an output schema.

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?

With no output schema and five parameters, the description's field enumeration does essential work by telling the agent what comes back, including the cheap-vs-expensive enrichments. It leaves a gap around the zero-required-parameter situation: nothing states that at least one of username or userId must be supplied or what error to expect otherwise.

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 100%, including defaults and the token-efficiency truncation note, so the baseline is 3. The description reinforces the either/or nature of username vs userId and ties the seller-terms payload to seller accounts, but adds no format, constraint, or precedence rules beyond the schema.

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?

Uses a specific verb ('Inspect') plus a precisely scoped resource (an Aukro.cz seller or user) and names both lookup keys. It also enumerates the returned data domains, so the agent knows this is a profile/ratings aggregate rather than a feedback list. It stops short of explicitly distinguishing itself from the sibling aukro_get_user_feedback, which is the nearest ambiguity.

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?

The description never says when to reach for this tool versus aukro_get_user_feedback, aukro_get_seller_leaderboard, or aukro_my_account, and gives no prerequisites or exclusions. The only conditional cue ('for sellers') describes which fields appear, not when to call the tool. Usage is left entirely to inference from the name.

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