Search machine services observed by Atinamos harvesters across external discovery sources. Results are observational evidence, not an endorsement, trust score or guarantee of current availability.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It usefully discloses that results are observational evidence and not a guarantee of current availability or trustworthiness. It does not mention authentication needs, rate limits, failure behaviors, or whether results may be stale, but the caveat adds meaningful context beyond the basic purpose.
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, front-loaded sentence that immediately states the action and resource, then adds a valuable caveat. There is no filler or redundant repetition of the tool name.
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 two-parameter search tool with an output schema, the description covers the essential purpose and a key data-quality caveat. However, it lacks explicit guidance on choosing this tool over siblings and leaves parameter behavior largely implied, so the overall context 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 0%, so the description must compensate for explaining query and limit semantics. It does not clarify how query is matched, what fields are searched, or how limit affects pagination. The terms are self-explanatory at a basic level, but the description adds no parameter-specific meaning 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 a specific verb and resource: search machine services observed by Atinamos harvesters. It distinguishes itself from likely siblings by emphasizing external discovery sources and observational evidence, making it clear this is a search tool rather than a retrieval, invocation, or listing tool.
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 intended context: searching externally observed machine services rather than confirming availability or endorsing them. However, it does not explicitly state when to use this tool over list_services, get_service, invoke_service, or market_service, nor does it provide exclusions or alternative routing guidance.
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.
The live Agent Shop tools (get_service, list_services, invoke_service) are clearly distinct, and the market tools (market_search, market_service) are also separated by search vs. direct lookup. There is mild potential confusion between get_service and market_service since both retrieve a single service, but their differing sources and identifiers make them distinguishable.
get_service, list_services, and invoke_service follow a clear verb_noun pattern. market_search and market_service break that pattern by using a domain noun plus an action/object, making the naming convention somewhat mixed but still readable and predictable within each subgroup.
Five tools is well-scoped for an Agent Shop that covers both catalogue access and market observation. Each tool serves a distinct purpose without redundancy or bloat.
The tool surface covers the core workflows: discovering services, retrieving definitions, preparing paid invocations, searching the market, and looking up market records. No obvious lifecycle operations are missing because this is a read-oriented shop interface rather than a management API.