Skip to main content
Glama

Star Company

star_listing

Star/save a company listing. Starring subscribes you to their job postings. Starred company jobs appear in get_starred_jobs. Starring also unlocks the company's FULL tech stack (unstarred listings only show a small preview). Starring is FREE. It does not consume budget. However, there is a limit on how many active stars you can have at once. Call get_account to check remaining star slots. CRITICAL: Only star companies where the user's tech stack genuinely overlaps with the company's tech stack. A React/Node developer should NOT star a company that only uses Go or Java. Irrelevant stars pollute the job feed with noise. Every star must be a deliberate, high-quality match. A company returned by a techStack-filtered search_listings call confirms the technologies in its matchedTechStack field (the filter checks the full stack, including the part hidden from the preview), so judge overlap by matchedTechStack, not the visible preview.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
listingIdYesThe ID of the listing to star

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only mark the tool as non-readonly, but the description reveals real behavioral consequences: it subscribes to job postings, unlocks the full tech stack, is free and does not consume budget, and has an active-star limit. The CRITICAL overlap rule adds substantial judgment context beyond what annotations could provide.

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?

The core action is front-loaded and every major section adds value: effects, cost, limit, and critical exclusion criteria. The description is somewhat verbose in its repeated emphasis on high-quality matches, but it remains organized and parsable.

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 single-parameter mutation with no output schema, the description covers the action, side effects, budget impact, limit-checking step, and decision criteria via matchedTechStack. It does not specify behavior on exceeding the star limit or on repeated starring, but it already directs the agent to prevent that by checking get_account.

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?

The schema already documents listingId as 'The ID of the listing to star' with 100% coverage, so the description adds no parameter-specific syntax or format details. The extra guidance is about selection policy, not about how to fill in the parameter.

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?

Opening with 'Star/save a company listing' names the exact verb and resource, and the next sentences give observable effects: subscribing to job postings, appearing in get_starred_jobs, and unlocking the full tech stack. This makes it easy for an agent to distinguish from siblings like unstar_listing or save_job.

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?

The description explicitly states when to use the tool ('Only star companies where the user's tech stack genuinely overlaps'), when not to use it ('should NOT star a company that only uses Go or Java'), and refers the agent to get_account for checking remaining star slots. It even tells the agent to judge overlap using matchedTechStack from search_listings, leaving no ambiguity.

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