Skip to main content
Glama
vinayvobbili

jobwatch

by vinayvobbili
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_company

Read-onlyIdempotent

Look up a company by name to see all tracked jobs by status, contacts, and watchlist details when you don’t know which application stage it’s at.

Instructions

Everything tracked at one company, whatever the status of its jobs (new, queued, applied, screening, interviewing, offer, rejected, withdrawn, skipped) and open or closed. company, counts (jobs by status), and jobs: each with key, title, status, posted, applied_at, closed, next_step, follow_up, due, note, package (what was saved: files, answers, note) and duplicate_of (see get_job); contacts: people the user knows there, with find_referral, a LinkedIn search for someone who could introduce them; watch: whether the company's board is on the watchlist and, when it isn't, add_board (the entry and name to pass add_board) and command. Closed postings never acted on are only counted (closed_unacted), so are open ones not acted on that the filters leave out (left_out, with left_out_by: filter -> count) unless every_role, and the other open ones not acted on are listed up to 25 (more_open). also names other companies the name matched. Returns an error when none matches. Use it when the person names a company and you don't know which stage it's at; for one job's full text, fit and prep use get_job, for every application list_applications, and for all jobs of one status list_jobs.

Input Schema

NameRequiredDescriptionDefault
nameYesA company's name ("Acme Robotics"), part of it ("acme"), or its domain ("acme.com"); case, punctuation and suffixes such as Inc don't matter.
every_roleNoAlso list the open roles the filters leave out (other cities, low pay...). Default: the watchlist's display.company setting (matches: only the roles Today's filters pass).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • addedInput schema / properties / every_role
      Added value: +{
+  "default": false,
+  "description": "Also list the open roles the filters leave out (other cities, low pay...). Default: the watchlist's display.company setting (matches: only the roles Today's filters pass).",
+  "title": "Every Role",
+  "type": "boolean"
+}
  2. Addedv0.5.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantive behavior beyond them: an error when nothing matches, name-matching against other companies, a 25-item cap with a more_open remainder, closed_unacted counting, and left_out_by filter attribution. These are exactly the edge cases an agent must anticipate before calling.

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?

Purpose and routing are front-loaded in the first clause and the closing sentence, and nearly every fragment carries information. However, the middle is a dense telegraphic run-on ('left_out, with left_out_by: filter -> count', 'watch: ... and command') that is harder to parse than it needs to be.

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?

With no output schema and no nested objects, the description carries the full burden of explaining return shape and does so field by field (counts, jobs fields, contacts, watch/add_board, truncation buckets). Nothing an agent needs to call and interpret this tool is missing.

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 the schema already documents name and every_role. The description reinforces every_role's consequence (left_out/left_out_by appear unless every_role) but adds no syntax or format detail beyond the schema — the baseline 3 applies.

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?

Names a specific resource and scope: 'Everything tracked at one company' across all job statuses and open/closed, then enumerates the returned sections (counts, jobs, contacts, watch). It explicitly distinguishes itself from get_job, list_applications and list_jobs, so an agent can route correctly without opening a 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?

Gives an explicit trigger ('when the person names a company and you don't know which stage it's at') plus three named alternatives with their selecting conditions (get_job for one job's full text/fit/prep, list_applications for every application, list_jobs for one status). No inference is required.

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

Deploy Server

Other Tools