Skip to main content
Glama

signals

by com.datahyena
OverviewDiscussionsAdmin

hiring_signals

Read-only

List hiring signals read from companies' own job boards, newest first: leadership openings, team build-outs, hiring surges and freezes, expansion into new countries and hard-to-fill roles. Each signal carries the roles behind it. Filter by type, function, seniority, company or a time window. Costs one credit per returned signal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum records to return (1-100). Each returned record costs one credit.
sinceNoReturn records announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp.
untilNoReturn records announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp.
cursorNoOpaque pagination cursor returned as pagination.nextCursor on the previous page.
domainNoCompany domain, e.g. stripe.com. Matches the company's primary domain or any domain it redirected from; a full URL works too.
functionNoJob functions, e.g. sales or engineering. Canonical values: engineering, data, security, it, product, design, sales, marketing, customer_success, operations, finance, people, legal, research, healthcare, executive, other, all.
companyIdNoFilter by company id.
countriesNoHeadquarters country codes (ISO alpha-2, OR). Pass "unknown" to include companies with no country on file.
eventTypeNoSignal types. Canonical values: leadership_opening, founding_role, role_family_scaling, technology_hiring, team_buildout, hiring_surge, hiring_freeze, location_expansion, hard_to_fill, leadership_filled.
seniorityNoSeniority of a leadership opening, e.g. c_level, vp_level, head, director.
activeOnlyNoOnly signals whose roles are still open.
roleFamilyNoRole families, e.g. sales_development, revops, security. Canonical values: sales_development, sales, sales_engineering, revops, gtm_engineering, partnerships, marketing, demand_gen, product_marketing, content_brand, customer_success, support, software_engineering, hardware_engineering, infrastructure, security, data_engineering, data_analytics, ml_ai, product_management, design, recruiting, people, finance, legal, it, operations, science, production.
includeTotalNoAlso return pagination.total, the number of records matching these filters across all pages. Costs no credits.
technologiesNoTechnologies named in the roles, e.g. snowflake, salesforce, kubernetes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / fundedWithinDays
      Removed value: -{
-  "description": "Only companies that announced a funding round this many days before the signal.",
-  "maximum": 365,
-  "minimum": 1,
-  "type": "integer"
-}
  2. Changed4 schema fields changed
    • changedInput schema / properties / eventType / description
      Previous value: -"Signal types. Canonical values: leadership_opening, team_buildout, hiring_surge, hiring_freeze, location_expansion, hard_to_fill, leadership_filled."New value: +"Signal types. Canonical values: leadership_opening, founding_role, role_family_scaling, technology_hiring, team_buildout, hiring_surge, hiring_freeze, location_expansion, hard_to_fill, leadership_filled."
    • changedInput schema / properties / eventType / items / enum
      Previous value: -[
-  "leadership_opening",
-  "team_buildout",
-  "hiring_surge",
-  "hiring_freeze",
-  "location_expansion",
-  "hard_to_fill",
-  "leadership_filled"
-]New value: +[
+  "leadership_opening",
+  "founding_role",
+  "role_family_scaling",
+  "technology_hiring",
+  "team_buildout",
+  "hiring_surge",
+  "hiring_freeze",
+  "location_expansion",
+  "hard_to_fill",
+  "leadership_filled"
+]
    • addedInput schema / properties / fundedWithinDays
      Added value: +{
+  "description": "Only companies that announced a funding round this many days before the signal.",
+  "maximum": 365,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / roleFamily
      Added value: +{
+  "description": "Role families, e.g. sales_development, revops, security. Canonical values: sales_development, sales, sales_engineering, revops, gtm_engineering, partnerships, marketing, demand_gen, product_marketing, content_brand, customer_success, support, software_engineering, hardware_engineering, infrastructure, security, data_engineering, data_analytics, ml_ai, product_management, design, recruiting, people, finance, legal, it, operations, science, production.",
+  "items": {
+    "enum": [
+      "sales_development",
+      "sales",
+      "sales_engineering",
+      "revops",
+      "gtm_engineering",
+      "partnerships",
+      "marketing",
+      "demand_gen",
+      "product_marketing",
+      "content_brand",
+      "customer_success",
+      "support",
+      "software_engineering",
+      "hardware_engineering",
+      "infrastructure",
+      "security",
+      "data_engineering",
+      "data_analytics",
+      "ml_ai",
+      "product_management",
+      "design",
+      "recruiting",
+      "people",
+      "finance",
+      "legal",
+      "it",
+      "operations",
+      "science",
+      "production"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
  3. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare this a safe, read-only, open-world read, so the safety profile is covered. The description adds genuinely non-annotated context: the cost model ('costs one credit per returned signal'), the ordering guarantee, the provenance of the data, and the fact that each signal carries its underlying roles. Auth requirements and rate limits remain undisclosed.

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?

Three tight sentences, front-loaded with the what-and-where, then filters, then cost. Nothing is wasted, though 'Costs one credit per returned signal' partially duplicates the limit parameter's schema description and the roles sentence sits oddly after the filter list rather than with the return description.

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 14-parameter, no-output-schema tool, the description covers source, ordering, signal taxonomy, filter dimensions, and even return structure ('each signal carries the roles behind it') plus the billing rule. It is close to sufficient; a note on pagination expectations or the interaction between activeOnly and the default time window would close the remaining gap.

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 every one of the 14 parameters, including the credit-per-record cost in 'limit'. The description's filter list mirrors the schema's own categories without adding syntax, defaults, or format guidance, so the baseline of 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?

States a specific verb (List) and resource (hiring signals) with unusual precision: the data source ('read from companies' own job boards'), the sort order ('newest first'), and an enumeration of the signal kinds returned. This is far beyond a tautology. It stops short of 5 because it never names or contrasts with the closest sibling, company_hiring, leaving the cross-company vs per-company distinction to inference.

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?

The sentence 'Filter by type, function, seniority, company or a time window' enumerates the filter axes, which is useful capability guidance, but it says nothing about when to reach for this tool over company_hiring or company_timeline, and gives no when-not conditions or prerequisites. Usage is implied rather than instructed.

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

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