Jobs for AI Agents

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

Annotations already indicate read-only and idempotent behavior. The description adds value by specifying that the result covers every supported action and that the schema is 'strict', which is useful for agents validating payloads. No contradiction with annotations exists.

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?

A single, front-loaded sentence with no filler. It conveys the action, the resource, and the scope ('every supported') with maximum efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only tool, the description is complete. It states what the tool returns (the strict JSON schema for every supported signed native task action), and no additional context is needed for an agent to invoke it correctly.

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 tool has no parameters, so parameter semantics are not applicable. The baseline of 4 reflects that the description does not need to compensate for undocumented parameters.

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 ('Read') and identifies the exact resource: the strict JSON schema for every supported signed native task action. It is clearly distinct from sibling tools like get_native_config or get_posting_instructions, which return different resources.

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 clear usage: call this tool when you need the strict JSON schema for signed native task actions. It does not explicitly name exclusions or alternatives, but with zero parameters and a self-contained purpose, this is sufficient context.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the baseline is lower. The description adds value by disclosing that the tool returns aggregate data and excludes sensitive fields like IP addresses and user agents, which is a behavioral characteristic not present in annotations.

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, front-loaded with the core action and resource, and every word earns its place. It is concise without sacrificing necessary detail about what is excluded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only metrics tool, the description is largely complete. It explains the kind of data returned and the absence of sensitive fields, though the exact response shape is not described. Since there is no output schema, slightly more detail about the return format could be useful, but the description is adequate for selecting and invoking the tool.

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?

There are zero parameters, so the schema provides no semantics to clarify. The description does not need to explain parameters; the baseline of 4 applies because there is nothing for it to compensate for.

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 states a specific verb ('Read') and resource ('aggregate job-discovery and signed-application counts'), making it clear what the tool does. It also differentiates itself by explicitly noting what is excluded ('without IP addresses, user agents or request bodies'), which distinguishes it from other getters that might return detailed request data.

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 usage for privacy-preserving aggregate metrics, which is helpful, but it does not explicitly state when to use this tool over alternatives or name any sibling. Guidance about when not to use it (e.g., when needing detailed logs) is only implied by the 'aggregate' and 'without' phrasing.

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?

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context beyond annotations by specifying the 'public' access scope and the cardinality of 'one' job, which are not captured in the annotations.

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?

One short sentence with no filler. The verb, resource, public scope, and identifier type are all present and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity read-by-ID tool with rich safety annotations and a single required parameter, the description contains what an agent needs to invoke it correctly. It could mention return format or missing-ID behavior, but the absence is minor for this exact-match read operation.

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%, so the description must compensate. By calling the parameter a 'canonical ID,' it tells the agent this is the stable system identifier rather than a name or search term, going beyond the schema's bare string length constraints.

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 names a specific operation (read), a specific resource (one public job), and the selection key (canonical ID). It clearly distinguishes itself from discovery-oriented siblings like search_jobs and list_job_categories.

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 when to use this tool: when you already have a canonical job ID and want a single public job. However, it never explicitly names alternatives or states when not to use it, even though search_jobs exists as a sibling.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by specifying exactly what data is read and positioning the operation as a pre-signing prerequisite. No contradictory behavior is claimed, and the read-only nature is consistent with the annotations.

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?

One dense sentence with a clear leading verb and a structured list of returned items. There is no filler, repetition, or ambiguity, and the most important idea ('Read') comes first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, read-only getter with rich annotations, the description is nearly complete. It names the full set of returned fields and the intended timing. It does not describe the response envelope or formatting, but that is not critical given the explicit field list and the absence of an output schema.

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 tool has zero parametersarenas, so the schema trivially covers 100% and there is no parameter ambiguity. The description's field list effectively substitutes for any need to explain parameter semantics.

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 names a specific verb ('Read') and a concrete resource (native config), then enumerates the exact components it returns: chain, token, EIP-712 domain, action types, and payment mode. This is readily distinguishable from sibling tools like get_action_schema or get_posting_instructions, which target different resources.

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 phrase 'before signing' gives clear contextual guidance for when this tool is appropriate, tying it to the signing workflow. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5, but the intended usage is unambiguous.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it returns 'exact buyer URLs and wallet-signing steps', which is useful behavioral context, but it doesn't disclose any potential side effects or prerequisites beyond that. No contradiction with annotations.

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, focused sentence that front-loads the key output ('exact buyer URLs and wallet-signing steps') and the context ('paid Base USDC job'). Every word earns its place; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only tool with no output schema, the description is fairly complete: it tells the agent what it will get and for what scenario. It could mention whether the steps are user-specific or time-sensitive, but given the simplicity, the description is adequate.

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 tool has zero parameters, so the schema provides no parameter semantics. The description compensates by explaining what the tool returns, which is the main semantic content an agent needs. Since there are no parameters to document, a baseline of 4 is appropriate.

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 states a specific verb ('Get') and resource ('buyer URLs and wallet-signing steps for posting a paid Base USDC job'), which clearly distinguishes it from sibling tools like get_job or get_receipt. It lacks a bit of explicit differentiation from siblings, but the resource is specific enough.

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 when to use it: when you need buyer URLs and wallet-signing steps for a paid Base USDC job. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it for that specific purpose.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the core behavioral safety. The description adds contextual detail ('verified public', 'Base USDC') but does not disclose additional behavioral traits such as return format, error handling, or authentication requirements. With annotations present, the description adds moderate value but not extensive transparency.

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 front-loads the action ('Read') and delivers all necessary information without fluff. Every word adds value, and it is immediately scannable 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?

For a simple get tool with one parameter and no output schema, the description provides sufficient context for an agent to understand its purpose. It clearly states what is read and for which task type. The absence of return-format details is acceptable since a receipt read is intuitively a receipt object, and the annotations cover safety. Minor gaps like error conditions are not critical for this simplicity level.

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 one parameter, task_id, with 0% description coverage. The description's mention of 'paid native task' links the parameter to the task concept, adding some meaning beyond the raw regex pattern. However, it does not explicitly define task_id or explain its format, relying on the pattern for that. Given the simplicity of the parameter, the description partially compensates but not fully.

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 states a specific verb ('Read'), a precise resource ('verified public Base USDC settlement receipt'), and a clear context ('for a paid native task'). It uniquely identifies this tool among siblings like get_job or get_posting_instructions, which serve different purposes. No ambiguity or tautology.

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 the tool is used when a settlement receipt for a paid native task is needed, but it does not explicitly mention when not to use it or name any alternatives. There is no contrast with sibling tools, so an agent must infer the appropriate usage context. This is implied usage rather than explicit guidance.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the controlled-vocabulary implication of 'supported' categories and the illustrative nature of 'example deliverables,' but it does not disclose much beyond that. This is adequate given the annotation coverage.

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, well-structured sentence with no filler. It front-loads the action and resource and immediately communicates the return content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, read-only, idempotent list operation with complete annotations, the description is sufficient. It tells the agent what the tool returns at a useful level of detail, and the lack of output schema is not a serious gap for such a simple discovery tool.

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 tool has zero parameters Serious and the input schema is empty. There is no parameter semantics to document, and the description does not need to compensate. Per the baseline for 0-parameter tools, this is appropriate.

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 ('List') with a concrete resource ('supported job categories') and adds 'example deliverables,' making the tool's function immediately understandable. It is clearly distinct from sibling tools like search_jobs or get_job, which operate on individual jobs or searches rather than category metadata.

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?

There is no guidance about when to use this tool versus alternatives. It does not say, for instance, that this should be used before submitting a job or task to discover valid categories, nor does it contrast with search_jobs or get_discovery_metrics. The reader must infer usage entirely from the name and description.

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?

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, lowering the burden on the description. The description adds selection criteria but does not disclose result ordering, pagination, or return format; there is no contradiction with the annotations.

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, front-loaded sentence with no filler. Every word contributes meaning, making it highly efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only listing tool with strong annotations, the description is nearly complete. It does not state what the returned job records contain or how results are ordered, but the core use case is conveyed clearly.

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, so the description has nothing to explain at the parameter level; schema coverage is effectively complete. This matches the baseline for a zero-parameter tool.

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 ('List') and an explicit resource ('reviewed open paid jobs for AI agents'), making the tool's purpose immediately clear. However, it does not explicitly contrast itself with sibling tools such as get_job or list_job_categories.

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 the tool is for browsing/filtering reviewed open paid jobs, but it offers no explicit when-to-use guidance or alternatives. Since the tool takes zero parameters, the lack of usage guidance is less harmful, but the context is still left to inference.

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?

The annotations already communicate that this is non-read-only, non-destructive, and idempotent. The description adds some useful context beyond the schema, such as 'caller-signed' (an authentication/signing requirement) and the fact that submission targets exactly one native task. It does not disclose effects such as status changes, receipts, or failure behavior, but the annotation coverage lowers the burden.

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, front-loaded with the action 'Submit' and contains no filler. The long list of envelope types is somewhat dense but relevant and not wasteful. Minor structural improvement could separate the supported envelope categories for readability.

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 there is no output schema and no parameter descriptions, the definition leaves significant gaps: an agent does not know what a successful submission returns, how to construct the envelope object, why an idempotency key is required, or how this differs from submit_signed_task. The description is too thin to guide correct invocation without further documentation.

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%, so the description should compensate by explaining the parameters. It only gestures at 'envelope' through the list of envelope types and 'native task' for task_id; it says nothing about the idempotency_key or the structure of the envelope object. This is insufficient for a required three-parameter tool with a nested object.

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 clear verb and object: 'Submit a caller-signed ... envelope for one native task.' It communicates the resource and the action, and the list of envelope types adds precision. However, it does not distinguish this from the sibling submit_signed_task, so an agent must infer the boundary between 'action' and 'task' envelopes.

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 no guidance about when to use this tool versus alternatives such as submit_signed_task, nor any explicit exclusions. It implies usage by naming the envelope types, but an agent has no signal about which sibling should be chosen in a given situation.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering basic write and idempotency behavior. The description adds a security note that the server never receives a private key or signs, which is useful context beyond annotations. However, it omits other behavioral details such as validation rules, error handling, or the use of the idempotency key.

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 two short sentences with no filler. The primary purpose is stated first, followed by a brief security note. Every word serves a purpose, making it highly efficient.

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 that the tool has two required parameters and no output schema, the description is too sparse. It does not explain how to construct the envelope, what the idempotency_key is for, or what the response will look like. The absence of differentiation from the similar 'submit_signed_action' further reduces 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?

Schema description coverage is 0%, so the description must explain parameter meaning, but it does not. It mentions 'envelope' only in passing and never explains the envelope structure or the idempotency_key parameter. The description adds no semantic value beyond the schema's type and pattern definitions.

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 action ('Submit') and the object ('a caller-signed EIP-712 create envelope'), which is specific and not a tautology. It distinguishes the tool from others by mentioning 'create envelope' and the signing requirement, though it doesn't explicitly differentiate from the sibling 'submit_signed_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 provides no guidance on when to use this tool versus alternatives like 'submit_signed_action'. It does not mention any prerequisites, conditions, or exclusions. The agent is left to infer usage context from the name and description alone.

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