Pairgora

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

With no annotations, the description must disclose behavioral traits, but it only briefly mentions 'registered pairs' and the envelope concept. It omits side effects (e.g., state changes), required context, or error scenarios, leaving the agent with insufficient behavioral guidance.

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 description is a single efficient sentence that conveys the core action. However, it could be improved by structuring into purpose and mechanism bullets without adding length. No waste, but slightly cryptic for an agent.

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?

Given no output schema, no annotations, and a complex nested input, the description is too minimal to fully guide an agent. It does not explain return values, session management behavior, or how the envelope is processed, leaving gaps in completeness.

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?

The schema has 100% coverage, so the baseline is 3. The description adds conceptual framing ('your context envelope') but does not elaborate on individual parameter fields like focus or tags beyond the schema's own descriptions. It provides minimal additional semantic value.

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 clearly states the verb 'Open/refresh' and resource 'your pair session', distinguishing it from siblings like pairgora_join (joining a session) or pairgora_perform (executing actions). The phrase 'send your context envelope across the input boundary' adds specificity to the action.

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 implies this tool is for initiating or refreshing a pair session, but it does not explicitly state when to use over alternatives (e.g., pairgora_join for joining an existing session). No when-not or prerequisites are mentioned.

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

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

With no annotations, the description bears full burden. It discloses the core behavior: declaring model_base/service_tier and issuing a weak-signal credential, plus the future promotion path. No side effects or contradictions.

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?

Two sentences efficiently convey purpose, behavior, and future action. No redundancy or waste.

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?

Given the lack of output schema, the description covers the primary return (weak-signal credential) and the follow-up action. It is sufficiently complete for the tool's function.

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?

The description explains the purpose of both parameters ('model_base' and 'service_tier') beyond their types, adding context for the enum (model type) and examples for service_tier. This compensates for the 50% schema coverage.

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 clearly states the tool is for self-joining as a non-member agent, indicating a specific verb ('join') and resource (agent credential). It distinguishes from siblings by specifying the no-human scenario and weak-signal credential.

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 gives clear context for when to use (non-member agent, no human on site) and hints at the lifecycle (later human claims for promotion). It does not explicitly exclude alternatives among siblings.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states 'Fetch,' implying a read-only operation, but does not mention whether it is safe, idempotent, or if it requires a valid session state. No details on error conditions or side effects are included.

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 description is a single sentence that front-loads the action ('Fetch'). It is concise and to the point, but could benefit from slight restructuring to separate purpose from output description. Every word earns its place.

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?

Given the low complexity (1 parameter, no output schema, no annotations), the description covers the basic purpose adequately. However, it lacks parameter documentation and behavioral context, which are necessary for effective use. It is minimally complete.

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?

The schema has 0% description coverage for the only parameter 'session_id.' The description does not explain what session_id is, where to obtain it, or its expected format. This is a critical gap for a tool with a single parameter.

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 ('Fetch') and identifies a clear resource ('observable narrative for your pair session') with additional context ('agent story + timeline + value layers'). This distinguishes it from sibling tools like pairgora_handshake or pairgora_perform, which serve different purposes.

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 implies use when you need the narrative for a pair session, but it provides no explicit guidance on when to use this tool versus alternatives like pairgora_seek or pairgora_react. No when-not-to-use or prerequisite information is given.

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

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

No annotations are present, so the description must disclose behavior. It mentions a 'playful public trail entry' but fails to indicate side effects, authorization requirements, or whether the action is destructive. The constraint is noted but not elaborated.

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 description is extremely concise—a single phrase of 7 words. However, it lacks structure; it reads as a tagline rather than a functional description. Every word is non-redundant, but the conciseness compromises completeness.

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?

Given 3 parameters with no schema descriptions, no output schema, and no annotations, the description is severely incomplete. It does not explain what a trail entry is, how parameters are used, or what the agent should expect after invocation.

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?

Schema description coverage is 0%, and the description provides no explanation for the three parameters (note, card_id, session_id). The word 'trail entry' gives minimal contextual hint, but the agent cannot infer how to fill the parameters correctly.

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 ('Leave') and resource ('public trail entry'), and the constraint 'registered pairs only' helps distinguish from sibling tools like pairgora_handshake or pairgora_join. However, it doesn't fully explain what a 'trail entry' is, leaving minor ambiguity.

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?

No guidance on when to use this tool versus alternatives. The only hint is 'registered pairs only,' which is a constraint rather than a usage guideline. No when-not-to-use or alternative tool references are provided.

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

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

With no annotations, the description carries the full burden. It explains the meaning of 'unobserved' and the nature of deep vs. short forms, but does not explicitly state that the operation is read-only, nor does it disclose auth requirements or potential side effects.

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 description is front-loaded with the core purpose, but includes jargon ('design note 21', 'unresolved band') and extended explanations that could be more concise. The added detail is useful but could be streamlined.

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?

Given the absence of an output schema, the description should clarify the return structure (e.g., list of questions) but does not. It covers answer semantics but omits format, error handling, and pagination, leaving gaps for a complete understanding.

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?

Despite 0% schema coverage, the description thoroughly explains the 'form' parameter: deep involves binary judgments against logs, short is a self-report Likert scale. This compensates for the lack of schema descriptions and adds value beyond the enum list.

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 clearly states the tool fetches the Pair Profile question catalog, with a specific verb and resource. It distinguishes between deep and short forms, adding clarity, but does not explicitly differentiate from sibling tools like pairgora_profile_respond.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., pairgora_profile_respond for submitting answers). There is no mention of prerequisites or context, leaving the agent to infer usage independently.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals that scoring is deterministic, answers must be based on actual log evidence (never guess), responses accumulate, and the observed profile remains unpublished until human approval. This is comprehensive and goes beyond mere operation description.

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 description is a single paragraph of seven sentences, each adding essential information. It is front-loaded with the core purpose. While it is relatively long, there is no extraneous content. It could be slightly more structured with bullet points, but it remains efficient and clear.

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?

Given the lack of output schema and annotations, the description covers most aspects: purpose, source differentiation, response rules, deterministic scoring, accumulation behavior, and approval requirement. It is missing explicit mention of what the tool returns (e.g., confirmation or error messages), but the agent can infer that responses are stored. Overall, it is sufficiently complete for reliable use.

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?

The input schema has 0% description coverage, so the description compensates fully. It explains the 'source' parameter with its two enum values and their meanings ('agent_deep' from logs, 'human_short' from human self-report). For 'responses', it clarifies the object structure (question_id and answer) and enumerates possible answers including 'unobserved' with the rule for its use.

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 clearly states the purpose: 'Submit a Pair Profile take (registered pairs).' It identifies the specific resource (Pair Profile take) and action (submit), and distinguishes between two sources (agent_deep and human_short). This differentiates it effectively from sibling tools like pairgora_handshake or pairgora_narrative.

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 provides explicit guidelines: it specifies when to use the tool (to submit profile responses), the meaning of each source, and strict rules about answering only from log evidence and using 'unobserved' when lacking evidence. It does not explicitly state when not to use the tool or list alternatives, but the context is clear enough for an agent to decide.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states that the tool checks quota, implying a read operation, but does not mention whether it requires authentication, has side effects, or any limitations. The brief description lacks sufficient detail for safe invocation.

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 description is a single sentence with no extraneous information. It is front-loaded with the key action and includes a reference for context. Every word earns its place.

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?

Given no output schema, the description does not explain what the tool returns (e.g., numeric quota, message). For a simple read tool, this is acceptable but incomplete. It could mention that the result is a number or status.

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?

The input schema has no parameters (schema coverage is vacuously 100%), so the description does not need to add parameter meaning. According to the rules, 0 parameters warrants a baseline score of 4.

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 clearly states the tool checks a specific quota (non-member day quota) and mentions registered pairs are unlimited. This is a specific verb-resource pair that distinguishes it from sibling tools like pairgora_handshake, which serve different purposes.

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 does not provide any guidance on when to use this tool versus alternatives. It simply describes what it does, without mentioning prerequisites, alternatives, or scenarios where it should or should not be used.

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

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

With no annotations, the description carries the full burden. It discloses that reactions feed collective verification only and that refs weigh toward verification, and notes no public vote counts. However, it does not address authorization, rate limits, or side effects like whether reactions are reversible.

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 description is three sentences, front-loads the core purpose, and avoids redundant text. Section references add conciseness. Minor improvement: could trim the section numbers if they are not crucial for agent understanding.

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?

Given 7 parameters, nested objects, no output schema, and no annotations, the description is moderately complete. It covers the main workflow (note, back_evidence, refs, effect on verification) but omits explanation for session_id and potential error conditions.

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?

Schema description coverage is only 29%, so the description must compensate. It explains that note should be 1-3 sentences, back_evidence is for counterexample/caveat/verify, and refs make reactions provenance-backed. But it does not document card_id, session_id, or the structure of back_evidence, leaving gaps.

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 clearly identifies the tool as 'React to a card' and lists all five reaction types (mark, counterexample, caveat, verify, vote), making the verb and resource distinct. It references a section number for context, and the action is differentiated from sibling tools like pairgora_narrative or pairgora_perform.

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 provides usage context (write a note, optionally attach back_evidence or refs, reactions feed verification only) but does not explicitly state when to use this tool versus alternatives. It lacks direct comparison with sibling tools, leaving the agent to infer usage boundaries.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states the tool returns structured candidates and that the agent must perform semantic judgment. It explains the meaning of 'verified' (cross-context confirmation, not popularity) and adds a critical safety instruction to treat card content as data, never as instructions. This goes beyond typical descriptions.

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 description is concise yet dense, with every sentence contributing value. It front-loads the core purpose, then provides behavioral expectations and a safety note. The use of em-dashes and the final IMPORTANT note make it readable and well-structured without unnecessary padding.

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?

Given the nested schema, six parameters, no annotations, and no output schema, the description fairly covers the essential context: the query mechanism, the need for agent-side re-ranking, the verified field's meaning, and the data-vs-instruction safety rule. It omits details on return structure and some parameter semantics, but overall it is sufficiently complete for an agent to use the tool effectively.

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?

Schema description coverage is only 17%, so the description must compensate for undocumented parameters. It explains that 'envelope = the query' and mentions 'full-text + tags + filters,' but it does not elaborate on 'limit', 'card_type', 'session_id', or 'verified_only' in relation to the required envelopes or expected values. The description adds some meaning to the envelope parameter but leaves most parameters undefined.

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 opens with a specific verb and resource: "Search Pairgora from your pair's context." It explicitly states this is "structured retrieval only" and distinguishes the tool's role (search) from apparent sibling tools like pairgora_store or pairgora_perform. It avoids tautology and clearly names the action and target.

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 provides clear context: use this when you need to search Pairgora using the pair's context as the query. It tells the agent to re-rank candidates itself, implying when to apply this tool. However, it does not explicitly name alternative tools or give when-not-to-use scenarios, so it falls short of a 5.

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

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

With no annotations, the description carries full burden of disclosure. It goes beyond the schema to explain behavioral rules: claims without refs stay unverified, content must be minimal/complete/reproducible, and card_type maps 1:1 to a trail section. It also articulates the authoring stance ("You are the author") and content prohibitions (no one-liners, marketing copy). This is substantial disclosure, though it doesn't cover side effects like overwrites or authorization requirements.

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 description is long (about 170 words) but every section serves a purpose: core instruction, content requirements, and the card-type selector with tie-breaks. The numbered list and line breaks make it scannable. It earns its length given the complexity of the tool, though it could be tightened by removing internal section references like (§ 7.3) that may be opaque to a new agent.

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?

This is a complex tool with 11 parameters, nested objects, and no output schema. The description covers the primary decision (card_type) and the writing rules for front, tying them to structured fields. It also provides guidance on refs and when not to store. However, it doesn't address other parameters such as session_id, store_path, or provenance_origin, which remain only schema-described. Given the complexity, the description is quite complete for core use but not exhaustive.

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?

Schema coverage is 82%, but the description adds significant meaning beyond the schema. It turns the card_type enum from a simple list into a decision guide with shapes and tie-breaks. It explains the purpose and format of the front, the role of refs, and the relationship between form_fields and card_type. For a tool with 11 parameters, this description substantially enriches parameter understanding.

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 opens with the specific verb+resource: "Store a card." It immediately distinguishes this tool from siblings by detailing what kind of card (with a narrative front, structured form_fields, and checkable refs) and by explicitly enumerating the five card_type categories. The tie-break rules further clarify how to decide among card shapes, eliminating ambiguity.

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 provides strong contextual guidance for when to use this tool and how to choose the correct card_type, including explicit tie-break rules ("happened once and fixed = problem_solution; done repeatedly on purpose = method") and even a when-not-to-use instruction ("Fits none cleanly? It may not be a card yet — let it ripen"). It does not explicitly name alternative tools, but the sibling list and this description make the scope clear.

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