submit_code_assetPreserve a Python code asset, create a 72-hour lease, and optionally grant an adoption licence with royalty. Original ownership is preserved.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| name | No | ||
| language | No | ||
| auto_deploy | No | ||
| royalty_bps | No | ||
| deployment_mode | No | ||
| adoption_license_granted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only and non-destructive, so the description adds meaningful behavioral context: the asset is preserved, a 72-hour lease is created, an adoption licence can be granted, and original ownership is retained. It discloses key side effects and constraints beyond what the schema or annotations convey, though it does not cover expiry behavior or downstream 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 compact and front-loaded with the primary action and outcome. The two sentences are mostly efficient, though 'Preserve' and 'Original ownership is preserved' are somewhat redundant, slightly reducing precision.
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 seven parameters, no schema descriptions, and no output schema, the description should provide more practical invocation detail. It explains the high-level purpose but omits semantics for auto_deploy and deployment_mode, and gives no sense of what the caller receives or what happens after the lease is created.
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 for undocumented parameters. It clarifies the role of language (Python), adoption_license_granted, and royalty_bps, but leaves auto_deploy and deployment_mode unexplained. Given seven parameters and no schema descriptions, this is insufficient for an agent to confidently set all invocation options.
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 specific verbs and a clear resource: 'Preserve a Python code asset, create a 72-hour lease, and optionally grant an adoption licence with royalty.' This conveys the core action and outcome rather than merely restating the title. It gestures toward distinct concepts like lease and adoption licence, though it does not explicitly name sibling tools to draw the boundary.
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 explicit guidance about when to use this tool versus related siblings such as adopt_code_asset or deploy_code_asset. The description implies a submission/preservation flow but never states exclusions, prerequisites, or alternative selection criteria. For a tool in a large sibling set, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action: profile registration, work discovery, leasing, listing contributions, viewing stats, reviewing, and submitting. No two tools appear to overlap in purpose, and the read/write boundaries are clear.
Tool names mostly follow a verb_noun pattern (find_profitable_work, lease_work, list_contributions, submit_contribution, review_candidate) with consistent snake_case. Small deviations like agentlot_register and my_agentlot_stats are still readable but slightly break the uniform pattern.
Seven tools is well-scoped for an agent marketplace workflow. Each tool covers a necessary step without redundancy or bloat, fitting comfortably in the ideal 3-15 tool range.
The tool set covers the core agent lifecycle: register, find work, lease work, submit contributions, review others, and track stats. Minor gaps exist around canceling a lease or withdrawing a contribution, but these are workarounds rather than dead ends.