get_meGet your own identity and capabilities: user id, username, join date, rating, and whether you can currently post a job or place a bid -- with why not and where to fix it, if not.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although the readOnlyHint annotation already marks this as a safe read operation, the description enriches transparency by disclosing that it also reports capability checks ('whether you can currently post a job or place a bid') and even includes guidance ('with why not and where to fix it'). This goes beyond the schema and annotations, giving agents behavioral insight into what the response contains without contradicting the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, information-dense sentence. It front-loads the primary purpose, lists the key output fields in a natural list, and adds the capability-check nuance without a single wasted word. Every element earns its place, making it exemplary in conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool, the description covers all essential aspects: returns identity fields and capability status. While it doesn't detail the exact response schema (e.g., JSON structure or data types), the absence of parameters and the simplicity of the self-inspection use case mean the description is nearly complete. A minor enhancement would be noting the response is for the authenticated user, but that is implicitly obvious from 'your own identity.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is trivially complete. The description indirectly reinforces that no arguments are needed by focusing entirely on the implicit context (the caller's identity), which aligns with the baseline score of 4 for parameterless tools. No additional parameter-level explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear resource ('your own identity and capabilities'), and enumerates concrete data points (user id, username, join date, rating, posting/bidding eligibility). This clearly distinguishes it from sibling tools like 'get_user' by explicitly scoping to the caller's own record, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (to inspect your own identity and capabilities) versus siblings like 'get_user' for other users. While it doesn't explicitly name alternatives or state when *not* to use it, the self-referential framing makes the intended use unmistakable, providing clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action: job lifecycle, bidding, messaging, ratings, users, and documents all have clear boundaries. Even the several list tools (browse_jobs, get_my_jobs, get_user_jobs, get_bids) are differentiated by scope and described without overlap.
All tool names follow a consistent snake_case verb_noun pattern, e.g. accept_bid, cancel_job, submit_rating, withdraw_bid. The use of browse_ for public directory listings and get_ for specific or contextual retrievals is a predictable and coherent convention.
20 tools is in the heavy range for an agent to navigate, even though the freelance marketplace domain justifies most of them. The count is borderline rather than excessive, but it exceeds the typical well-scoped 3-15 tool sweet spot.
The core lifecycle is well covered: job posting and browsing, bidding and acceptance, completion/cancellation, request_close for stalled jobs, messaging, and ratings. The main gaps are the lack of job or bid editing and the absence of an explicit dispute mechanism, but agents can work around these using cancel_job and request_close.