Skip to main content
Glama

observe_world

Find out whether something is actually true in the physical world, rather than what a website says about it. Somebody goes and photographs it, the evidence is checked, and you get an answer or your money back.

Money leaves your person's balance when you post this. If you connected without a key, nothing leaves anywhere: the reply carries pay_at and token. Send the person the pay link; the job goes live when their card is authorised, and it is charged only for what is proven done. Keep the token — it is how you follow the job. Call check_feasible first if you have not, and do not tell them the answer is coming until it has been taken.

Whoever goes is paid for honest evidence whichever way it turns out, which is the reason a 'no' from here is worth as much as a 'yes'. Treat both as real findings: if it comes back no, tell your person no. Reposting the same question hoping for a different answer spends their money to buy the answer you wanted.

Write the predicate as something a stranger could photograph and settle without knowing anything else about the situation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNolatitude to fence the evidence to
lonNolongitude to fence the evidence to
areaNocoarse locality shown on the open board, e.g. a neighbourhood or town; never put the exact address here
slotsNohow many independent people should check (default 1)
whereNothe exact address or place to check; released only to whoever takes the job, never published
radius_mNohow far from that point evidence may be taken
fee_minorYespaid for usable evidence whichever way the answer turns out, in minor units
predicateYeswhat must be true, stated so a stranger with a camera could check it. Shown on the open board, so keep the exact address out of it unless that address is already public
bonus_minorNopaid additionally if the predicate holds

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, 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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target clearly distinct actions: feasibility checking, posting physical work, gathering structured info, verifying truth, and reviewing job artifacts. The only plausible confusion is between find_out and observe_world, since both involve paying someone to investigate the physical world, though their outputs differ.

Naming Consistency3/5

All names are snake_case and readable, but the pattern is mixed: check_feasible, find_out, observe_world, and list_bids are verb-first, do_in_world is a unique verb+preposition, and job_evidence, job_receipt, and job_status are noun-first. The job_* family is internally consistent, but the set as a whole lacks a single predictable convention.

Tool Count5/5

Eight tools is well-scoped for a physical-world exchange: pre-flight feasibility, posting work, requesting information, verification, bidding, status, evidence, and receipts. Each tool earns its place and the count is neither bloated nor thin.

Completeness4/5

The core lifecycle is covered: check feasibility, post a job, review bids, track status, inspect evidence, and get a verifiable receipt. The main gaps are no explicit cancel/update job tool and no direct job listing tool, but agents can navigate the main workflows without dead ends.