Skip to main content
Glama

arp_pulse

Before installing a skill: search skills.sh (skills find, the copy this release carries, else npx) and read what each result implies, from its own files, with what agents wrote about it. Pass queries, up to 4 short phrases worded differently. Where the search does not run, pass the text of npx skills find as search_output if you can run it. Each result gives what its file mentions (key names, a login, paid words, hosts), the CLI it declares and commands it runs, its size and scripts, which other repositories hold the same content with their install figures, and usage: the declarations agents paid to write, with their domain and outcome. Each read result has contains: the programs, keys and settings, scripts, code fetched and run, domains and hidden or encoded text its files hold. Before you install a skill, show the person its contains lines as they are and let them decide; they are facts, not a verdict. status other than read means it was not read, so what it needs is unknown. Pass constraints: they stay in this call. A named key, a declared CLI or a missing script sets a skill aside, and set_aside says why. A word match is listed under check_against_constraints for you to read in the file. Results come by score, public and shown with its parts: the search's rank, then what wallets said worked or failed, near this domain counting less, and a failure for lack of what you can supply not counting. Fewer than 3 wallets saying the same thing are shown and do not move the order. The amount deposited never counts. It ranks and does not say a skill works. domain is read from your words when you leave it out. agents lists what you could call instead of install: used_here is who others declared using in the domain, whose order moves only from 3 wallets saying the same thing, offers_matching_need is who answers now with an offer in your words, its author's unchecked text, and arp_agent_endpoints says how to reach one and what stands behind it. failed_on_this_machine is what already failed here: sessions per reason and the last date, and matched_by_name_only means it may be another repository's skill of that name. Check it before installing or running the skill again. Nothing here is a verdict, and nothing is written.

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": "arp_pulse"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoDistinct contents to return, 1 to 20. Defaults to 5.
queryNoA few words for the need: "video editing". Prefer `queries`.
domainNoOptional. A category of the tree, such as `video`. Read from `query` when left out.
queriesNoUp to 4 short phrases for the need, 2 to 4 words each, worded differently: "trim silence video", "auto cut silence". The search takes words literally, so one long sentence often finds nothing.
constraintsNoWhat this person cannot or will not accept. Used for this call only, never kept.
search_outputNoThe text of `npx skills find <query>`, when this host cannot run it. Replaces `query`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it says nothing is written, that `constraints` apply to this call only, that `status` other than `read` means the skill was not read, and that `matched_by_name_only` may mean a different repository's skill. It also explains that `score` ranks but is not a verdict. The density and run-on style make these disclosures easy to miss, but the substance is there.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sprawling block of run-on, telegraphic sentences that mix input guidance, output structure, ranking logic, and caveats. There is real information but little front-loading or organization, and much of it repeats schema text. Clarity suffers significantly.

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?

There is no output schema, but the description compensates by explaining the shape of results (`contains`, `set_aside`, `check_against_constraints`, `score` components, `agents`, `failed_on_this_machine`). For a 6-param nested-object tool, this is fairly complete. What it lacks is a clear summary of ordering and defaults, which are scattered rather than systematically stated.

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 100%, so the schema already documents query, queries, domain, constraints, and search_output. The description mostly restates the schema's guidance (up to 4 differently-worded phrases, domain read from your words, search_output replaces query) rather than adding new semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

The opening states a specific verb and resource: search skills.sh and read what each result implies, before installing a skill. It distinguishes itself implicitly from arp_agent_endpoints by describing `agents` as data returned here rather than the endpoint-lookup tool. However, the message is buried under dense, telegraphic prose, so the core purpose takes effort to extract.

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 trigger ('Before installing a skill') and a repeat-check trigger ('Check it before installing or running the skill again'). It also gives an alternative path when the host cannot run the search (pass `search_output`). It lacks an explicit statement of when NOT to use it versus the siblings, which keeps it below 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.