Skip to main content
Glama

IRIS: startup intelligence

get_wire

Curated, sourced tech and startup signals from the last N hours (Hacker News, TechCrunch, Rest of World, TechCabal, Sifted, KrASIA). Headlines are the sources' own; each links to the original.

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

Input Schema

NameRequiredDescriptionDefault
rawNotrue returns everything collected, uncurated. Default: curated for startup intelligence.
hoursNo1-72, default 24

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description does carry useful behavioral detail: content is curated by default, sources are listed, headlines are unmodified, and each item links to the original. It does not disclose volume, ordering, pagination, or what the response structure looks like, so the behavioral picture is partial.

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?

Two tight sentences: the first front-loads what the tool returns and its time scope, the second adds provenance and link behavior. Nothing is redundant or buried.

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?

For a two-parameter read tool with full schema coverage and no output schema, the description covers content type, sources, time window, and link semantics. The main omission is any sense of result volume or ordering, which would help an agent decide between this and the sibling brief tools.

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 both parameters are already documented in the schema, including the 1-72 range and default 24 for hours. The description reinforces the time-window and curated-vs-raw model but adds no syntax or edge-case meaning beyond what the schema states. Baseline 3 applies.

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 description names the resource concretely (curated tech and startup signals) and enumerates the actual sources (Hacker News, TechCrunch, Rest of World, TechCabal, Sifted, KrASIA), which distinguishes it from broader siblings like get_daily_brief or get_market. It lacks an explicit contrast sentence against those siblings, so an agent must infer the split rather than read it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is only implied: 'signals from the last N hours' suggests a recency-bounded news pull. There is no statement of when to prefer this over get_daily_brief or get_market, and no prerequisites or exclusions are given.

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.

Resources