Skip to main content
Glama

Petnecto

by com.petnecto
OverviewDiscussionsAdmin

Search by description

search_by_description
Read-onlyIdempotent

Find pets from wishes in the person's own words, in any language (“a calm small dog good with kids near Seattle”). Use it for wishes listings rarely state, like calm or good with kids: each pet's match says, per wish, stated, inferred (read from its text, with a %) or not_stated, and pets that do not say are left out and counted in not_stated unless include_unknown=true. The answer's understood.chips say what was searched; drop a wrong one with off=[chip id]; a chip noted approx or hint is not a fact about any pet. Found pets (found:true) are not adoptable. Prefer find_pets for structured values.

Input Schema

NameRequiredDescriptionDefault
offNoChip ids from a previous answer's understood.chips to leave out, e.g. ["good_with:kids"]
langNoThe person's language: en, es, zh-Hant, zh-Hans, ko, ja, vi, fr, ar, tl (default en)
nearNoWhere, if it is not in the query: a Taiwan county or township in any language, a US ZIP, Zaragoza, Wien or Fukushima (福島県), or lat,lon
pageNo
limitNo
queryYesWhat the person wants, in their own words and language, e.g. “a senior dog in Zaragoza”, “a friendly cat near 98101”, “小型犬 台北”
countryNoTW (Taiwan), US (King County WA, Montgomery County MD only), ES (Zaragoza), AT (Vienna, found pets only) or JP (Fukushima Prefecture)
include_unknownNoAlso include pets whose listing does not say whether they are good with dogs/cats/kids (they are marked not_stated)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"TW (Taiwan), US (King County WA and Montgomery County MD only), ES (Zaragoza) or AT (Vienna, found pets only)"New value: +"TW (Taiwan), US (King County WA, Montgomery County MD only), ES (Zaragoza), AT (Vienna, found pets only) or JP (Fukushima Prefecture)"
    • changedInput schema / properties / country / enum
      Previous value: -[
-  "TW",
-  "US",
-  "ES",
-  "AT"
-]New value: +[
+  "TW",
+  "US",
+  "ES",
+  "AT",
+  "JP"
+]
    • changedInput schema / properties / near / description
      Previous value: -"Where, if it is not in the query: a US ZIP (98101, 20850), lat,lon, a Taiwan place, Zaragoza or Wien"New value: +"Where, if it is not in the query: a Taiwan county or township in any language, a US ZIP, Zaragoza, Wien or Fukushima (福島県), or lat,lon"
  2. Changed4 schema fields changed
    • addedInput schema / properties / country / description
      Added value: +"TW (Taiwan), US (King County WA and Montgomery County MD only), ES (Zaragoza) or AT (Vienna, found pets only)"
    • changedInput schema / properties / country / enum
      Previous value: -[
-  "US",
-  "CA",
-  "TW"
-]New value: +[
+  "TW",
+  "US",
+  "ES",
+  "AT"
+]
    • changedInput schema / properties / near / description
      Previous value: -"A US ZIP, lat,lon or a Taiwan place, if it is not in the query"New value: +"Where, if it is not in the query: a US ZIP (98101, 20850), lat,lon, a Taiwan place, Zaragoza or Wien"
    • changedInput schema / properties / query / description
      Previous value: -"What the person wants, in their own words and language, e.g. “a calm small dog good with kids, under 10 kg, near 65738”"New value: +"What the person wants, in their own words and language, e.g. “a senior dog in Zaragoza”, “a friendly cat near 98101”, “小型犬 台北”"
  3. Added

TDQS

A4.6/5.0
Behavior4/5

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

Well beyond the annotations, it explains match semantics (stated / inferred with a % / not_stated), that unstated pets are excluded and counted, and that findings marked found:true are not adoptable. The remaining gap is the approx/hint caveat being phrased tersely ('a chip noted approx or hint is not a fact about any pet') without saying how such chips affect match confidence.

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?

Purpose is front-loaded in the first clause, followed by match semantics, the off/chips mechanism, and the sibling alternative. It is dense and the third sentence is a run-on carrying several distinct facts, but essentially no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description still explains the return shape an agent needs to act on: per-wish match statuses, understood.chips, and the found flag. Combined with the parameter coverage, an agent has enough to call it and interpret the result correctly.

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 75%, so the schema already documents near, country, lang and include_unknown. The description still adds cross-call meaning the schema cannot: 'off' works on chip ids from a previous answer's understood.chips, and include_unknown changes whether non-stating pets appear or are merely counted. It doesn't clarify paging behavior for page/limit.

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?

States a specific verb and resource ('find pets from wishes in the person's own words, in any language') and immediately scopes it to fuzzy/qualitative wishes rather than structured attributes. It also names the sibling it is not ('Prefer find_pets for structured values'), so an agent can route without opening either schema.

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?

Explicitly says when to use it ('wishes listings rarely state, like calm or good with kids') and names the alternative plus the condition that selects it ('Prefer find_pets for structured values'). It also documents the recovery path (drop a wrong chip with off=[chip id]) and the include_unknown escape hatch, leaving little to inference.

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

All Petnecto toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources