Lamdis Exchange

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

With no annotations provided, the description carries the full burden and delivers richly: 'It costs nothing and holds nothing' establishes non-destructive, free behavior; the honest-coverage limitation is disclosed ('coverage here is thin... many addresses where nothing can be dispatched at all'); and the explicit statement that it does not report cost prevents the agent from fabricating prices. These are genuine behavioral disclosures that shape agent conduct beyond what any structured field could convey.

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 first sentence is excellently front-loaded with a direct call-to-action, and the core facts (free, non-destructive, returns supply/refusal/history, no cost) are all present. But the description is roughly 200 words of conversational prose; the trust-loss paragraph and the gutter and driveway illustrations, while reinforcing, are redundant and could be halved without losing meaning.

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 an 8-parameter tool with no output schema and no annotations, the description does strong work on return semantics: what it answers, what it refuses to answer, and how to interpret sparse coverage. However, significant gaps remain — the observe/do kind dimension is absent, slots and instructions are unexplained, and no return structure is given despite the absence of an output schema, leaving the agent to guess at response shape.

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 50%; lat, lon, slots, and instructions are undocumented in the schema. The description partially compensates by anchoring the query to 'that place and those qualifications,' which gives meaning to lat/lon and skills, and 'what you are thinking of asking for' maps to predicate. But slots and instructions receive no explanation anywhere, and the observe-vs-do dimension of 'kind' is never mentioned, so compensation is incomplete.

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 what the tool does: it answers how much supply is reachable for a place and qualifications, whether the job would be refused outright, and what similar work has been paid. The lead line 'Call this BEFORE you tell your person that something can be done in the physical world' anchors its role as a pre-flight feasibility check. However, it never names a sibling tool, so differentiation from find_out or job_evidence is implied rather than explicit.

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?

Gives an explicit trigger condition: call before promising any physical-world action. It also gives a clear when-not: the tool does not tell costs, and the agent is directed not to guess but to post for bids in the bidding round, which implicitly routes to list_bids. The handling instruction for a negative result ('say so plainly and do not offer to arrange it') is concrete and actionable. It stops short of naming alternatives by name or enumerating exclusions systematically.

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 carries the full burden and delivers: it discloses financial consequences ('Money leaves your person's balance when you post this'), the no-key fallback behavior ('nothing leaves anywhere: the reply carries pay_at and token'), the async lifecycle ('the job goes live when their card is authorised'), and incentive effects ('skip it and you teach the people here to take only the easy jobs'). This is rich behavioral disclosure beyond anything the schema states.

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

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

The description is long (four dense paragraphs) but each one earns its place: purpose, payment mechanics, sequencing, and parameter guidance. It is front-loaded with the core action before diving into financial detail. For a 26-parameter tool with no annotations, the length is proportionate rather than padded.

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 (26 params, no annotations, no output schema), the description covers the critical lifecycle: what happens on post, what the reply contains (pay_at, token), how to follow the job, and how to phrase the deliverable. It does not describe the full response shape or enumerate fields like skills, stages, and plan_by, but those are already well documented in the schema at 92% coverage.

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

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

Despite 92% schema coverage, the description adds real semantic depth to key parameters: deliverable ('write it as the thing you would need to see to believe it'), attempt_minor ('set it so whoever travels to an impossible job is not left with nothing'), and unknowns ('a guessed dimension becomes a price nobody can hold to'). It does not touch all 26 parameters, but the ones it addresses get rationale that the schema lacks.

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

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

The description opens with a specific verb and resource: 'Have something in the physical world made true' with concrete examples (sign hung, parcel delivered, slab poured). It clearly establishes this as the action-taking tool versus siblings like check_feasible, job_status, and observe_world, and even names check_feasible as a prerequisite, sharpening the contrast.

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 explicitly says 'Call check_feasible first if you have not already,' naming the key sibling and the ordering. It also gives when-not-to guidance: 'Do not post one without their agreement on the amount unless they have told you a ceiling' and 'Do not describe this to your person as arranged until it has actually been taken.' It stops short of enumerating all sibling alternatives, but the main routing decision is covered.

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 disclosure burden. It reveals the paid human-driven nature, the structured output shape (provider, price, availability, notes), and the contrast to a photograph. It does not mention asynchronous behavior or job tracking despite sibling job tools, but the core behaviors are disclosed.

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?

Three sentences, each earning its place: purpose and deliverable contrast, when to use, and result structure. It is front-loaded and has no filler or repetition.

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?

No output schema exists, but the description explains the return shape well. It covers the main use cases and the kinds of information to request. It does not explain job lifecycle or status-checking, which would be useful given sibling job tools, but parameters are fully documented and the invocation path is clear.

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 100%, so parameter descriptions fully document each field. The tool description adds useful context about the result format but does not add parameter-specific semantics beyond what the schema already provides, so the baseline of 3 applies.

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?

Description states a clear purpose: commission someone to gather real-world information and return structured answers. It lists concrete use cases (quotes, availability, opening hours, stock) and explicitly distinguishes the deliverable from a photograph, separating it from observation-style sibling 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?

Gives explicit guidance on when to use it ('Use for quotes, availability, opening hours, stock — anything where the deliverable is information'). It does not name alternatives or state when not to use it, but the context is clear enough for an agent to select it.

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 behavioral burden. It does disclose useful output behavior: each file comes with a fetchable URL and includes location and challenge-code findings. However, it does not mention side effects, error conditions, or access requirements beyond what the schema already implies.

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?

Three well-organized sentences: what the tool returns, when to use it, and a key detail about the response. Every sentence adds value and the most important information is 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?

The tool is simple with only two parameters and no output schema, so the description must cover return shape and usage context. It does explain the contents of each file and provides a URL note, but it stops short of describing the exact response structure or edge cases like missing evidence.

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 100%, so the schema already documents both parameters. The description does not add new parameter-level meaning, which is acceptable under the high-coverage baseline, but it also does not elaborate on how the job id or token are used.

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 resource: actual evidence files brought back for a job (photographs, video, transcripts), along with location and challenge-code status. It also distinguishes itself from verdict-type tools by saying 'when the verdict alone is not enough,' which separates it from siblings like job_status.

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?

Provides explicit when-to-use guidance: 'Use this when the verdict alone is not enough and you want to look at what was bought, or show it to the person you are acting for.' It does not name alternatives directly or state exclusion cases, but the context is clear enough for an agent to route correctly.

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 burden of disclosing behavior. It adds useful context: the receipt is signed, verifiable without trusting the exchange, and contains a structured summary of the job. However, it does not explicitly state that this is a read-only lookup, what happens if the job is not finished, or any failure/auth edge cases.

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 front-loads the core concept ('signed receipt for a finished job') and then adds essential detail about the receipt's contents and verifiability. There is no redundant wording or unnecessary structure.

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 two-parameter retrieval tool with full schema coverage, the description plus schema is mostly sufficient: the agent knows what the receipt contains and how to verify it. However, without an output schema, an explicit action statement, or guidance on unfinished jobs and authentication variants, the definition is adequate but not fully complete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no parameter-level meaning beyond the schema; it neither clarifies the relationship between 'job' and 'token' nor provides any additional usage details for them.

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 identifies a specific resource—the signed receipt for a finished job—and explains what the receipt records, which clearly distinguishes it from sibling tools like job_status and job_evidence. However, it does not use an explicit verb such as 'returns' or 'gets,' so the agent must infer the action from the tool name and noun-phrase description.

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 'for a finished job' implies the tool is used after a job completes, and the verification property suggests an auditing use case. Still, there is no explicit guidance about when to prefer job_receipt over job_status or job_evidence, nor any exclusions or prerequisites beyond what the schema provides.

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

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

No annotations are provided, so the description must disclose behavior. It transparently lists the information returned: takers, submitted content, checking result, and payment, giving the agent a concrete picture of the response. It does not explicitly state that the operation is read-only or describe error/authorization edge cases, but the status-query framing implies a non-mutating call.

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 entire description is one 21-word sentence that front-loads the core concept and lists key status dimensions with a colon and commas. No filler or redundant wording.

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 no output schema and no annotations, the description carries the burden of explaining the return value, which it does by specifying four status aspects. It does not cover edge cases like invalid job IDs or latency, but for a status lookup the described scope 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 input schema already documents both parameters (job and token) with 100% coverage, so the description need not repeat them. It implicitly ties the 'job' parameter to the status being queried but adds no detail beyond 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 as a status query for a job, enumerating specific status components: whether taken, what was submitted, pass/fail checking, and payment. This distinguishes it from sibling tools like list_bids or job_evidence by focusing on overall job progress. It lacks an explicit verb, but the resource and scope are unmistakable.

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 'Where a job has got to' establishes clear context for when to call the tool: whenever an agent needs the current status of a posted job. It does not name alternative tools or explicitly state when not to use it, but the context is unambiguous and sufficient for selection.

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 transparency burden. It discloses the kind of data returned and scopes it to an open job, but it does not describe output structure, empty-result behavior, closed-job behavior, or any error or auth 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?

The description is two sentences with no filler. It front-loads the resource and its key contents, then adds practical usage guidance in the second sentence.

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 two-parameter list tool with no output schema, the description adequately names the returned bid information: price, availability, and message. It omits edge cases like no bids or closed jobs, but the schema plus description are sufficient for basic invocation.

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

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

The input schema already documents both parameters fully, so the baseline is 3. The description adds the 'open job' framing for the job parameter, but it does not add meaningful detail about the token parameter or parameter formats beyond 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 resource and content: 'The offers on an open job' with charge, timing, and message. It is distinguishable from siblings like job_status or job_receipt by focusing on bids, though it does not explicitly name or differentiate from a sibling.

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 second sentence gives a clear usage directive: show the offers to the human rather than selecting by price alone. This conveys when the tool is useful, but it does not state exclusions or compare against alternative 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?

No annotations are present, so the description carries the full burden, and it is unusually thorough: it discloses payment ('Money leaves your person's balance'), the unauthenticated pay-link flow (pay_at/token), that the job is charged only for proven work, and that a 'no' is a paid, valid result. It also warns against reposting to get a different answer.

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?

Front-loaded with the core purpose, then organized into payment, honesty, and predicate-writing guidance. It is longer than typical MCP descriptions, but the length is justified by financial side effects and user-protection rules; a few sentences could be trimmed without losing 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?

For a paid, asynchronous job-creation tool with no output schema, the description covers the key lifecycle: cost, authorization, token follow-up, and evidence validity. It doesn't specify the exact response shape or error cases, but it provides enough context to call and monitor the job via siblings.

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 100%, so the baseline is 3, and the description adds meaningful guidance for predicate: it must be photographable by a stranger and avoid exact addresses. It doesn't elaborate on lat/lon/radius/fee parameters, but those are already described 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?

States a clear purpose: verify a physical-world claim via paid photographic evidence, not web data. The phrase 'Somebody goes and photographs it, the evidence is checked, and you get an answer or your money back' makes the operation concrete. It doesn't explicitly contrast with siblings like find_out/do_in_world, though it names check_feasible.

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?

Gives clear context: use when physical-world truth is needed and explicitly instructs 'Call check_feasible first if you have not'. It also warns not to tell the user an answer is coming until evidence is taken. It stops short of listing when-not-to-use alternatives such as find_out.

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