Skip to main content
Glama
simplepush

Simplepush MCP Server

Official
by simplepush

Search everything by words or by place

search_knowledge

Search all organizational records—tasks, answers, replies, notifications, submissions—by text or location to retrieve ranked matches and their IDs.

Instructions

Full-text and location search over everything this credential reads — the organization's records, or what a personal account sent and submitted: task titles and content, answers, replies, notifications and their answers, and ad-hoc submissions — across all time, ranked. Use it for 'anything about X?', 'what was said about X?', 'who mentioned X?'. Words match literally, and by stem in the languages the organization configured (so 'leak' finds 'leaking' only where stemming is on); several words must all appear; quote a phrase for adjacency. For 'what happened around ?' pass center/radius_meters instead of (or on top of) the query: alone they return the location answers, replies and submissions recorded within the radius, nearest first; with a query, text hits are kept only when their task or submission carries an in-radius point. For a shape rather than a circle — a site, a block, a stretch of road — pass area_points, a polygon of 3 to 50 corners, instead; those hits carry no distance and come newest first. Resolve a street or site name to coordinates yourself first, and prefer a generous radius when the coordinates are geocoded rather than known. Each hit carries the id to read in full (tsk_/sub_ with get_task, grptsk_ — a task sent to several people — with get_group_status, ntf_ with get_notification_answer, sbm_ with query_submissions) and a snippet with the matching words in brackets (a location hit carries its point and distance instead). Encrypted records are not searchable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoOnly these kinds of hit.
limitNoBest hits to return; default 20, at most 100.
queryNoThe words to look for. Optional when center or area_points is given.
sinceNoISO-8601 instant; only items created at or after this.
untilNoISO-8601 instant; only items created at or before this.
centerNoWGS84 center of a radius filter; requires radius_meters.
memberNoOnly units written by this person: a usr_ id, an org member's name, or on a personal account the name of someone in your own activity.
area_pointsNoCorners of a polygon to search inside instead of a circle; not combinable with center/radius_meters.
radius_metersNoRadius around center, in meters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers extensively: stemming behavior depends on org config, multiple words must all appear, phrases require quoting, location-only results are sorted nearest-first, combined query+radius filters hits by in-radius points, and encrypted records are not searchable. This is far beyond minimal disclosure.

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 dense but every sentence earns its place, moving from scope to matching behavior to location modes to hit payloads and limitations. Front-loaded with the most important search intent and progressively detailing edge cases, it avoids filler while fully covering a complex 9-parameter tool.

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 complex tool with no output schema and no annotations, the description is unusually complete: it explains result IDs and how to follow up with get_task/get_group_status/get_notification_answer/query_submissions, describes snippets and location-hit payloads, covers ranking order in both circle and polygon modes, and flags non-searchable encrypted records. An agent has enough to invoke it correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds substantial operational meaning: how query matching works, when center/radius_meters alone or combined with query changes result semantics, polygon use and ordering, snippet composition, and practical advice like preferring generous radii for geocoded coordinates. This goes well beyond the schema's bare field definitions.

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 specifies a clear verb and resource: full-text and location search over all records this credential reads, listing task titles/content, answers, replies, notifications, and submissions. It also distinguishes itself from siblings by positioning itself as the broad 'search everything' entry point rather than a narrower query_tasks/query_submissions-style tool.

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?

The description gives explicit use cases: 'anything about X?', 'what was said about X?', and 'who mentioned X?', plus clear guidance for location search. It references the getter siblings for reading full hits and advises resolving coordinates first, but it does not explicitly say when not to use this tool versus targeted alternatives like query_tasks.

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