Skip to main content
Glama
Sign In

NetActuate

by com.netactuate
OverviewDiscussionsAdmin

Find apps in NetActuate's marketplace

find_marketplace_apps
Read-only

Finds deployable apps in NetActuate's marketplace (netactuate.com/marketplace): streaming servers, transcoders, WebRTC, CDN and media software that deploys on NetActuate's edge, open source and from partners such as Wowza, Broadpeak and NETINT. Filter by any mix of words, vendor, category, licensing and freeDemo; with no filter it lists them all, featured first, limit at a time. A vendor or category it does not know is explained in a note naming the valid ones. Each result gives the slug, name, vendor (null for open source), tagline, licensing (free, byol, trial), vpu when it needs NETINT VPU hardware, freeDemo with its terms, sizing (minimum and recommended vCPU, RAM and disk) and its URL; count is the full number of matches. Use for 'what can I deploy on NetActuate', 'is there an SRT gateway', 'which apps can I try for free' or 'what does NetActuate offer from Wowza'. One listing in full: get_marketplace_app; the vendors: list_marketplace_partners. Listings do not say where they run; for an app and a place together, use search_netactuate ('Wowza Africa').

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

Input Schema

NameRequiredDescriptionDefault
limitNoHow many listings to return, 1 to 50.
queryNoWords that must all appear in the listing (name, vendor, description, features, use cases, protocols), e.g. 'transcode', 'WebRTC', 'SRT', 'ad insertion'.
vendorNoA vendor as list_marketplace_partners names it, e.g. 'Wowza', 'NETINT', 'Broadpeak'. 'Open Source' gives the open-source projects.
categoryNoA marketplace category: 'Media & Streaming', 'Networking & Security', 'AI & ML', 'Observability', 'Storage' or 'Consulting & Services'.
freeDemoNotrue for only the listings that offer a free live demo from their page.
licensingNo'free', 'byol' (bring your own license, plus NetActuate compute) or 'trial'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  3. Changed1 schema field changed
    • addedInput schema / properties / freeDemo
      Added value: +{
+  "description": "true for only the listings that offer a free live demo from their page.",
+  "type": "boolean"
+}
  4. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish this as a safe read-only, non-open-world operation, but the description adds substantial behavior: no-filter ordering by featured first, limit-based pagination, handling of unknown vendors/categories, and the complete set of returned fields including count semantics. It also discloses the important limitation that listings do not say where apps run and routes that need to search_netactuate.

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 long but front-loaded and information-dense: purpose first, then filtering behavior, return shape, example uses, sibling alternatives, and the location limitation. Each section contributes actionable context, particularly because there is no output schema.

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 read-only find tool with six optional parameters and no output schema, the description is complete enough to call correctly. It explains filtering, pagination, return fields, count meaning, unknown-value handling, and the key limitation about locations with a clear alternative tool.

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 100%, so the baseline is 3, but the description adds useful semantic context: filters can be mixed, no filter lists all, and unknown vendor or category names produce a note naming valid values. It does not need to repeat every schema detail, though some parameter descriptions are schema-level rather than new explanatory content.

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 opens with a specific verb and resource: finds deployable apps in NetActuate's marketplace, and it scopes the content to streaming, transcoding, WebRTC, CDN and media software. It explicitly distinguishes itself from get_marketplace_app, list_marketplace_partners and search_netactuate, so an agent can select it without opening the 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?

It gives explicit usage contexts ('what can I deploy', 'is there an SRT gateway', free trials, Wowza offerings) and states the no-filter behavior. It also names the sibling tools for full listings, vendors, and app-plus-location searches, making the when-to-use boundaries very clear.

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

All NetActuate 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