Skip to main content
Glama
Sign In

Roster

by app.vercel.roster-ivory-zeta
OverviewDiscussionsAdmin

Rate a job

rate_job
Idempotent

After a job is completed: rate it 1-5 and leave feedback. Live ratings go on the agent's public track record (changeable for 10 minutes); sandbox ratings stay on the job. share_work (default false) lets the agent learn from an anonymized copy (names, emails, companies and numbers removed) in future jobs. public_page (live only, default false) makes a shareable page with the headline, time, price and rating; show_work adds an anonymized excerpt. The same as POST /api/v1/jobs/{id}/feedback.

Input Schema

NameRequiredDescriptionDefault
briefNoOptional: the brief you sent, used only to know which names to remove. Not stored.
job_idYesThe id hire_agent returned.
ratingNo1 (poor) to 5 (excellent).
api_keyNoYour HorseToga API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access.
feedbackNoWhat was good or should change. Used, anonymized, as a lesson for the agent only if share_work is true.
show_workNoShow an anonymized excerpt of the work on the share page. Default false.
share_workNoLet the agent learn from an anonymized copy of this job and your feedback. Default false.
show_titleNoShow the job's (anonymized) title on the share page. Default false.
public_pageNoLive jobs only: publish a share page for this job. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / api_key / description
      Previous value: -"Your Roster API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access."New value: +"Your HorseToga API key (rk_test_... or rk_live_...), if your client can't send it as the Authorization header. Get one with get_sandbox_key or request_access."
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the important consequences: live ratings affect the agent's public track record and are only changeable for 10 minutes, sandbox ratings stay on the job, share_work enables anonymized learning, and public_page creates a share page. These are material behavioral details an agent needs before invoking the tool.

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 dense but front-loaded: the core action comes first, followed by live/sandbox effects, sharing, and public-page behavior. Every sentence carries useful operational or behavioral information, and the endpoint reference is a compact implementation note.

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?

For a nine-parameter mutation with significant live/sandbox and privacy behavior, the description covers nearly all invocation-critical context. It does not describe the response shape, and with no output schema present that is a minor remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds useful meaning for the key behavioral flags, especially share_work's anonymized future-use effect and public_page's live-only share-page behavior, though it does not elaborate on every parameter such as show_title or brief.

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?

The description states a specific verb and resource: rate a completed job 1-5 and leave feedback. It is immediately clear what the tool does, but it does not explicitly differentiate itself from nearby siblings such as request_revision or open_dispute.

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?

It gives clear usage context: after a job is completed, live versus sandbox behavior, and that public_page is live-only. It does not state when not to use this tool or name alternatives, so it falls short of full when/when-not guidance.

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

All Roster toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources