Skip to main content
Glama

Loci Labs Real-World Observations

Search real-world observations

search_real_world_observations
Read-onlyIdempotent

Search for fresh real-world observations about physical places, conditions, availability, crowds, lines, closures, construction, weather effects, events, inventory visible in person, accessibility, or other facts that may be stale, uncertain, or unavailable on the public web. Use this when answering the user's question would benefit from a recent observation made by a person physically present at or near the relevant location.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contextNoOptional extra context that helps interpret the question. Do not include personal or sensitive information.
locationNoPlace name, address, neighborhood, venue, or coordinates written as text. Precision is not required.
questionYesWhat you want to know, in natural language. Examples: "Is the playground muddy right now?", "How long is the security line?"
freshnessNoHow recent the observation needs to be, e.g. "right now", "within 30 minutes", "today", "within 24 hours".
observation_typeNoKind of observation: crowd, condition, availability, closure, construction, weather impact, accessibility, inventory, event status, or other.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes
messageYes
requestYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety and non-mutating aspects of the tool. The description adds context about the nature of the returned data (fresh, real-world, from a person physically present) and the types of facts (stale, uncertain). However, it does not clarify response structure or any potential rate limits or access conditions, so it adds moderate value but not fully comprehensive.

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

Conciseness5/5

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

The description is a single, dense paragraph that front-loads the core purpose and the when-to-use guidance. It is concise, with no filler or redundant phrasing. Every sentence contributes value: the first lists the kinds of observations, the second states the trigger condition for use. It avoids enumerating parameters or restating the title, and the structure is clear and efficient.

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?

The tool has a single required parameter (question), an output schema, and five optional parameters with high schema coverage. Given this complexity, the description provides sufficient detail about the purpose and when to use it. The only minor gap is that it does not explicitly explain the return format, but since there is an output schema, that information is available elsewhere. For a search tool with these features, the description is nearly complete.

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

Parameters3/5

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

The schema description coverage is 100%, meaning all five parameters (context, location, question, freshness, observation_type) are already well-documented in the input schema. The description itself does not add additional detail about the parameters beyond what is in the schema. For example, it implies the use of 'question' and 'freshness' but doesn't clarify specific formats or edge cases. Since the schema covers the semantics, a baseline score of 3 is appropriate, as the description is not necessary for parameter understanding.

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

Purpose5/5

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

The description provides a comprehensive list of the categories of observations the tool can retrieve (e.g., closures, crowds, weather effects), and clearly states that it is for facts 'that may be stale, uncertain, or unavailable on the public web.' It uses specific verbs like 'Search for fresh real-world observations about physical places' and distinguishes it from general web searches. Even without siblings listed, it establishes a unique purpose that is far more specific than its simple title.

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

Usage Guidelines5/5

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

The description explicitly states when to use the tool: 'Use this when answering the user's question would benefit from a recent observation made by a person physically present at or near the relevant location.' This guides the agent on the appropriate trigger condition, making it clear that it is for questions requiring on-the-ground, up-to-date information. While it doesn't provide a when-not-to-use, the 'when to use' is explicit and sufficient in context.

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.

Resources