GovGazette

Create a saved search

create_saved_search

Create one private saved opportunity search with the supplied name and criteria. Requires authenticated workspace access and explicit user intent. Creates an account workspace if needed and adds a search without replacing existing searches. Returns a private feed link. The first successful check establishes a baseline; no email or external notification is sent.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "criteria": "<criteria>"
    },
    "name": "create_saved_search"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Human-readable name for the new saved search; 1 to 100 UTF-8 bytes after trimming.
`criteria`	Yes	Opportunity filters to save; generation, after and limit are reset by the server.

Output Schema

Name	Required	Description
`id`	Yes
`status`	Yes
`message`	Yes	First successful check establishes a baseline, not delivered changes.
`feed_path`	Yes	Private capability path; do not share it publicly.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026
RemovedOct 28, 2026
AddedOct 8, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare non-readonly, non-destructive, non-idempotent, closed-world, and the description adds real behavioral context on top: it may create an account workspace as a side effect, it appends rather than replaces existing searches, it returns a private feed link, the first check establishes a baseline, and no email/notification is sent. Those are non-obvious side effects and lifecycle details not derivable from the annotations or schema.

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?

Four short sentences, front-loaded with the core action and then the preconditions and side effects; little waste. The 'Requires authenticated workspace access and explicit user intent' sentence is dense but earns its place as a guardrail.

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?

For a two-parameter creation tool with an output schema, the description covers action, preconditions, side effects, idempotency-adjacent behavior (baseline on first check), and notification behavior. Nothing needed to call it correctly is missing, and return values are covered by the output schema.

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 description coverage is 100%, so the schema already documents 'name' (length limits) and the nested criteria object in detail. The description only restates that a name and criteria are supplied and does not add filter semantics beyond the schema, so the baseline of 3 is appropriate.

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 specific verb and resource ('Create one private saved opportunity search') and clarifies the mutation is additive ('without replacing existing searches'), which disambiguates it from overwrite semantics. It never names a sibling tool, so it stops short of full sibling differentiation, but the resource is unambiguous.

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 a clear precondition for use ('Requires authenticated workspace access and explicit user intent'), which is exactly the kind of gate an agent needs before creating persistent state. It does not name alternatives such as list_saved_searches or delete_saved_search or state when not to create a search, so no exclusions are provided.

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

All GovGazette tools Inspect

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.