Skip to main content
Glama

View Job Feed

get_starred_jobs
Read-only

Get job postings from the user's starred companies. This is the user's own curated feed. If the user has no stars, this returns nothing. In that case, use search_jobs instead: it reads the public catalogue. Supports filtering by search query, location, tech stack, remote policy, experience level, and minimum salary. Results are paginated. Same-title postings from one company are grouped into a single row: postingCount and postingLocations show how many raw postings it represents and where (boards often post one role per location). Use save_job to bookmark good matches so the user doesn't lose them.

SEARCH STRATEGY: For job recommendations, run multiple searches and merge results: first a broad search (no filters) to see what's available, then targeted searches by the user's technologies. This ensures comprehensive coverage. A single filtered query can miss good roles. The techStack filter uses OR logic: specifying ["React", "TypeScript", "Node.js"] returns jobs matching AT LEAST ONE of them (technologies are auto-normalized and matched across spelling variants), so filter by the technologies that genuinely matter and judge each job's fit from its own techStack field. Use searchQuery for role-based searches ("senior engineer", "frontend", "platform") and techStack for technology-based filtering.

OVER-CAP WARNING: if the response includes a "starsOverCap" field, the user has more starred companies than the limit allows and the surplus is scheduled for PERMANENT deletion on the given date. Proactively tell the user (count + date) and let them choose which companies to unstar down to the limit. NEVER unstar companies on the user's behalf just to get under the limit unless they explicitly ask you to.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, starting from 1
sortByNoSort field (default: createdAt)
pageSizeNoResults per page (max 50, default 20)
salaryMinNoMinimum salary filter
sortOrderNoSort direction (default: desc)
techStackNoFilter by technologies (e.g. ["React", "Node.js"])
searchQueryNoSearch keywords for job title, summary, or tech stack
remotePolicyNoFilter by remote policy: "remote", "hybrid", "onsite", or "remote-restricted"
locationQueryNoFilter by location or remote restrictions
techStackMatchNoHow techStack combines: "any" (default, at least one technology) or "all" (every technology required)
experienceLevelNoFilter by experience level: "junior", "mid", or "senior"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / locationQuery / maxLength
      Added value: +500
    • changedInput schema / properties / page / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / properties / pageSize / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / searchQuery / maxLength
      Added value: +500
    • addedInput schema / properties / techStack / items / maxLength
      Added value: +100
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already convey readOnlyHint=true and destructiveHint=false, so the bar for behavioral disclosure beyond annotations is lower. The description adds significant operational traits: pagination, grouping of identical postings with postingCount/Locations, and a critical over-cap warning that surplus stars lead to permanent deletion with instructions to proactively notify the user. This goes well beyond the annotations and provides essential context.

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 description is lengthy but well-structured with clear sections (main description, search strategy, over-cap warning) and front-loads the core purpose. Each part serves a purpose, though the search strategy block is verbose and could be condensed without losing value. It is not a tautology and is appropriately detailed for the tool's complexity.

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?

Given the tool's complexity (11 parameters, filtering, grouping, over-cap), the description covers the essential aspects: purpose, filtering semantics, pagination, grouping, and a safety warning. It doesn't fully describe the response object beyond postingCount and postingLocations, but without an output schema that is acceptable. There are no obvious gaps an agent would encounter when calling the tool correctly.

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 description coverage is 100%, so the schema already documents all parameters, giving a baseline of 3. The description adds valuable semantics: explains techStack uses OR logic with auto-normalization, differentiates searchQuery (role-based) from techStack (technology-based), and clarifies how grouping affects output via postingCount. This enriches parameter meaning beyond the schema.

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 explicitly states the tool retrieves job postings from starred companies, labels it as the user's curated feed, and contrasts it with search_jobs which reads the public catalogue. It also mentions grouping of same-title postings with postingCount and postingLocations, giving a precise picture of the tool's function and distinguishing it from siblings.

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 instructs when to use this tool vs. alternatives: if the user has no stars, use search_jobs. It also provides a detailed search strategy for job recommendations, advising broad searches first then targeted ones, and notes that a single filtered query can miss roles. Additionally, it suggests using save_job for bookmarking, offering clear routing and operational guidance.

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