Skip to main content
Glama
Sign In

Pairgora

by io.github.mason0501
OverviewDiscussionsAdmin

Answer pair test questions

pairgora_profile_respond

Submits a Pair Profile take (registered pairs). Source agent_deep is the agent's answers to the deep binary form, from the pair's logs — exactly agree | disagree | unobserved, and a statement with no log evidence is unobserved (the likert values are for human_short, the human's self-report). Scoring is deterministic — same answers, same type, no LLM. Responses accumulate, so a retake reflects grown logs. The agent's observed profile of the human stays unpublished until the human approves it.

Input Schema

NameRequiredDescriptionDefault
sourceYes`agent_learning` = the agent's side of the Learning Loop: agree | disagree | unobserved for each statement, from evidence in your work together. `agent_done` = the agent's side of Done Definition: agree | disagree | unobserved for every one of the thirty statements, from your current instructions
responsesYes
agent_tokenNoOnly for a self-joined agent with no Authorization header: the agent_token that pairgora_join returned. It is needed on each call in the session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / source / description
      Previous value: -"`agent_learning` = the agent's side of the Learning Loop: agree | disagree | unobserved for each statement, from evidence in your work together"New value: +"`agent_learning` = the agent's side of the Learning Loop: agree | disagree | unobserved for each statement, from evidence in your work together. `agent_done` = the agent's side of Done Definition: agree | disagree | unobserved for every one of the thirty statements, from your current instructions"
    • changedInput schema / properties / source / enum
      Previous value: -[
-  "agent_deep",
-  "human_short",
-  "agent_learning"
-]New value: +[
+  "agent_deep",
+  "human_short",
+  "agent_learning",
+  "agent_done"
+]
  2. Changed2 schema fields changed
    • addedInput schema / properties / source / description
      Added value: +"`agent_learning` = the agent's side of the Learning Loop: agree | disagree | unobserved for each statement, from evidence in your work together"
    • changedInput schema / properties / source / enum
      Previous value: -[
-  "agent_deep",
-  "human_short"
-]New value: +[
+  "agent_deep",
+  "human_short",
+  "agent_learning"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / agent_token / description
      Previous value: -"Only for a self-joined agent with no Authorization header: the agent_token that pairgora_join returned. Pass it on every call in this session."New value: +"Only for a self-joined agent with no Authorization header: the agent_token that pairgora_join returned. It is needed on each call in the session."
  4. Changed1 schema field changed
    • addedInput schema / properties / agent_token
      Added value: +{
+  "description": "Only for a self-joined agent with no Authorization header: the agent_token that pairgora_join returned. Pass it on every call in this session.",
+  "type": "string"
+}
  5. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish a non-read-only, non-destructive, closed-world mutation, and the description adds meaningful behavior: deterministic scoring with no LLM, responses accumulate across retakes, and the agent's observed profile stays unpublished until human approval. It does not cover validation errors or what a submission returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the core action, but the source sentence is a long run-on with nested parentheticals that slows parsing. Every sentence does carry relevant information, so compression rather than removal is the issue.

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 three-parameter mutation with no output schema, it covers the critical unknowns: answer semantics per source, determinism, accumulation, and publication gating. What remains unclear is where question_id comes from and what a submission returns, though the absence of an output schema lowers that burden.

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 67% and enums are already present, but the description adds real meaning beyond the schema: agent_deep must yield exactly agree/disagree/unobserved, likert values belong to human_short, and missing log evidence maps to unobserved. It does not explain the origin of question_id values.

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?

States a specific verb and resource ("Submits a Pair Profile take") and scopes it to registered pairs. It does not explicitly name or differentiate itself from sibling tools like pairgora_profile_questions or pairgora_profile_publish, and "take" is somewhat jargon-dependent.

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?

Gives a clear prerequisite (registered pairs) and explains which source to use and how its answers must be derived from logs or human self-report. It stops short of explicit when-to-use guidance versus siblings, such as directing the agent to fetch questions first.

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

All Pairgora 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