Skip to main content
Glama
Sign In
GravityPort

GravityPort

by fengseekling-coder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

asset_search

Read-only

Search GravityPort visual memory by keyword and creation-time bounds; all query words must match. Returns paginated asset summaries, with asset_get for full recipe and metadata.

Instructions

Search GravityPort visual memory using lexical search and explicit creation-time bounds. Multiple query words are combined with AND: every word must appear for an asset to match; OR is not supported. Returns compact per-asset summaries with the total match count (20 per page by default, at most 100; pass cursor to page further); use asset_get for an asset's full recipe and metadata.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "asset_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNoSpace-separated words; every word must appear (AND). OR is not supported.
cursorNo
visualNoDeprecated and ignored.
minScoreNoDeprecated and ignored.
createdAfterNoInclusive lower creation-time bound. A date-only value ("2026-11-07") means local midnight of that day on this machine; a value with Z or a ±hh:mm offset keeps its explicit zone.
createdBeforeNoInclusive upper creation-time bound. A date-only value ("2026-11-07") means local midnight of that day, so the bound is "before Nov 7 starts" — assets created on Nov 7 itself are outside. A value with Z or a ±hh:mm offset keeps its explicit zone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.11

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds behavior the annotations cannot: AND-only matching semantics, compact per-asset result shape, total match count, a 20-item default page size and 100 ceiling, and cursor-based continuation. It does not explain ranking or ordering of results, which for a search tool is the main remaining unknown.

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?

Three sentences, front-loaded with the search scope before query semantics, result shape, and the sibling redirect. It is dense but each clause carries information; the AND rule is stated compactly and reinforced with "OR is not supported" rather than restated at length.

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?

With seven parameters, no required fields and no output schema, the definition covers what an agent needs: matching rules, result granularity, pagination defaults, the boundary semantics of the time filters, and the redirect for full detail. The main gap is result ordering, which matters for deciding how far to page.

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?

Schema coverage is 71%, so the createdAfter/createdBefore boundary semantics, including the date-only local-midnight interpretation, are already documented in the schema. The description adds the default page size of 20 and the cursor-paging intent, which the schema does not state, but says nothing about the two deprecated parameters beyond what the schema already discloses.

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 states a specific verb and resource ("Search GravityPort visual memory") and narrows scope to lexical search with explicit creation-time bounds, which separates it from listing or retrieving tools. It also names the sibling asset_get for the detail-retrieval case, so an agent can pick between them 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 Guidelines4/5

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

It clearly gives the retrieval alternative ("use asset_get for an asset's full recipe and metadata") and states the query constraint (AND only, OR unsupported), which prevents wrong query construction. It does not distinguish itself from asset_list or say when search is preferred over plain enumeration, leaving one inference to the agent.

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

Deploy Server

Other Tools