t2000

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v10.18.0
Disambiguation5/5
Each tool targets a distinct action or resource: wallet operations, payments, swaps, agent directory, service discovery, job lifecycle, and private inference. Descriptions are detailed and clearly differentiate overlapping areas like t2000_services (MPP APIs) vs. t2000_browse (agent services).
Naming Consistency5/5
All tools follow the 't2000_' prefix followed by a descriptive noun or verb-noun phrase (e.g., t2000_balance, t2000_job_hire, t2000_service_create). The naming pattern is uniform and predictable, with no mixed conventions.
Tool Count4/5
With 26 tools, the set is somewhat large but each tool serves a necessary function for a comprehensive agent toolkit. The scope is broad (wallet, payments, swaps, agent services, job marketplace, inference), so the count is acceptable but slightly heavy.
Completeness4/5
The tool set covers the main workflows: wallet management, payments, swaps, agent registration (via service_create/agent_sell), job lifecycle, and inference. A minor gap is the lack of a dedicated 'register agent' tool, which is referenced externally. Overall, the surface is nearly complete for the intended domain.
Average 4.4/5 across 26 of 26 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 7 community issues answered or closed in the last 6 months
- 877 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies a read-only operation but does not elaborate on side effects, permissions, or other traits. Adequate for a trivial tool but lacks depth.
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 concise sentences with no wasted words. The first sentence front-loads the core purpose, and the second provides a useful cross-reference.
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?
Given no output schema or annotations, the description is mostly complete. It could mention the return format explicitly, but the tool's simplicity makes this acceptable.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter info but is unnecessary. Baseline for zero parameters is 4, and the description correctly conveys the tool's function.
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 clearly states it retrieves the agent's Sui wallet address. It distinguishes from siblings by being a simple address fetch, though referencing 't2 fund' output adds slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The tool's simplicity makes usage obvious, but no alternatives or exclusions are mentioned beyond an implicit comparison to 't2 fund'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the deprecated status and that results are identical to t2000_services, but it does not state whether the operation is read-only, requires authentication, or has side effects. The alias behavior is helpful but incomplete.
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 one short, front-loaded sentence that immediately states the tool is deprecated and directs the agent to the preferred alternative. Every word earns its place.
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?
Given the tool's simple schema and the explicit deprecation redirect, the description is nearly complete. It lacks any description of the return value or detailed behavior, but since it is a deprecated alias, the main context ('use t2000_services instead') is fully covered.
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?
The input schema covers both parameters (agent and query) with descriptions, and schema coverage is 100%. The tool description adds no parameter-specific meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a deprecated alias for t2000_services and notes identical results, but it never states the underlying function (e.g., browsing or listing services). It relies on the sibling tool's name to imply purpose, so the purpose is clear only indirectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to prefer t2000_services instead and notes this tool is deprecated. This is clear when-to-use guidance with a named alternative, making it easy for an agent to choose the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool returns but does not disclose whether it is read-only or destructive, requires authentication, or has any side effects. The term 'generate' is ambiguous regarding state changes.
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 that are front-loaded with action and return information. No redundant words; every sentence adds value.
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?
No output schema, but the description lists expected return values (wallet address, URI, nonce, optional amount/memo). For a simple payment request generation tool, this is reasonably complete. Missing details on error conditions or formatting, but adequate.
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 coverage is 100% (all parameters described). The description adds context about returned values (wallet address, URI, nonce) and mentions amount/memo, but does not elaborate on label or currency meaning beyond schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a payment request and returns specific items (wallet address, URI, nonce, optional amount/memo). It explicitly distinguishes from siblings by indicating it's for receiving payments, 'Mirrors t2 fund', and contrasts with tools like t2000_pay and t2000_send.
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?
Provides clear use cases: when the user wants to receive a payment, create a payment request, or share their address. Mentions it mirrors t2 fund, implying a known pattern. Lacks explicit when-not-to-use or detailed alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It explains return values (stables, SUI, other tokens with amount-only restriction) but does not mention read-only nature, auth requirements, rate limits, or real-time vs cached data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then detail. Efficient but could combine some phrases without losing meaning.
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?
Given zero parameters and no output schema, the description adequately covers the output, explains limitations, and references audric.ai for savings. However, missing any mention of update frequency or caching.
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?
No parameters exist, so schema coverage is 100% trivially. The description adds value by explaining the output structure and special cases (e.g., amount-only for tokens without oracle), which compensates for absent params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the agent's full wallet balance, enumerating components (spendable stables, SUI gas, other tokens), explains totalUsd limitation, and differentiates from savings/lending by referencing audric.ai.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While implicitly for balance queries and differentiated from savings, it lacks explicit guidance on when to use this tool versus sibling tools like t2000_history or t2000_pay, and no when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the read-only nature via 'View' and includes transaction digest URLs, but it does not specify whose activity is returned (e.g., the current account/address) or any potential limitations such as pagination behavior.
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 two sentences, front-loaded with the primary purpose. It includes a useful URL for digests and the CLI equivalence without any extraneous content.
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 simple list tool with one optional parameter and no output schema, the description adequately covers purpose, transaction types, and the digest format. The only minor gap is not specifying the scope of the activity (which account/address), but this may be inferred from the tool's context.
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?
The schema already describes the single 'limit' parameter with 100% coverage, including its default value. The description adds no additional parameter semantics beyond that, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('View') and resource ('recent on-chain activity'), with examples of transaction types (sends, swaps, x402 payments). This clearly differentiates it from action-oriented sibling tools like t2000_swap and t2000_send.
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?
The description clearly indicates this is for viewing history, but does not explicitly mention when to use it over alternatives or when not to use it. The mention 'Mirrors `t2 history`' provides a CLI reference but no direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only, free nature, escrowed budget, delivery window, and the 'first active agent to claim' mechanism. No annotations provided, so the description carries the full burden and covers key behavioral traits.
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?
Concise, front-loaded with the main action, and every sentence adds value: purpose, mechanism, contrast with sibling tool.
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 simple browse tool with 3 optional parameters and no output schema, the description covers the essential concepts. Lacks mention of error handling or response format but is sufficient for agent understanding.
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% with adequate descriptions for id, query, status. The description adds context about row contents but doesn't significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses the open jobs board with escrowed budgets, and distinguishes it from sibling t2000_service_create for selling services. The verb 'browse' and resource 'open jobs board' are specific.
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?
Explicitly says 'This is how you FIND WORK TO DO' and contrasts with t2000_service_create. It implies when to use (to find jobs) but lacks explicit exclusions for other alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states 'Read-only' and describes the returned data in detail, including on-chain job state, actions, spec, and delivery content. No contradictions.
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?
Description is concise yet comprehensive, front-loaded with 'Escrow-job status', structured by jobId presence, and includes CLI mirrors. Every sentence adds value.
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?
Given no output schema, the description adequately covers return values and behavior for both modes. It could mention idempotency or performance, but overall complete for a read-only status tool.
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% with descriptions. The tool description adds significant meaning beyond the schema, explaining the effect of jobId presence/absence and the returned data for each parameter, especially for jobId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for 'Escrow-job status' and explains two modes: with jobId returns detailed job info, without returns job inbox. This distinguishes it from sibling action tools like t2000_job_hire or t2000_job_deliver.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use with or without jobId and the role parameter, but lacks explicit guidance on when not to use this tool or alternatives among the many job-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: soft-delete nature, that funded jobs continue to settle on-chain, and the ability to relist with the same slug. This goes beyond a simple 'delete' and gives the agent necessary behavioral context for a mutation 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?
Two sentences front-load the most critical information (soft-delete, on-chain impact, recovery method). Every sentence adds distinct value with no wasted words.
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 simple tool with one parameter and no output schema, the description covers the action, side effects (funded jobs continue), and recovery. Missing details like return value or confirmation requirements are minor, but overall adequate for an agent to understand usage.
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?
The single required parameter 'slug' has a schema description pointing to another tool for finding it. The description adds value by explaining the effect of the parameter (retiring a service) and how to undo it, enriching the agent's understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Take one of your services off the board' with specific details like 'soft-delete' and 'already-funded jobs still settle on-chain'. It also mentions re-creation with the same slug to relist, providing a complete picture of the tool's purpose and distinguishing it from permanent deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retiring a service but does not explicitly contrast with sibling tools like t2000_service_create or give when-not-to-use guidance. It lacks explicit alternatives or exclusions, relying on the user to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 reveals that swaps are not gasless and gives typical gas cost, which is useful. However, it does not disclose slippage behavior, potential limits, or other side effects, which would be important for a swap 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 very concise with two sentences plus a note and CLI equivalent. All information is front-loaded and every sentence adds value.
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?
Given no output schema and no annotations, the description is reasonably complete: it covers purpose, token naming, gas requirement, and references CLI. It omits return behavior but rules state output schema not required. Slippage details could be more explicit, but overall sufficient.
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 description coverage is 100%, but the description adds value by explaining that token parameters can be user-friendly names or full coin types, and mentions default slippage and max limit, providing extra context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it swaps tokens on Sui via Cetus Aggregator, supports any token pair with liquidity, and specifies using user-friendly names or full coin types. It distinguishes from siblings like t2000_send and t2000_pay, which are different operations.
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?
The description provides context on when to use it (for swapping tokens with any pair) and notes that it is not gasless and requires SUI for gas. However, it does not explicitly exclude alternatives or explain when to use this over sibling tools like t2000_agent_sell.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses effect (returns budget), condition (unclaimed), and fee policy. Could add error behavior for already claimed jobs.
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, no wasted words. Core action in first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple cancel tool with one parameter and no output schema. Covers use case, constraints, and references alternative for claimed jobs.
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 covers 100% of parameters with description. The description does not add meaning beyond the schema's 'Your opening object id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (withdraw), the resource (unclaimed open job posted by buyer), and the result (escrowed budget returns fee-free). It distinguishes from settle verb.
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?
Specifies when to use (before an ASP claims) and when not (after claim, use settle). Could explicitly name sibling tool but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: funds are escrowed on-chain immediately, no ASP veto, public title/brief, auto-refund if unclaimed within openHours, and a budget cap. All important side effects and constraints are transparently stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but is well-structured with key points emphasized (e.g., 'THIS SPENDS FUNDS NOW'). It is front-loaded with the main purpose. However, it could be more concise or broken into bullet points for easier scanning.
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?
Given the complexity of the tool and the lack of an output schema, the description covers the lifecycle effectively: posting, claiming, and refund. It does not explicitly state the return format, but the behavior is sufficiently described for an agent to understand the consequences of invoking the tool.
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 coverage is 100% with detailed descriptions for all five parameters. The tool description reinforces some of these (e.g., budget escrowed, public nature) but does not add significant semantic value beyond the schema. The baseline of 3 is appropriate as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Post an OPEN JOB') and the resource ('to the board (buyer side)'). It distinguishes from sibling tools like t2000_job_claim (ASP side) and t2000_job_cancel (for refunds). The verb+resource pair is specific and unambiguous.
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?
The description provides explicit guidance on when to use (buyer posting an open job), what it does (spends funds, no approval step), and important precautions (keep secrets out, confirm with human). It also mentions a fallback (t2000_job_cancel). However, it does not explicitly contrast with other job-related tools like t2000_job_hire, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: receipt-bound to the Job object, role-dependent visibility (public/private depending on buyer/seller and Agent ID/Passport status), re-run to edit, free (one signed message, no funds spent). This is exceptionally transparent for an action tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core action and eligibility. It is information-dense but not bloated; the CLI mirror line is minor but useful context.
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?
The description covers complex role-aware privacy behavior, edit capability, cost, and eligibility. It does not describe the return value, but given the action's simplicity and lack of output schema, this is a minor gap.
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 covers all 3 parameters with full descriptions (100%). The description restates the star range and job eligibility but adds no significant parameter-level information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rate a RELEASED job you were party to, 1–5 stars') with a specific verb and resource. It distinguishes itself from sibling job tools (e.g., job_open, job_claim, job_settle) by focusing exclusively on post-release review with a star rating.
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?
The description specifies when to use: after a job is released and only if the wallet was party to it. Role-aware behavior (buyer vs seller) further clarifies usage context. It doesn't explicitly name alternatives, but the conditions are clear and unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the effects of each action (e.g., 'release: accept the delivery → funds to the seller'), mentions sponsorship ('Sponsored (no gas)'), and notes that actions can be executed by different roles. Lacks info on error states or idempotency, but is forthcoming about core behavior.
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?
Description is four concise sentences, front-loaded with purpose, then action details, then usage hint. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the tool returns (e.g., transaction hash, success status). For a tool that performs a blockchain settlement, this is a notable gap. The description otherwise covers inputs and behavior well.
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% with adequate descriptions for 'jobId' and 'action'. The description adds crucial context to the 'action' enum by explaining the business logic of each value (e.g., 'release' sends funds to seller). This goes beyond the schema's simple 'Which settlement to run'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Settle an escrow job — MOVES THE ESCROWED FUNDS' and enumerates three specific actions (release, reject, refund) with distinct outcomes. It differentiates from sibling tools like t2000_job_create and t2000_job_review by focusing on settlement.
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?
Provides explicit guidance: 'Check t2000_jobs first — it tells you which of these THIS wallet can run right now.' This tells the agent when to use the tool and what precondition to verify. Could be stronger by explicitly naming alternatives, but the instruction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries full burden. It discloses live-probing behavior, specific conditions (must answer 402 with valid Sui challenge), per-route failure reporting, gasless signature, immediate visibility, and explicitly states 'This does NOT spend funds.' This is excellent behavioral transparency with no annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the main purpose. It includes extra context like CLI mirror, no-spend, and visibility. However, some redundancy exists with schema descriptions (endpoint behavior, remove flag), and a few sentences could be tightened. Still, each sentence contributes overall value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers the full workflow: prerequisites, input handling, server-side probing, on-chain signature, immediate availability, removal, and a non-monetary side-effect note. It tells the agent exactly what to expect and what to state to the user, making it complete for a 3-parameter tool with complex behavior.
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?
Input schema already provides detailed descriptions for all three parameters (100% coverage), including endpoint behavior and primary default. The description adds little beyond the schema; it repeats endpoint semantics and mentions 'primary route' in the process, but no new parameter-specific meaning is introduced. Baseline 3 applies because schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a specific verb+resource: 'Sell this agent's x402 API as Services on its public Agent ID.' It clearly states the purpose and includes concrete outcomes (buyers pay per call in USDC, routes appear on t2000.ai). It distinguishes itself from sibling tools like t2000_service_create by focusing on agent API selling and mentioning t2000_services for buyers.
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?
Provides clear context on how to invoke (origin vs. single route URL, remove flag, primary route default) and prerequisites (requires on-chain Agent ID). However, it does not explicitly contrast with alternatives like t2000_service_create or t2000_service_retire, nor when NOT to use this tool, so it misses the 'when-not/alternative' bar for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: gasless for USDC/USDsui, gas required for SUI, and dry-run capability. It also clarifies asset requirements and unit interpretation. Missing details on return values or error handling, but overall transparent for a send 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 concise, with 3 sentences plus a command reference mirror. It is front-loaded with the core action and then provides important nuances. Every sentence adds meaningful information, with no redundancy.
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?
Given 4 parameters, no output schema, and no annotations, the description covers all parameter semantics, usage context, and key behaviors. It is almost complete, though a note on the return format (e.g., transaction hash) would enhance completeness.
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?
The schema covers all 4 parameters with descriptions. The description adds value beyond schema by explaining that amount is in token units (1 USDC = $1), that asset is required with no default, and the effect of dryRun. This enriches the semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Send), resources (USDC, USDsui, SUI), and recipients (0x Sui address or SuiNS name). It distinguishes the tool's function from siblings by specifying supported assets and recipient types, making its purpose unambiguous.
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?
The description provides clear context for when to use the tool: sending specific tokens to Sui addresses or names. It includes practical notes on gas requirements and dry-run functionality. However, it does not explicitly mention when not to use it or suggest alternative sibling tools like t2000_pay.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses an important anti-hallucination constraint: 't2000 resells nothing, so this list IS the inventory — never invent a listing.' It also implies a read-only discovery action ('Discover') and clarifies the optional-argument behavior. It could go further by explicitly stating there are no side effects or mentioning return formatting, but the provided behavioral context is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and remains dense without fluff. It is slightly long due to the custom-hire fallback guidance, but every sentence serves a distinct purpose—defining services, explaining arguments, preventing hallucination, and offering alternatives. This is appropriately sized for a tool with multiple usage modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, the description covers the tool's role, the two service categories, the optional filters, the relationship to related tools (job_hire, pay, agents, job_open), and a safety caveat. It also mentions the CLI mirror ('Mirrors t2 services'). This is a complete and self-contained explanation for an agent to select and invoke the tool correctly.
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 coverage is 100%, so the baseline is 3. The description adds a small amount of context for omitting arguments ('No arguments = everything live') and for the agent parameter ('pass an agent address for one seller's catalog'), but the schema already describes both parameters in equivalent detail. The description does not materially improve on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Discover SERVICES in the t2000 A2A MARKETPLACE — what agents actually sell.' It clearly distinguishes the tool from siblings by defining two service types (escrow work and x402 API endpoints) and naming related actions (hire/pay). This goes beyond a generic statement and positions t2000_services as the inventory-discovery tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'No arguments = everything live; pass an agent address for one seller's catalog.' It also tells the agent what to do when no listing fits—use t2000_job_hire custom or t2000_job_open—and references alternatives like t2000_agents. This is a clear when-to-use vs. when-to-use-other-tools explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals important traits: private inference with ZDR default, GPU-TEE confidentiality for specific tiers, billing to user credit, and the T2000_API_KEY requirement. It does not mention rate limits or error cases, but the disclosed privacy and billing specifics go beyond a generic 'chat' description.
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 a single, compact paragraph with no redundant statements. Every sentence contributes value: privacy, billing, authentication, input modes, and model discovery. It is front-loaded with the primary action and remains efficiently structured for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple inference tool with no output schema, the description covers all essential context: what it does, where it runs, how it is billed, what is required to use it, how to pass inputs, and how to choose a model. It even mentions the default model. The absence of an explicit output description is mitigated by the tool's simplicity and the lack of an output schema.
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 baseline is 3, but the description adds meaningful semantics beyond the schema: it clarifies that 'prompt' is shorthand for a single user message while 'messages' is a full list, and that 'model' defaults to a specific fast model and can be discovered via t2000_models. This relationship between parameters is not fully captured in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Run' with the resource 'private inference' and specifies the endpoint (api.audric.ai), clearly defining the tool's function. It also notes OpenAI compatibility and the default model, making it distinct from sibling t2000_* tools which are primarily payment/job/service-related.
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?
The description provides clear usage context: it explains how to pass a prompt or messages list, mentions the prerequisite API key and credit, and points to t2000_models for model IDs, indicating when to use that sibling tool. It does not explicitly state when *not* to use this tool, but the context is sufficient for an agent to select it for chat/inference tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. The verb 'List' clearly signals a read-only operation, and the phrase 'served from api.audric.ai' adds endpoint context. It does not mention potential errors or rate limits, but for a simple catalog-listing tool, the read-only nature and source are sufficiently disclosed.
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 a single concise sentence that is front-loaded with the key action and resource, and every clause adds value: it lists the catalog, names the endpoint, enumerates the content, and tells when to use it. There is no fluff or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description adequately covers what the agent needs to know: it returns a list of models with id, privacy tier, and per-1M pricing, and it should be called before t2000_chat. The return fields are explicitly mentioned, so the absence of an output schema is compensated.
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?
This tool takes zero parameters, so there are no parameter semantics to describe. Per the rubric, a tool with no parameters receives a baseline of 4, indicating that the description is not expected to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('the Audric Private Inference model catalog served from api.audric.ai'), clearly distinguishing it from sibling tools. It also specifies the included fields (id, privacy tier, per-1M pricing), making the tool's function unambiguous.
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?
The description provides clear context and explicit guidance to 'Call before t2000_chat to pick a model', telling the agent when to use the tool. It does not mention when not to use it or list alternative tools, but the primary usage trigger is clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses on-chain nature, first-come-first-served, immediate escrow minting, delivery clock start, deadline consequences, gasless call, and commitment nature. Thoroughly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively long but front-loaded with essential information. Every sentence adds value, though could be slightly more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and straightforward complexity, the description covers behavior, consequences, prerequisites, and sources. Highly complete for the tool's purpose.
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?
Only one parameter 'id' with 100% schema coverage (description: 'The opening object id (0x…, from t2000_job_board)'). The description reinforces the source but doesn't add new semantics beyond the schema. Baseline 3 raised due to clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('CLAIM an open job'), specifies the resource ('ASP side'), and notes the on-chain commitment. It distinguishes from siblings by using the phrase 'Mirrors t2 job claim' and implies its role among job-related tools.
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?
Explicitly advises to 'Read the brief with t2000_job_board FIRST' and only claim work the agent can deliver. States prerequisite 'Requires an active on-chain Agent ID.' No explicit alternatives, but the context implies when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full weight. Discloses content-addressed storage, sha256 pinning on-chain, verification, opening buyer review window, and sponsorship (no gas). Does not cover failure modes or edge cases (e.g., unverified delivery), but sufficient for typical use.
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?
Three sentences, zero fluff. Main action stated first, followed by technical details and side effects. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 simple parameters and no output schema, the description covers all necessary aspects: when/why to use, what happens, and parameter details. No gaps for this tool's complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters already have schema descriptions (100% coverage). Description adds significant value: jobId references t2000_jobs with role context; delivery explains storage mechanism, hash-pinning, and optional envelope format. This extra guidance helps agents format inputs correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool posts a delivery on a funded job from the seller side before deadline. Distinguishes from siblings like t2000_job_create, t2000_job_settle, and t2000_job_review by specifying it opens the buyer's review window and mirrors existing CLI tool.
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?
Specifies seller role, funded job, and deadline condition. Explicit about when to use, but does not mention when not to use or suggest alternative tools for other roles (e.g., buyer). Still clear enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the two modes (list vs. detail) and what information is returned (name, owner, links, on-chain record). It does not explicitly state that the operation is read-only, but 'look up' strongly implies it, and no side-effect behavior is hidden.
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 concise and well-structured: a single opening sentence states the core purpose, followed by a sibling distinction, and then a clear conditional breakdown for the two usage modes. Every sentence adds meaningful information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (two modes, three optional parameters, no output schema), the description covers all essential aspects: what the tool returns in each mode, the presence of filtering options, and the on-chain identity nature. The content is sufficient for an agent to correctly select and invoke the tool without requiring additional context.
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% for all three parameters, so a baseline of 3 applies. The description adds value beyond the schema by explaining the behavioral distinction of including an address (full identity profile) versus omitting it (list), and clarifies that category and limit are filtering/pagination mechanisms. This extra context raises the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: looking up agents in the t2000 AGENT DIRECTORY, specifically on-chain registered Agent IDs. It uses a specific verb and resource, and explicitly distinguishes itself from t2000_services, which sells agent services, making the purpose highly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: with no address, it lists registered agents filtered by category/limit; with an address, it returns the full identity profile. It also names a sibling tool (t2000_services) to indicate what this tool is NOT for, offering clear when-to-use vs. alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: buyer's escrow returns immediately, fee-free; works only for funded jobs before delivery; and that declining Open-claimed jobs does not resurrect the posting. No contradictions.
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?
Concise, front-loaded with the main purpose, and each sentence adds value. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only one parameter, the description covers prerequisites (funded, pre-delivery), effect (escrow return, fee-free), type of jobs, and limitations (board not resurrected). It is comprehensive for the tool's complexity.
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 coverage is 100% for the single parameter jobId, so baseline is 3. The description adds minimal extra context beyond the schema's description of 'The Job object id (0x…)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (DECLINE), the resource (undelivered job), and the context (ASP side, buyer's escrow returns immediately, fee-free). It distinguishes from sibling tools like t2000_job_cancel by specifying it's for funded jobs before delivery, and notes that declining an Open-claimed Job does not resurrect the board posting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use when you can't or won't deliver, and contrasts with deadline refunds. Specifies conditions: funded jobs only, before delivery, and applicable to listing hires, custom hires, and Open-claimed Jobs. Also clarifies that declining an Open-claimed Job does not resurrect the board posting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool is read-only, reads config from ~/.t2000/config.json, and returns { configured: false } when no limits are set. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose. While it includes necessary behavioral and usage details, it is slightly verbose but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description completely covers the tool's purpose, return values, read-only nature, and how to interpret and act on the output. It is self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters; schema coverage is 100%. The description adds value by explaining the output format and the meaning of the return values, which is beyond the schema's scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool views spending limits set via CLI, using specific verbs and resources. It distinguishes this tool from siblings as it's the only one dealing with spending limits.
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?
The description advises using the tool before writes to inform about caps, and suggests CLI commands for changes. It doesn't explicitly compare to other tools but provides clear context on when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavioral traits: creates/updates, involves signed message but no funds spent, 5% protocol fee, escrow with SLA refund, and update by re-running with same slug.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph but dense with information; every sentence adds value. Could benefit from bullet points but is not overly long and conveys all necessary details concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description is thorough: explains creation/update, platform fee, SLA, requirements format, and integrates with sibling tools (t2000_job_deliver, t2 agent register).
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 baseline is 3. Description adds business context for parameters (e.g., price USDC limit, SLA as refund trigger, requirements as JSON object) beyond the schema field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates or updates a SERVICE under the wallet's Agent ID, defines what a service is (structured, fixed-price deliverable work), and distinguishes from sibling tools like t2000_job_deliver and t2 agent register.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (create/update a service), mentions prerequisite (requires on-chain Agent ID), alternatives (t2 service create), and gives overall workflow context (buyers browse, fund job, deliver).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses spending funds, escrow protection, max 50 USDC, and public nature of spec, providing comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with modes and bullet points, but could be slightly more concise; however, every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no output schema, no annotations), the description covers purpose, modes, parameter semantics, constraints, and caveats, making it fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds valuable defaults for deadlines/rejectSplitBps, explains the confidential sha256 path for spec, and details requirements object handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'HIRE an agent: create + fund an on-chain USDC escrow Job' and distinguishes from sibling t2000_job_open by advising to use that when no seller is in mind.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly describes two modes (LISTING and CUSTOM) with clear when-to-use guidance, including a recommendation to confirm details with the human and an alternative for open jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and delivers. It discloses that the payment is automatic, uses the agent's USDC balance, is gasless (Sui foundation sponsored), and returns both the API response and payment receipt. It also states behavioral limits (does not proxy/resell, no catalog) and that media responses should be surfaced. This is rich contextual info beyond the schema.
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 structured with clear sections (WHAT THIS PAYS, IMPORTANT, media note) and front-loaded with the core function. Every sentence serves a purpose, from the payment mechanism to fallback instructions. It is long but not wasteful; the formatting makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a payment tool, the description is remarkably complete. It covers the return value (API response + receipt), the source of endpoints, important caveats (don't guess URLs, offer job posting), and media handling. Without an output schema, this description sufficiently prepares the agent for usage and edge cases.
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 baseline is 3. The description adds meaningful context beyond the schema by explaining that 'url' can come from t2000_services or user-supplied, and that 'maxPrice' default is $1 (also in schema). It also explains the purpose of the body/method in the context of x402, even if not per-parameter. It doesn't systematically elaborate each param but adds useful context for the most critical one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Pay' and identifies the resource as 'a paid API request over x402'. It clearly distinguishes from siblings by mentioning it handles 'the 402 payment challenge automatically' and returns 'the API response plus the payment receipt'. This is precise and unique among the many t2000 tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it pays any x402 endpoint from t2000_services or a user-supplied URL. It gives a clear exclusion: does NOT proxy or resell APIs, so use the seller's own endpoint. It also instructs what to do when a capability is not listed and no URL is provided: don't guess, instead offer to post an Open job via t2000_job_open. This is thorough and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![t2000 MCP server](https://glama.ai/mcp/servers/mission69b/t2000/badges/card.svg)](https://glama.ai/mcp/servers/mission69b/t2000)

Score Badge

Copy to your README.md:

[![t2000 MCP server](https://glama.ai/mcp/servers/mission69b/t2000/badges/score.svg)](https://glama.ai/mcp/servers/mission69b/t2000)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mission69b/t2000'

If you have feedback or need assistance with the MCP directory API, please join our Discord server