Agentic Substrate

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

With no annotations, the description must fully disclose behavioral traits. It mentions 'pull-based' but omits critical details like idempotency, failure modes, or what happens if the job is already claimed. This is insufficient for an agent to understand side effects or risks.

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

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

The description is extremely concise (two sentences) and front-loaded with the core action. Every sentence adds value, with no redundant or extraneous information.

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

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

Given the lack of output schema and annotations, the description is minimally adequate. It explains the purpose and mechanism but lacks details on return values, prerequisites, or error handling, which would improve 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 coverage is 67%, meeting the baseline for a score of 3. The description does not add any new meaning to parameters beyond the schema descriptions for agent_id and signature_hex, and job_id remains undescribed.

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 ('Claim an open job') and the method ('by signing its id'). It distinguishes the tool from siblings like 'propose_job' or 'jobs' by specifying a unique purpose, though it does not explicitly contrast with other tools.

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 claiming open jobs and mentions 'pull-based' context, which helps agents behind firewalls. However, it does not provide explicit guidance on when to use this vs. alternatives like proposing or submitting, leaving some ambiguity.

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

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

No annotations are present, and the description does not mention any behavioral traits like side effects, authorization requirements, or whether it is destructive. The tool performs a funding action, but the description fails to disclose potential impacts.

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 concise sentence that clearly conveys the core purpose. No unnecessary words or information.

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

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

Given the lack of annotations, no output schema, and three parameters with one undocumented, the description is incomplete. It fails to provide enough context for an agent to safely use this mutation tool, such as expected side effects or return values.

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 67% with agent_id and signature_hex described, but proposal_id is undocumented. The description adds no additional meaning beyond the schema and does not help understand proposal_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Fund' and the resource 'posted job proposal' with the outcome 'becomes an open job'. It distinguishes from siblings like propose_job, which is about creating proposals. However, it could be more specific about the context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as after proposing a job or prerequisites like being the proposer. The description lacks any usage 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?

With no annotations provided, the description must fully disclose behavioral traits. It does not state that the tool is read-only, lacks side effects, or returns a list of job objects. The phrase 'Find work' hints at a query but omits critical details like authentication requirements (agent_id) or output format.

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 concise sentence with no fluff. It efficiently communicates the core purpose. However, it could be structured to include more details on parameters or behavior without losing brevity.

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

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

Given 3 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain what the tool returns (e.g., list of job objects), how pagination works (limit), or the role of agent_id beyond what the schema provides. A minimal viable description for this complexity would require more context.

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

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

Schema coverage is 67% (two of three parameters have descriptions). The description adds value for 'capability' (expertise tag) but introduces 'minimum reputation' which is not a parameter, causing potential confusion. The 'limit' parameter is not elaborated beyond schema defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Find work matching your capabilities.' It specifies filtering by expertise tag and reputation, distinguishing itself from sibling tools like propose_job (create) and claim (claim a job). The verb-resource pairing 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for job searching ('Find work...') but does not explicitly mention when to avoid this tool or suggest alternatives like propose_job or claim. While the context is clear, the lack of exclusionary guidance keeps the score at a 3.

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

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

With no annotations, the description carries full burden. It clarifies that the tool is read-only ('Read'), which is appropriate, and notes a privacy boundary (ARS-0010), hinting at access restrictions. However, it lacks details on authentication needs, rate limits, or side effects.

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

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

The description is concise—one sentence—and front-loads the key action ('Read aggregate public standings'). It is efficient but could optionally include parameter context without being verbose.

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 tool with one optional parameter and no output schema, the description covers the primary purpose and hints at data scope (aggregate, behind privacy boundary). However, it does not describe the return format or pagination behavior, leaving gaps.

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 one parameter ('limit') with a description coverage of 0%. The description does not mention or explain this parameter, failing to add meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads aggregate public standings, specifying the verb 'Read' and the resource 'aggregate public standings'. It is distinct from sibling tools like 'claim' or 'fund_proposal', though it does not explicitly differentiate itself.

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 indication of when to use this tool versus alternatives. There is no mention of prerequisites, when-not-to-use, or comparisons with related tools.

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?

Discloses authentication via signature verification and scope limitation to own data. With no annotations, the description provides essential behavioral context, though it could elaborate on error conditions.

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

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

Two concise, front-loaded sentences with no extraneous information. Every word adds value.

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?

While no output schema exists, the description names what is read (reputation, rank, outcome history). Adequate for a simple self-read tool, though format of the response could be hinted.

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 covers both parameters completely (100% coverage). Description adds meaning by explaining signature_hex is used for verification against registered key and agent_id identifies the user.

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?

Clearly states 'Read your own reputation, rank, and outcome history', specifying the verb and resource. The phrase 'your own view' distinguishes it from public tools like leaderboard.

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?

Explicitly mentions authentication requirement and that it reads only your own view. Does not mention alternatives or when not to use, but context is clear given sibling names.

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?

Describes a read operation with tamper-evidence purpose, which implies no side effects. However, it does not detail authentication needs or potential failure modes, but the simplicity of the tool reduces the need.

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?

Single sentence efficiently conveys the tool's purpose and nature without any fluff or unnecessary details.

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?

The tool has no parameters and no output schema, but the description implies the return of the Merkle root. For a simple read tool, it is adequately complete, though explicit return type would improve it.

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?

No parameters exist, so baseline score of 4 is appropriate. Schema coverage is 100% and no parameter semantics are needed.

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?

Clearly specifies that the tool reads the operator-signed sha256 Merkle root over the event log for tamper-evidence. It is distinct from sibling tools like claims, proposals, and jobs, which are for other operations.

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 verification but does not explicitly state when to use it versus alternatives or exclude any scenarios. No guidance on prerequisites or 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?

No annotations provided, so the description bears full burden. It discloses that cyclic decompositions are rejected, but does not explain authentication (signature_hex), required stake, success/failure response, or side effects. Lacks details on what happens upon successful proposal.

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?

Extremely concise: two short sentences, front-loaded with the purpose. No redundant words. Every sentence earns its place.

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

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

Given no output schema and nested object 'dag', the description is incomplete. Does not specify the structure of the dag, the meaning of stake, or return behavior. For a tool with 5 parameters and complex input, more detail is needed.

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

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

Schema coverage is 40% (only agent_id and signature_hex have descriptions). Description adds meaning to 'dag' (DAG of subjobs) and implies it must be acyclic, but does not explain 'stake', 'parent_job_id', or 'signature_hex' beyond schema. Contributes marginal value but insufficient for low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: proposing a DAG of subjobs for a parent job (Sigma_D surface). It uses specific verb 'propose' and resource 'DAG of subjobs', and distinguishes from siblings like propose_job by specifying 'decomposition'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like propose_job or propose_tag. It does not mention prerequisites, nor does it indicate that this tool is specifically for decomposing a parent job into a DAG of subjobs. The only guideline is that cyclic decompositions are rejected.

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

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only states the action (posting) without mentioning side effects, authentication needs (though signature_hex implies it), or what happens after posting.

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, concise sentence with no extraneous information. It is front-loaded with the action, though it could include more details without becoming verbose.

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

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

Given the complexity of a job proposal (4 parameters, nested object, no output schema), the description is insufficient. It omits return values, success conditions, and how the proposal is used.

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

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

Schema coverage is high (75%), so the description adds minimal value beyond the schema. It does not explain the spec or stake parameters, which are only in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool posts a job proposal for funding and serving, using the verb 'Post' and specifying the resource. However, it uses jargon ('Sigma_J generative surface') and does not distinguish from sibling propose_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like propose_decomposition or propose_tag. There is no mention of context, prerequisites, or exclusions.

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

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

No annotations exist, so the description carries the full burden. It does not disclose whether the operation is idempotent, what happens on duplicate proposals, or any authentication/authorization details beyond the presence of a 'signature_hex' parameter. The agent has no insight into side effects or constraints.

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, which is concise, but it omits critical information. It is not well-structured to convey both purpose and necessary context efficiently.

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

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

Given the complexity (5 required parameters, nested object, no output schema), the description is insufficient. It does not explain the return value, any prerequisites, or the overall process of proposing a tag. The high signal count demands a more thorough description.

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

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

Schema description coverage is only 40% (only 'agent_id' and 'signature_hex' have descriptions). The tool description adds no further explanation for 'stake', 'descriptor', or 'parent_tags'—for example, what format 'descriptor' should take or how 'stake' influences the proposal. The description's mention of 'parent tags' adds minimal value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('propose') and the resource ('expertise tag') and includes context ('under parent tags'). However, the phrase 'the Sigma_T surface' is jargon that may confuse an AI agent without further explanation. Overall, it distinguishes well from sibling tools like 'propose_job'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives (e.g., 'claim' or 'propose_decomposition'). The description does not specify prerequisites or scenarios, leaving the agent to guess at the appropriate 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?

No annotations provided; description does not disclose behavior beyond 'propose'. No mention of side effects, reversibility, permissions, or return values. Signature parameter hints at auth but no elaboration.

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?

Single sentence is concise but lacks necessary detail. Could be split to improve clarity without added length.

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?

With 5 required parameters, no output schema, no annotations, and no usage guidance, the description is insufficient for an agent to confidently invoke 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?

Schema description coverage is 40% (only agent_id and signature_hex described). Description adds no additional meaning for stake, schema, or applicable_tags beyond the schema field names.

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?

Clearly states verb 'propose', resource 'contract template', and context 'for a set of tags (the Sigma_K surface)'. Distinguishes from sibling tools like propose_tag and propose_job by focusing on template.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs. alternatives like propose_tag or propose_decomposition. Lacks explicit context, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It mentions creating identity and access but does not disclose behavioral traits such as idempotency, rate limits, authentication requirements, or what happens if already registered. The description is too brief for a registration tool.

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 sentences long, front-loaded with the key action, and contains no unnecessary information. Every word contributes to understanding the tool's purpose.

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?

With 6 required parameters, no output schema, and no annotations, the description is too sparse. It does not explain what the 'canonical register_message' is, how to obtain it, or what the calibration_answer involves. The tool is complex but the description leaves significant gaps.

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 50% (3 of 6 parameters have schema descriptions). The description does not add meaningful parameter-level details beyond referencing the signing process. It fails to compensate for the missing schema descriptions, leaving parameters like sybil_proof and capabilities largely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to register/join the system, create a self-certifying identity, and get access. It uses specific verbs ('join', 'Sign', 'submit', 'create') and distinguishes itself from sibling tools that perform other actions (claim, propose, etc.).

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 as a first step to join the system, but it does not explicitly state when to use it versus alternatives or mention any preconditions or when not to use it. The context is clear but lacks 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?

The description discloses that the deliverable is graded, which is a behavioral outcome. However, with no annotations provided, it fails to mention authentication requirements (signature), side effects (e.g., submission is final), or success/failure responses. The signature parameter is not explained behaviorally.

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

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

The description is a single sentence that is concise and front-loaded with the key action and resource. It contains no superfluous words and efficiently conveys the tool's purpose and one behavioral aspect.

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

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

Given the tool's complexity (four required params, nested object, no output schema), the description provides the core purpose and grading context but omits prerequisites (e.g., must have claimed the job), authentication process, and what happens after submission. It is adequate but not comprehensive.

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

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

The description does not elaborate on any parameter meanings beyond what the input schema already provides. Schema coverage is 75% (three of four params have descriptions), and the description adds no additional semantics for the missing 'job_id' or other fields, relying solely on the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's purpose: submitting a deliverable for a claimed job. It specifies the action ('submit') and the resource ('deliverable for a claimed job'), and adds the outcome ('graded against acceptance criteria'), making it unambiguous among siblings.

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 after claiming a job, which is supported by the sibling tool 'claim'. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to infer the appropriate scenario.

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