Job platform for AI agents. Track tech jobs from companies that match your stack.
Scored across 24 tools
Each tool targets a distinct resource and action: searches, saved jobs, starred companies, profile sections, and linktrees are clearly separated. The overlapping job-discovery tools (get_feed, get_starred_jobs, get_saved_jobs, get_digests) are explicitly differentiated by source and purpose in their descriptions.
Tool names consistently follow a verb_noun pattern in snake_case (get_profile, save_job, star_listing, update_saved_job_note). Actions are symmetric (save_job/unsave_job, star_listing/unstar_listing, create_linktree/delete_linktree), and minor plural variations do not create confusion.
24 tools is on the heavy side, at the upper edge of the borderline-heavy band. The broad domain (jobs, companies, profile, linktrees, account limits) mostly justifies the count, but deprecated get_digests and peripheral get_apps add bloat.
Core workflows are covered: profile CRUD, job search/save/apply, company search/stars, and linktrees. Notable gaps exist though: there is no way to list or manage applications after apply_to_job, and linktrees have create/get/delete but no update operation.
Apply to a job on behalf of the user, or get its application link. Two outcomes by job type: internal jobs (posted directly through Remoet's partner system) are applied to end-to-end and return the created application; scraped jobs (most of the platform) return applicationType "external" with the applicationUrl where the user applies on the company's site. Share that link with the user; Remoet cannot submit external applications for them.
IMPORTANT: Before applying, confirm with the user that they want to apply. Review the job details (use search_jobs, get_starred_jobs, or get_listing) and cross-reference against the user's profile. Flag any gaps between the job requirements and the user's skills, e.g. "This role asks for Go experience which isn't on your profile. Still want to apply?" This helps the user make informed decisions and avoids wasting applications. Do NOT apply to jobs without the user's explicit consent.
Internal jobs must be published and not expired, and the user can only apply once per job: duplicate applications are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The ID of the job to apply to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly=false and idempotent=false, and the description substantially expands on this by explaining the two behavioral paths: internal jobs are applied end-to-end, while scraped jobs merely return an external URL and cannot be submitted by Remoet. It also discloses that duplicate applications are rejected, which is important side-effecting behavior beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose, then clearly separates behavior by job type, and ends with explicit safety constraints. It is long because the tool carries significant side effects and user-consent obligations, but every sentence adds necessary guidance and no content is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one simple parameter, no output schema, and a high-stakes side-effecting action, the description fully covers what the agent needs: input requirements, outcome differences, user-consent protocol, and failure conditions. Nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single jobId parameter is already described as 'The ID of the job to apply to.' The description adds no additional parameter-level meaning, such as how to obtain the ID or any format caveats, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Apply to a job on behalf of the user, or get its application link.' It clearly distinguishes between internal and scraped job outcomes, which separates this tool from other job-related siblings like save_job or search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: confirm with the user before applying, review the job via search_jobs/get_starred_jobs/get_listing, cross-reference against the user's profile, flag skill gaps, and never apply without explicit consent. It also states constraints for internal jobs (must be published, not expired, no duplicates), giving clear when-to-use and when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a link tree page: a shareable page with the user's links (social media, portfolio, GitHub, etc.). Each account can create up to 10. The slug becomes the public URL. Slug rules: 5-20 characters, lowercase letters, numbers, and hyphens only, cannot start/end with a hyphen. Must be unique. Use the user's name or handle as a base for the slug. Pull links from the user's profile (get_profile): githubUrl, linkedinUrl, twitterUrl, url, etc.
TIP: Suggest the user adds their link tree URL to their CV or job applications. Remoet tracks views and link clicks, so they can see if a recruiter has opened it.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | URL slug (5-20 chars, lowercase, hyphens allowed, must be unique) | |
| links | Yes | Array of links to display on the page (max 50) | |
| title | Yes | Page title (e.g. "Carl Igelström: Links") | |
| description | Yes | Short description for the page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only signal a non-read-only, non-idempotent write. The description adds meaningful behavioral constraints beyond that: the per-account limit of 10, slug uniqueness, and the tracking of views/clicks. These are not present in annotations and help the agent understand side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by constraints and parameter guidance, and ends with a tip about CV usage and tracking. It is slightly long but every sentence carries useful information; the tip adds user-facing value without bloating the core invocation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential domain rules: limit of 10, slug pattern and uniqueness, link sources, and the resulting public URL. It does not describe the response payload or error handling, but no output schema exists and the agent can infer basic behavior. Overall it is sufficiently complete for a correct creation request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds extra value by detailing slug rules (numbers, no leading/trailing hyphens) and explicitly suggesting profile fields (githubUrl, linkedinUrl, twitterUrl, url) for the links array, which is not fully captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a link tree page' with a clear purpose ('a shareable page with the user's links'). It distinguishes from siblings like delete_linktree and get_linktrees by explicitly naming the creation action and the resulting artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to create a link tree, including the account limit and slug rules. It also instructs the agent to pull links from get_profile, which guides parameter preparation. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a link tree page. Use get_linktrees to find the ID first. Confirm with the user before deleting.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the link tree to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false; description adds behavioral context about needing user confirmation and prerequisite lookup, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, each serving a distinct purpose: stating the action and providing prerequisites/cautions. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with no output schema, the description provides sufficient context: what to do, how to prepare, and user confirmation needed. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with description for the 'id' parameter. Description does not add further meaning beyond what schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('delete') and resource ('link tree page'), and distinguishes from siblings by instructing to use get_linktrees to find the ID first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides context: use get_linktrees to find the ID and confirm with the user before deleting, which is essential for a destructive operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a profile item: a work experience entry, a project, or an education entry (set type accordingly). Use this to clean up duplicates, placeholder/test entries, or clearly wrong data. Get the id from get_profile. Always confirm with the user before deleting anything that could be real.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the item to delete (get its id from get_profile) | |
| type | Yes | Which kind of profile item to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context by specifying what kinds of items are deleted and requiring user confirmation before deleting potentially real data. It aligns with the annotations and adds the confirmation policy beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: first defines the operation and scope, second gives the use cases, third provides the prerequisite and confirmation requirement. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation with destructiveHint and idempotentHint already in annotations, the description covers what is deleted, when to use it, where to get the id, and the confirmation policy. No critical guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both id and type already documented in the schema. The description repeats the type options and id source but does not add meaning beyond the schema. This matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete'), names the resource ('profile item'), and enumerates the exact types it applies to: work experience, project, education. It clearly distinguishes itself from siblings like delete_linktree by scoping to profile items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: 'clean up duplicates, placeholder/test entries, or clearly wrong data.' It also provides a prerequisite ('Get the id from get_profile') and a safety rule ('Always confirm with the user before deleting anything that could be real'). It lacks explicit when-not-to-use or named alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user's account status in one call: every budget the platform enforces (active stars vs cap, unstars used vs the 30-day unstar budget, MCP requests today vs daily cap, REST API requests today vs daily cap, each with a resetsAt), the remaining limits (link-tree cap), and any over-cap/grace state.
Calling this is free and never counts against a cap, so check eagerly: when the user asks "how close am I to my limit?" or "when does X reset?", when a limit is hit (to show them where they stand), or before firing several write tools in a row so you can pace. Every limit is a plain number.
Remoet is free. There is nothing to upgrade to and nothing to sell: if the user is at a limit, help them work within it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, but the description adds important context: the call is free, never counts against a cap, and every limit is a plain number. It also explicitly states there is nothing to upgrade or sell, which helps the agent set expectations with the user. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet comprehensive. It front-loads the core purpose, then gives usage guidance, and ends with a note about Remoet's free nature. Each sentence serves a purpose—no fluff. The structure is logical: what, when, and what to expect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with no output schema, the description is remarkably complete. It explains what data is returned (budgets, resetsAt, limits, over-cap/grace state), when to use it, and the cost/free aspect. An agent has everything needed to call it correctly and interpret its result without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter details because there are none. It does describe the content of the response (budgets, resetsAt, limits), which indirectly helps the agent understand what the tool returns, though no output schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: retrieves the user's account status including budget limits, remaining limits, and over-cap/grace state. It distinguishes itself from sibling get_* tools by focusing specifically on account-level budget and limit information, not on data like apps, digests, or profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'check eagerly' when the user asks about limits or resets, when a limit is hit, and before firing several write tools to pace. It also clarifies the tool is free and never counts against a cap, so agents can call it without hesitation. This leaves no ambiguity about appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List approved apps built on the Remoet platform. These are community and official apps that extend Remoet's functionality. Each app has a repo URL for deployment and a demo URL to try it out. Use this to help users discover tools that complement their Remoet workflow, e.g. portfolio sites, CV generators, job trackers, etc. You can filter by category or tag.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag | |
| page | No | Page number, starting from 1 (default: 1) | |
| category | No | Filter by category | |
| pageSize | No | Results per page, max 50 (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. It adds meaningful context about app contents (repo URL, demo URL, categories/tags) but does not disclose any deeper behavior such as pagination limits or response shape, which are left to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three informative sentences with no wasted words. The core action and resource are front-loaded, followed by concrete use cases and filtering capabilities. Every sentence contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with all parameters self-documented in the schema and annotations covering safety, the description is complete. No output schema exists, so explaining the return format is not required, and the description gives enough context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description only restates that filtering by category or tag is possible; it does not add meaning beyond the schema's own parameter descriptions. This is acceptable but not a value-add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List approved apps built on the Remoet platform') and clarifies what these apps are and what they do. This clearly distinguishes get_apps from the job/listing/linktree siblings by focusing on curated Remoet platform extensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear intended usage scenario: 'Use this to help users discover tools that complement their Remoet workflow' with concrete examples. It does not explicitly name alternatives or state when not to use this tool, but the context is strong enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HISTORICAL ONLY: the user's archived job digests, the email summaries Remoet used to send about new jobs from their starred companies. No new digest has been generated since 2026-07-06, when the feed roundup replaced that pipeline, so this returns nothing at all for an account created since then. What carries new roles now is get_feed (the composed dashboard stream, and what the roundup emails are built from); for searching, use get_starred_jobs or search_jobs. Reach for this tool only when the user asks about their old email summaries by name. Without an id: the 20 most recent as lightweight summaries (id, title, frequency, jobCount, createdAt). With an id: that digest's full markdown body (each job's title, application URL, salary, remote policy, experience level, tech stack).
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Fetch one digest in full by id. Omit to list recent digests. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds crucial behavioral context: the 2026-07-06 cutoff, that new accounts get nothing, and the difference between the list view (lightweight summaries) and detail view (full markdown body). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose (around 200 words) but front-loaded with 'HISTORICAL ONLY' and each sentence contributes meaningful information: alternatives, cutoff date, return formats. No filler, though it could be trimmed slightly without losing substance. Structure is logical – purpose, usage, behavior, parameter modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with one optional parameter and no output schema, the description is exhaustive. It covers when to use, what it returns (both list and detail), the historical limitation, and the migration to get_feed. An agent can call this tool correctly with no further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the id parameter already has a description). The tool description adds context by explaining the dual behavior (omit id vs. provide id) in the context of historical data, but it mostly reiterates what the schema states. Still, the clarification of what each mode returns is valuable beyond the schema's one-liner.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('get digests') and clarifies its scope as 'HISTORICAL ONLY' – archived email summaries. It distinguishes itself from siblings like get_feed, get_starred_jobs, and search_jobs by name and purpose, leaving no ambiguity about what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it: 'Reach for this tool only when the user asks about their old email summaries by name.' It also names the alternatives (get_feed, get_starred_jobs, search_jobs) and the conditions that select them, making the decision tree fully transparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user's dashboard feed as ONE composed stream, chronological newest first. Each entry has a kind: 'item' (per-company job items from their starred companies - the company, when it landed, role snapshots with job id/title/application URL/salary/remote policy/experience level/tech stack, and per-role flags isActive, savedJobId, matchesFilters, plus per-item isStarred: false means the user unstarred that company since), 'job_of_the_day' (one daily editorial pick from anywhere on the platform - a discovery candidate worth surfacing), 'blog' and 'broadcast' (platform content; usually skim). Poll this on the user's schedule to act as their notification layer: check what landed, save interesting roles via save_job, brief the user. Pass nextCursor back to page deeper; omit it for the newest page.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | nextCursor from the previous page. Omit for the newest page. | |
| pageSize | No | Items per page (default 20, max 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description correctly aligns with that. It adds behavioral context by explaining the composed stream includes per-company job items with flags like isStarred meaning the user unstarred a company since, and that 'job_of_the_day' is a discovery candidate. It also mentions entries are chronological newest first, which is useful. The only minor gap is not detailing the exact return schema or error behavior, but annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but not overly long; it front-loads the key purpose and composition, then provides usage guidance. It could be slightly more concise, but every sentence adds value, explaining entry kinds and usage. It's well-structured for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple entry kinds, flags, and pagination), the description is thorough. It covers the composition of the feed, the meaning of key fields, and how to use pagination. With annotations covering safety and no output schema needed, the description is complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds meaning by explicitly stating 'Pass nextCursor back to page deeper; omit it for the newest page' and mentioning pageSize default and max, reinforcing the schema. However, the description doesn't add much beyond that, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('View') and resource ('dashboard feed'), and distinguishes it from siblings by describing it as a composed stream with specific entry kinds. It clearly explains the feed's purpose as a notification layer, which differentiates it from other get_* tools like get_digests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it says to poll on the user's schedule, to act as a notification layer, to save interesting roles via save_job, and to brief the user. It also explains how to use the cursor parameter for pagination, and mentions that blog and broadcast entries are 'usually skim' implying when to skip them. This is explicit and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user's link tree pages: shareable single-page URLs for a CV, email signature, or job application, with per-link view/click tracking so recruiter engagement is measurable. Without a slug: all of the user's link trees (each with its id and slug). With a slug: that page's content plus its engagement data (views, clicks per link), which answers "has anyone looked at my link tree?". If the user has none, suggest creating one via create_linktree pulling their profile links.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Fetch one link tree in full by its public slug (with engagement data). Omit to list all of the user's link trees. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: listing returns ids and slugs, fetching with a slug returns page content plus per-link views and clicks, and engagement tracking is measurable. This is more than the annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it defines the concept, explains both invocation modes, and gives an actionable fallback to create_linktree. The key behavioral distinction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining return behavior. It does so clearly for both the list and single-slug cases, and even includes the engagement data that answers the user's likely question. No critical calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the slug parameter well, so the baseline is 3. The description adds meaning beyond the schema by clarifying that omitting the slug returns all link trees and that supplying it returns engagement data such as views and clicks per link.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: viewing the user's link tree pages. It distinguishes the two modes (list all without a slug, fetch one with a slug) and names the sibling create_linktree for the creation flow, so an agent can tell it apart from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains when to omit or supply the slug and gives a concrete use case ('has anyone looked at my link tree?'). It also routes to create_linktree when the user has no link trees, which is explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works without a Remoet account. Get detailed information about a specific company listing by its slug. Use this to review a company before deciding whether to star it. Returns the company's full description, perks, job count, and URLs. NOTE: the tech stack is a small preview unless the company is starred. Starring unlocks the full stack (techStackCount shows the true total, e.g. a 3-tag preview of 147). Pass checkTechStack with the user's technologies to verify overlap against the FULL stack. Matched ones come back in matchedTechStack and lead the preview, same contract as search_listings. Pair with get_account to check budget before starring.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The URL slug of the listing (e.g. "digital-ocean", "stripe") | |
| checkTechStack | No | Technologies to verify against the company's full stack (auto-normalized, max 50); matches are returned in matchedTechStack |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description adds substantial behavioral context: unstarred companies show only a preview stack, starring unlocks the full stack, techStackCount reflects the true total, and checkTechStack verifies against the full stack. This goes well beyond the annotations and helps the agent understand preview versus full data semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, account requirement, return contents, tech-stack preview caveat, parameter behavior, and a pairing recommendation. It is front-loaded with the main purpose and the key exception, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, two-parameter tool with no output schema, the description covers the returned data, the preview/full-stack distinction, the matchedTechStack contract, and the recommended pairing with get_account. Nothing an agent needs to call this tool correctly or interpret its result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters at 100% coverage, but the description adds meaningful semantics: slug maps to a single company, and checkTechStack is explained as verifying overlap against the FULL stack with matched results returned in matchedTechStack. The concrete '3-tag preview of 147' example makes the parameter's effect tangible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Get detailed information about a specific company listing by its slug') and the resource, and ties it to a clear use case ('review a company before deciding whether to star it'). This distinguishes it from list/search siblings by emphasizing the single-listing slug-based operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: works without an account, use before starring, and 'Pair with get_account to check budget before starring.' It does not explicitly name an alternative like search_listings as the tool to use for browsing many listings, but 'specific company listing by its slug' strongly implies the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user's complete Remoet profile in one call: profile core (summary, links, location, avatar), workExperience, projects, and education (each section entry carries an id for update/delete) plus the current visibility setting. Always read this before changing anything.
After reading, run a quick gap analysis and offer to fix what you find, ranked by impact (be encouraging, not critical):
SUMMARY (highest impact, the first thing companies read): flag if empty, under ~100 chars, or missing tech stack / years of experience / a differentiator. See update_profile for the pattern.
VISIBILITY: if NONE, suggest STARRED via update_profile so companies the user has starred can discover them.
PROJECTS (#1 gap for junior/mid devs): flag zero projects (ask about side projects, OSS, hackathons, scripts, blogs), or projects missing a URL, description, or technologies.
WORK HISTORY: flag missing descriptions, empty technologies arrays (they feed job matching), or descriptions without measurable impact ("Built React frontend" -> "...serving 50K users, 40% faster").
BASICS: flag a missing avatar, a vague location (needs city + country for timezone/jurisdiction), or missing GitHub/LinkedIn.
EDUCATION: flag if empty (degrees, bootcamps, notable certifications).
If the user shares a CV, resume, or website, populate the whole profile (update_profile, save_work_experience, save_project, save_education), then search companies by their stack, surface jobs with search_jobs, and suggest stars for the genuine fits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false; the description adds meaningful context beyond that: the call returns per-entry IDs intended for later update/delete, includes current visibility, and is safe to run as a first step. The description's guidance about subsequent writes aligns with the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: core purpose is front-loaded, the gap analysis is bulleted by area, and the CV workflow is clearly separated. Every section earns its place, though the length is near the upper bound and some workflow directives could arguably live outside the tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains the returned structure (sections, ids, visibility) and also covers downstream actions and alternative tools. An agent has everything needed to call the tool, interpret its result, and decide on follow-up steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the parameter documentation burden is absent. The description appropriately focuses on the return payload rather than inputs, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns the user's complete Remoet profile in one call, listing exact sections (profile core, workExperience, projects, education) and the visibility setting. This clearly distinguishes it from siblings like get_account or get_listing by specifying the full profile scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs 'Always read this before changing anything', establishing when to use this tool relative to mutation tools. It then maps common profile gaps to specific alternatives (update_profile, save_project, save_education, etc.) and describes the CV/resume workflow using search_jobs, making the tool's role in the pipeline unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the user's saved jobs list. This is the user's job search memory: shows all jobs they've bookmarked across sessions, with notes and job details. Includes both AI-extracted jobs and internal partner jobs (see jobType field). IMPORTANT: Always call this before get_starred_jobs or search_jobs when helping with job search. It shows the user's existing pipeline so you can avoid re-recommending jobs they've already saved or dismissed. Paginated, newest saves first. Each saved job includes isActive and deactivatedAt fields. If isActive is false, the job is no longer appearing on the company's careers page. This usually means it was filled or expired, but could also be a temporary scraper issue (there is a grace period before deactivation). A saved job the user can no longer see (its company is no longer starred, or a partner role was unpublished) keeps its entry but comes back with job: null, locked: true and a lockedReason to pass on. If job is null without locked, the listing was deleted entirely. Suggest the user check the company's careers page directly if a saved job they care about gets deactivated.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting from 1 (default: 1) | |
| pageSize | No | Results per page, max 50 (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the description must carry behavioral detail. It delivers substantial context: pagination and ordering, isActive/deactivatedAt semantics, the job:null/locked/lockedReason scenarios, and even advice to check the company's careers page on deactivation. None of this contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the core purpose and the critical usage directive. The later edge-case explanations (isActive, locked, job:null) are essential because there is no output schema, and each paragraph earns its place. It is not maximally concise, but it is well organized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only optional pagination parameters and no output schema, so the description must explain the return experience. It covers the job list contents, notes, jobType, pagination, order, active/deactivated fields, locked/nulled entries, and practical follow-up guidance. An agent has enough context to call the tool correctly and interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both page and pageSize have clear descriptions and bounds. The tool description adds only that results are 'paginated, newest saves first,' which is context the schema does not provide, but it does not need to restate parameter syntax. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the user's saved jobs list') and clearly distinguishes it from sibling tools by calling it the user's 'job search memory' and 'bookmarked across sessions.' It explicitly contrasts itself with get_starred_jobs and search_jobs, so an agent knows exactly which tool this is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit directive: 'IMPORTANT: Always call this before get_starred_jobs or search_jobs when helping with job search.' It explains why (to avoid re-recommending jobs already saved or dismissed), giving a clear selection rule among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting from 1 | |
| sortBy | No | Sort field (default: createdAt) | |
| pageSize | No | Results per page (max 50, default 20) | |
| salaryMin | No | Minimum salary filter | |
| sortOrder | No | Sort direction (default: desc) | |
| techStack | No | Filter by technologies (e.g. ["React", "Node.js"]) | |
| searchQuery | No | Search keywords for job title, summary, or tech stack | |
| remotePolicy | No | Filter by remote policy: "remote", "hybrid", "onsite", or "remote-restricted" | |
| locationQuery | No | Filter by location or remote restrictions | |
| techStackMatch | No | How techStack combines: "any" (default, at least one technology) or "all" (every technology required) | |
| experienceLevel | No | Filter by experience level: "junior", "mid", or "senior" |
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.
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.
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.
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.
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.
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.
Add or update an education entry (upsert). Omit id to create (institution is required); pass an id (from get_profile) to update, changing only the fields you send. Ask about degrees, bootcamps, and notable certifications. Confirm approximate dates with the user rather than guessing; don't fabricate. Check get_profile first to avoid duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Present: update this education entry (only the fields you pass change). Omit: create a new one (institution is required to create). | |
| endDate | No | End date: a date, e.g. "2024-01-15" | |
| isCurrent | No | Whether you are currently studying here (default false on create) | |
| startDate | No | Start date: a date, e.g. "2024-01-15" | |
| studyLevel | No | Level of study: HIGH_SCHOOL, ASSOCIATE, BACHELOR, MASTER, DOCTORATE, BOOTCAMP, or OTHER | |
| description | No | Description of studies, achievements, etc. | |
| institution | No | Institution name (e.g. "MIT", "Lund University") | |
| fieldOfStudy | No | Field of study (e.g. "Computer Science") | |
| institutionUrl | No | Institution website URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the full burden. It discloses that updates only change sent fields, that institution is required on create, and advises confirming dates and not fabricating—useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: the core upsert concept comes first, then conditional logic, then conversational guidance, then a pre-check. Every sentence earns its place with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no output schema, it covers the essential behaviors (create/update), conditional requirements, and user-interaction guidance. Missing minor details like return value, but not necessary given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 9 parameters have descriptions), so the baseline is 3. The description adds extra semantics for the id parameter (present vs omit meaning) and the conditional requirement on institution for creation, going beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Add or update an education entry (upsert)') and clearly distinguishes the two modes (create vs update) based on id presence. The resource is unambiguous, making it easy to tell apart from siblings like save_work_experience even though it doesn't name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to create (omit id) vs update (pass id from get_profile), and instructs to check get_profile first to avoid duplicates. It doesn't explicitly contrast with sibling tools, but the resource-specific nature makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a job to the user's list for later. Supports both AI-extracted jobs (from search_jobs or get_starred_jobs) and internal partner jobs. This gives the agent memory across sessions. Saved jobs persist so the user doesn't lose track of interesting roles. Optionally attach a note (e.g. "Great fit for React skills", "Follow up next week"). Each job can only be saved once.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional note about why this job is interesting | |
| jobId | Yes | The ID of the job to save | |
| jobType | No | Type of job: "ai_job" (from search_jobs or get_starred_jobs, default) or "listing_job" (internal partner job) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no helpful annotations, the description carries the behavioral burden. It discloses that saves persist across sessions and that each job can only be saved once. It stops short of specifying duplicate-save error behavior, but the key persistence and uniqueness traits are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and is appropriately compact. Minor redundancy exists between 'agent memory across sessions' and 'saved jobs persist,' but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with a fully documented schema and no output schema, the description covers purpose, persistence, note usage, and the uniqueness constraint. The only notable omission is explicit behavior on duplicate saves, but the constraint itself is disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds meaningful context by mapping jobType to AI-extracted jobs vs internal partner jobs and giving practical note examples, going beyond the bare enum labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Save a job to the user's list for later.' It also differentiates the job types it supports and distinguishes itself from sibling save tools like save_education or save_project by naming the exact resource and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use it: when the user wants to keep track of interesting roles and across sessions. It does not explicitly name exclusions or alternatives like apply_to_job or unsave_job, but the intended use case is well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update a portfolio project (upsert). Omit id to create (title and shortDescription are required); pass an id (from get_profile) to update, changing only the fields you send. Projects are the #1 differentiator for junior/mid developers. Help the user recognize work they might not think of: side projects, open-source contributions, hackathon entries, internal tools, time-saving scripts, blogs, personal apps. Check get_profile first to avoid duplicates; don't fabricate or embellish.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Present: update this project (only the fields you pass change). Omit: create a new one (title and shortDescription are required to create). | |
| role | No | Your role in the project | |
| title | No | Project title | |
| demoUrl | No | Live demo URL | |
| endDate | No | End date: a date, e.g. "2024-01-15" | |
| repoUrl | No | Repository URL | |
| isRemote | No | Whether this was remote work (default false on create) | |
| isCurrent | No | Whether this is an ongoing project (default false on create) | |
| startDate | No | Start date: a date, e.g. "2024-01-15" | |
| description | No | Full project description | |
| isOpenSource | No | Whether this is open source (default false on create) | |
| technologies | No | Technologies used | |
| shortDescription | No | A one-line summary of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false, so the safety profile is known. The description adds meaningful behavioral context: upsert semantics, partial-update behavior ('changing only the fields you send'), and creation requirements. It doesn't describe return values, but with no output schema and annotations covering the safety profile, the added context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core upsert behavior, then moves to usage guidance. The list of project types is slightly long but earns its place by helping the agent identify what to save. No redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no output schema, the description covers the key decision (create vs update), prerequisites (get_profile), and content guidance. It doesn't explain what happens after saving (e.g., confirmation, return value), but the absence of an output schema and the presence of rich parameter descriptions make this acceptable. The guidance about avoiding duplicates and not fabricating content is particularly valuable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 13 parameters. The description adds semantic value by explaining the id parameter's dual role (create vs update) and the required fields for creation, which is not fully captured in the schema's per-parameter descriptions. It also adds guidance on what kinds of projects to include, which helps the agent populate fields meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Add or update a portfolio project (upsert)') and immediately distinguishes the two modes (create vs update) with explicit field requirements. It also names the sibling tool get_profile as the source for the id, which differentiates it from other save_* siblings like save_education and save_work_experience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Check get_profile first to avoid duplicates' and 'Help the user recognize work they might not think of' with concrete examples. It also states what not to do ('don't fabricate or embellish'). This is strong usage guidance beyond just a definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update a work experience entry (upsert). Omit id to create a new entry (title and startDate are required); pass an id (from get_profile) to update an existing one, changing only the fields you send. Every description should cover WHAT was built, HOW (technologies), IMPACT (users served, performance gains, revenue, uptime), and SCOPE (team size, scale). Push for measurable outcomes ("Built React frontend" -> "...serving 50K users, 40% faster"). Always populate technologies; they feed job matching. Check get_profile first to avoid duplicates, and don't fabricate. Ask the user to confirm vague dates or fill real gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Present: update this work-experience entry (only the fields you pass change). Omit: create a new one (title and startDate are required to create). | |
| title | No | Job title | |
| endDate | No | End date: a date, e.g. "2024-01-15". Omit it for a current role | |
| isRemote | No | Whether this job is remote (default false on create) | |
| isCurrent | No | Whether this is your current job (default false on create) | |
| startDate | No | Start date: a date, e.g. "2024-01-15" | |
| companyUrl | No | Company website URL | |
| companyName | No | Company name | |
| description | No | Job description | |
| technologies | No | Technologies used (e.g. ["React", "Node.js"]). They feed job matching |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false, which is consistent with 'Add or update'. The description adds valuable behavioral context: it demands measurable outcomes in descriptions ('Built React frontend' -> '...serving 50K users'), instructs not to fabricate, and mandates always populating technologies for job matching. These are behavioral traits not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 200 words, which is a bit long, but every sentence earns its place. It front-loads the core operation and then adds essential usage rules and content guidelines. No fluff, though it could be tightened slightly by moving content-quality guidance into a separate section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no output schema, and annotations that only cover read/write flags, this description is remarkably complete. It covers the upsert behavior, required fields for create, the duplicate-avoidance strategy (check get_profile), and content quality expectations. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra semantics for the id parameter (create vs update behavior) and for description (content requirements) and technologies (feed job matching). It does not add extra explanation for every parameter (e.g., isRemote, companyUrl), but the schema already explains those. The added value pushes it to a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Add or update a work experience entry (upsert)', giving a clear verb and resource. It distinguishes itself from siblings like save_education and save_project by naming the specific resource (work experience) and the operation (upsert). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to create (omit id) vs update (pass id from get_profile), and instructs to 'Check get_profile first to avoid duplicates'. It also tells the agent to ask the user to confirm vague dates, which is a clear usage rule. This goes beyond a basic description by giving actionable when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works without a Remoet account. Search Remoet's PUBLIC job catalogue: every role on the open board at remoet.dev/jobs, across all companies, not just the ones the user has starred. No star is needed and none is consumed. Use this to answer "what is out there" for any technology, title or company; use get_starred_jobs instead for the user's own curated feed.
Each result carries the role's public Remoet URL, which is a real page anyone can open, plus applyUrl (the employer's own posting, where an application actually happens) and companySlug (the same slug get_listing takes, for company detail). Roles that Remoet is not permitted to publish never appear here.
Duplicate postings of one role at a company are collapsed into a single result, so totalCount is the number of distinct roles, not raw postings. duplicateCount is how many postings collapsed into it; boards usually duplicate a role per location, but nothing guarantees that, so do NOT report it as a number of locations. firstSeenAt is when Remoet first saw the role, not when the employer posted it, and lastVerifiedAt is the last time Remoet confirmed it was still open.
Filters are searchQuery (title, Remoet summary and tech stack), techStack (ANY of the given technologies, or EVERY one under techStackMatch: "all", which is how you express a must-have stack), companySlug, location, remotePolicy, experienceLevel and salaryMin. A salaryMin floor drops every role Remoet holds no numeric salary for, which is roughly 45% of the board, so use it when salary is a hard requirement and leave it off otherwise. location matches the canonical places Remoet stores per role rather than the free-text location string, so a country also finds roles that name only one of its cities; searchQuery does NOT read location, so filter by place with location and not by typing the place into searchQuery.
When a search returns nothing, the hint says which filter emptied it and how many roles dropping that one filter would return, so act on the hint rather than guessing at which filter to relax. Results are newest-first unless you ask otherwise: sortBy takes "newest" or "salary", with sortOrder asc or desc. Start broad and narrow: a single heavily filtered query misses good roles. Use save_job to bookmark anything worth keeping.
Example: search_jobs({ searchQuery: "platform engineer", techStack: ["Go", "Kubernetes"], location: ["Berlin"], remotePolicy: ["remote"] }).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting from 1 (default: 1). Without a Remoet account the first 10 pages are available; connect an account to page deeper. | |
| sortBy | No | Sort field: "newest" (default) or "salary". Under "salary", roles with no known salary sort LAST whichever direction is asked for, so they never head the list. | |
| location | No | Match roles in ANY of these places (max 5), e.g. ["Berlin"] or ["Germany", "Netherlands"]. Matched against the canonical place names Remoet stores per role, not the free-text location string, so a country ALSO matches roles that only name one of its cities. City or country name, url slug ("san-francisco") and common alias ("NYC", "UK") all resolve. A place Remoet does not know returns no roles and says so, rather than quietly returning everything. Note that under a location filter a role's duplicateCount, firstSeenAt and the particular posting shown (its id, applyUrl and location) describe only that role's postings IN THOSE PLACES, so they can differ from the same role returned without one. | |
| pageSize | No | Results per page, max 20 without a Remoet account (default: 20) | |
| salaryMin | No | Minimum salary, against the role's normalized salaryEnriched.from. Roles Remoet holds no numeric salary for are EXCLUDED by this filter, so a floor narrows the board to the ~55% of roles that publish one. | |
| sortOrder | No | Sort direction (default: desc) | |
| techStack | No | Match roles carrying ANY of these technologies (e.g. ["React", "Go"]), or EVERY one of them under techStackMatch: "all". Matched case-insensitively against the exact stored technology, so use whole names rather than fragments. Known spelling variants are expanded, so "Go" also finds roles tagged "Golang". | |
| companySlug | No | Restrict to one company by its Remoet slug (the same slug get_listing takes, e.g. "stripe"). An unknown or delisted company returns an empty page, not an error. | |
| searchQuery | No | Free text, matched against the job title, Remoet's own summary of the role and its tech stack. Comma-separate keywords to require ALL of them (e.g. "react, typescript"). | |
| remotePolicy | No | Match roles with ANY of these remote policies: "remote", "hybrid", "onsite" or "remote-restricted" (max 5). | |
| techStackMatch | No | How techStack combines: "any" (default, at least one technology) or "all" (every technology required ON THE SAME ROLE; use for a must-have stack). Spelling variants stay grouped per technology, so "all" with ["Go", "React"] means a Go-or-Golang role that is ALSO a React role, never a Golang-or-React one. Under "all" at most 20 distinct technologies may be required in one search: more than that returns NO roles rather than a search quietly trimmed to 20, so send the ones that genuinely matter. | |
| experienceLevel | No | Match roles at ANY of these experience levels: "junior", "mid" or "senior" (max 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description goes far beyond this, disclosing critical behaviors: 'Works without a Remoet account', 'No star is needed and none is consumed', 'Roles that Remoet is not permitted to publish never appear here', duplicate collapsing semantics ('totalCount is the number of distinct roles, not raw postings'), and temporal nuances ('firstSeenAt is when Remoet first saw the role, not when the employer posted it'). It also explains the empty-result hint behavior. All of this is essential behavioral context that annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized into logical paragraphs: intent, result semantics, filter explanations, and an example. Every sentence adds necessary information for correct use of a 12-parameter tool; there is no fluff. The opening sentence immediately establishes purpose, and the example at the end anchors the explanation. While it is not brief, the length is justified by the tool's complexity, and the structure supports comprehension. It earns a 4 for being efficiently structured despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is highly complex with 12 parameters, all optional, and no output schema. The description covers everything an agent needs: the full filter behavior, sorting semantics, pagination limits, result field meanings (URL, applyUrl, companySlug), duplicate collapse counts, empty-result hints, and even an example call. It also explains edge cases like 'a country also finds roles that name only one of its cities' and the 45% salary exclusion. Nothing essential is missing; the description is a complete operational manual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds substantial semantic value beyond the schema: it explains that 'location matches the canonical places Remoet stores per role rather than the free-text location string' and that 'searchQuery does NOT read location', clarifies techStackMatch 'all' semantics with an example, and warns that salaryMin 'drops every role Remoet holds no numeric salary for, which is roughly 45% of the board'. These details materially change how an agent interprets parameters. While the schema already documents each parameter, the description provides operational nuance that the schema alone does not; hence a 4 rather than 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'Search Remoet's PUBLIC job catalogue: every role on the open board at remoet.dev/jobs, across all companies, not just the ones the user has starred.' It names the resource (public job catalogue), the scope (all companies), and explicitly contrasts with get_starred_jobs, making the tool's unique purpose unambiguous. It is not a tautology and clearly differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage direction: 'Use this to answer "what is out there" for any technology, title or company; use get_starred_jobs instead for the user's own curated feed.' It also offers tactical advice on filters, e.g., 'leave it off otherwise' for salaryMin when not a hard requirement, and 'Start broad and narrow: a single heavily filtered query misses good roles.' This is targeted, actionable guidance for when and how to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search companies on Remoet, or list the user's starred companies (starred: true). Returns a summary per result. Use get_listing with a slug for full detail (description, perks, URLs). Job boards and aggregators are excluded; talent networks that post direct roles (e.g. Toptal) appear as companies.
CRITICAL, star quality: only star companies whose tech stack OVERLAPS the user's skills (a JavaScript dev should not star a Go/Rust-only shop). Stars are the user's job-feed noise filter, so an irrelevant star pollutes their feed with jobs they can't use. Judge overlap by each result's matchedTechStack: the technologies from your techStack filter that the company actually uses, checked against its FULL stack (not the capped preview), so do NOT skip a company just because the visible preview omits the user's skills. An empty matchedTechStack means the result matched on text, not tags. techStackCount is the company's true tag total; the full stack unlocks on starring. techStack matches AT LEAST ONE filtered technology by default; set techStackMatch:"all" to require every one.
Typical flow: read get_profile for the user's stack and seniority, search filtered by their real technologies (and experienceLevel when seniority matters), then star the genuine fits. Use starred: true to audit existing stars (pass the user's techStack to see matchedTechStack per starred company and flag zero-overlap stars). If the user's interests aren't clear, ask before searching.
Example: search_listings({ searchQuery: "payments", techStack: ["TypeScript", "React"], experienceLevel: ["mid"] }).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting from 1 (default: 1) | |
| sortBy | No | Sort results by: stars (most popular), jobCount (most active hiring), or name (alphabetical). Default: relevance when searching/filtering, stars when browsing | |
| starred | No | Set true to list the user's STARRED companies instead of searching the full catalog. In this mode searchQuery/experienceLevel/sort/pagination are ignored; pass techStack to get a matchedTechStack per starred company for auditing stack fit. | |
| pageSize | No | Results per page, max 100 (default: 20) | |
| techStack | No | Filter by technologies (e.g. ["React", "Node.js", "TypeScript"]). Each result's matchedTechStack shows which matched. Technologies are auto-normalized. | |
| searchQuery | No | Search keyword: matches company name, description, and about text | |
| techStackMatch | No | How techStack combines: "any" (default, at least one technology) or "all" (every technology required; use for must-have stacks) | |
| experienceLevel | No | Only companies with at least one open role at any of these seniorities (e.g. ["junior"] for entry-level-friendly companies). Each result's experienceLevels field shows its per-seniority role counts; a 0 can also mean seniority was not detected for those roles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. The description adds crucial context: exclusions, the star-quality rule for filtering noise, and the 'matchedTechStack' semantics that are not in annotations. However, it doesn't mention rate limits or pagination details beyond schema (though schema covers pagination), so a slight gap remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but somewhat verbose, with extensive detail on star quality and matchedTechStack that could be trimmed without loss. It front-loads the core purpose and usage, but the star-quality section adds redundancy. Still, it is structured with an example for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the complexity of 8 optional parameters and no output schema, the description covers key subtleties: how to audit stars, the meaning of matchedTechStack, and the typical flow. It compensates for lack of output schema by explaining the result summary fields (matchedTechStack, experienceLevels). Complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra value by explaining the interplay of techStack and matchedTechStack, the meaning of empty matchedTechStack, and the effect of starred:true on parameter handling. It goes beyond just restating schema definitions, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search companies on Remoet' and differentiates from siblings like search_jobs and get_listing, but it does not explicitly contrast with those siblings in text. The purpose is specific and actionable, yet it could more directly distinguish itself from search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('search filtered by their real technologies', 'Use starred: true to audit existing stars') and when-not-to-use guidance ('Job boards and aggregators are excluded'), and names the alternative (get_listing) for specific needs. This is exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| listingId | Yes | The ID of the listing to star |
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.
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.
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.
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.
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.
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.
Remove a job from the user's saved list. Use get_saved_jobs first to find the saved job ID. Confirm with the user before removing.
| Name | Required | Description | Default |
|---|---|---|---|
| savedJobId | Yes | The ID of the saved job entry to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds a valuable behavioral detail (user confirmation), which is not covered by annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, prerequisite, and action confirmation. Every sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and good annotations, the description covers purpose, prerequisite, and confirmation. It lacks details on return values or error handling but is sufficient given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already provides a regex pattern and description for savedJobId. The description adds context on how to obtain the ID but no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'remove a job from the user's saved list' with a specific verb and resource. It distinguishes from sibling tools like save_job and get_saved_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use get_saved_jobs first to obtain the saved job ID, and confirms the action with the user. It does not mention alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a star from a company listing. WARNING: Unstarring consumes from your unstar budget (per 30-day period), EXCEPT when the user is over their star cap (then trimming back to the limit is free). This prevents unlimited cycling of stars. Call get_account first to check your remaining unstar budget. Only unstar if the company is truly not relevant. Do NOT mass-unstar to get a user under their cap unless they explicitly ask. If they are over cap, surface the choice and let them decide which to keep.
| Name | Required | Description | Default |
|---|---|---|---|
| listingId | Yes | The ID of the listing to unstar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructive, idempotent), the description discloses the budget-consumption rule and its exception, which is not otherwise visible from annotations or schema. It also explains the anti-cycling rationale and the policy guardrails around mass-unstarring.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and then presents structured warnings. It is longer than a minimal description, but each sentence carries policy or cost information that materially affects invocation. Minor redundancy could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with a single parameter and no output schema, the description covers the prerequisite call, the cost model, the exception, and policy guardrails. The agent has everything needed to correctly decide whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents listingId with a clear description and 100% coverage, so the description doesn't need to add parameter-level detail. The phrase 'company listing' aligns with the parameter but introduces no additional semantic info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Remove a star from a company listing') and is clearly the inverse of the sibling star_listing. It is unambiguous and distinguishable from the other save/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs the agent to call get_account first, defines the only acceptable reason to unstar, and forbids mass-unstarring without explicit user consent. It also specifies how to handle the over-cap case: surface the choice and let the user decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the user's Remoet profile core and/or their visibility. Only provide the fields you want to change. Omitted fields are left as-is; pass null to clear a field. Always read the current profile first with get_profile. If the source data (CV, website, etc.) is missing a field, ask the user rather than guessing. Never copy placeholder text like "lorem ipsum".
VISIBILITY: pass visibility to control who can see the profile in company candidate lists: NONE (hidden), STARRED (only companies the user has starred, the recommended two-way match), or ALL (every company). Explain the trade-off before changing it.
SUMMARY WRITING GUIDE: the summary is the most important field, the first thing companies read. Pattern: [Role] with [X years] experience in [core tech stack]. [One differentiator or achievement]. Example: "Senior Full-Stack Developer with 8 years of experience in React, Node.js, and AWS. Built and scaled a SaaS platform serving 200K users." Under 500 characters. Avoid generic fluff like "passionate developer". Be specific and quantifiable.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Your personal website URL | |
| name | No | Your full name | |
| slug | No | Your public profile URL slug (must be unique) | |
| No | Update your email address | ||
| phone | No | Your phone number | |
| summary | No | A brief professional summary or bio | |
| location | No | Your location | |
| avatarUrl | No | Your avatar/photo URL | |
| githubUrl | No | Your GitHub profile URL | |
| twitterUrl | No | Your Twitter/X profile URL | |
| visibility | No | Who can see the profile in company candidate lists: NONE (hidden), STARRED (only companies the user has starred, recommended), ALL (every company). Explain the trade-off before changing. | |
| youtubeUrl | No | Your YouTube channel URL | |
| facebookUrl | No | Your Facebook profile URL | |
| linkedinUrl | No | Your LinkedIn profile URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: it discloses partial-update semantics ("Omitted fields are left as-is"), explicitly describes null as the way to clear a field, and instructs the agent to ask the user rather than guess when source data is missing. These are behavioral details that annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bolded section labels (VISIBILITY, SUMMARY WRITING GUIDE) and front-loaded with the core partial-update behavior. Every sentence carries actionable guidance; the summary writing guide is dense but directly useful for the agent's output quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter mutation tool with no output schema, the description covers selection semantics, prerequisite reads, field-clearing behavior, source-data verification, visibility consequences, and summary quality. It does not describe the response/return value or error behavior, but those are secondary for an update call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds cross-parameter meaning with the only-changed-fields and null-clearing rules, plus a detailed summary writing guide and a visibility trade-off instruction. It does not individually elaborate every parameter, but the schema already handles those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: "Update the user's Remoet profile core and/or their visibility." This clearly distinguishes the tool from sibling sub-resource savers like save_education, save_project, and save_work_experience without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: "Only provide the fields you want to change" and "Always read the current profile first with get_profile." It names get_profile as the prerequisite companion, though it does not explicitly enumerate when to prefer sibling update/save tools over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the note on a saved job. Use this to add context, track application status, or record follow-up reminders. Pass null to clear the note.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | Updated note, or null to clear | |
| savedJobId | Yes | The ID of the saved job entry (not the job ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosure of mutation (updating note) aligns with readOnlyHint=false. IdempotentHint=true is consistent. Description adds the null-clearing behavior and allowed operations beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (update a single field) and absence of output schema, the description is complete enough. No need for return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds value by explaining the note can be a string or null (clear) and clarifying savedJobId is the saved job entry ID, not the job ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update the note on a saved job' with specific use cases (add context, track status, reminders). It clearly distinguishes from siblings like add_application_note (application notes) and save_job/unsave_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit scenarios for use (add context, track status, reminders) and notes the null clearing behavior. Though no explicit when-not-to-use, the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_feed1 field changedInput schema / properties / cursor / maxLengthAdded value: +64save_education5 fields changedInput schema / properties / endDate / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / endDate / descriptionPrevious value: -"End date (ISO 8601)"New value: +"End date: a date, e.g. \"2024-01-15\""Input schema / properties / institution / minLengthAdded value: +1Input schema / properties / startDate / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / startDate / descriptionPrevious value: -"Start date (ISO 8601)"New value: +"Start date: a date, e.g. \"2024-01-15\""save_project8 fields changedInput schema / properties / demoUrl / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 500,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / endDate / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / endDate / descriptionPrevious value: -"End date (ISO 8601)"New value: +"End date: a date, e.g. \"2024-01-15\""Input schema / properties / repoUrl / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 500,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / shortDescription / minLengthAdded value: +1Input schema / properties / startDate / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / startDate / descriptionPrevious value: -"Start date (ISO 8601)"New value: +"Start date: a date, e.g. \"2024-01-15\""Input schema / properties / title / minLengthAdded value: +1save_work_experience5 fields changedInput schema / properties / endDate / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / endDate / descriptionPrevious value: -"End date (ISO 8601), or null if current"New value: +"End date: a date, e.g. \"2024-01-15\". Omit it for a current role"Input schema / properties / startDate / descriptionPrevious value: -"Start date (ISO 8601, e.g. \"2024-01-15\")"New value: +"Start date: a date, e.g. \"2024-01-15\""Input schema / properties / startDate / maxLengthAdded value: +64Input schema / properties / title / minLengthAdded value: +1get_apps1 field changedInput schema / properties / page / typePrevious value: -"number"New value: +"integer"get_listing2 fields changedInput schema / properties / checkTechStack / items / maxLengthAdded value: +100Input schema / properties / slug / maxLengthAdded value: +500get_saved_jobs2 fields changedInput schema / properties / page / typePrevious value: -"number"New value: +"integer"Input schema / properties / pageSize / typePrevious value: -"number"New value: +"integer"get_starred_jobs5 fields changedInput schema / properties / locationQuery / maxLengthAdded value: +500Input schema / properties / page / typePrevious value: -"number"New value: +"integer"Input schema / properties / pageSize / typePrevious value: -"number"New value: +"integer"Input schema / properties / searchQuery / maxLengthAdded value: +500Input schema / properties / techStack / items / maxLengthAdded value: +100search_jobs3 fields changedInput schema / properties / companySlug / maxLengthAdded value: +500Input schema / properties / page / typePrevious value: -"number"New value: +"integer"Input schema / properties / pageSize / typePrevious value: -"number"New value: +"integer"search_listings4 fields changedInput schema / properties / page / typePrevious value: -"number"New value: +"integer"Input schema / properties / pageSize / typePrevious value: -"number"New value: +"integer"Input schema / properties / searchQuery / maxLengthAdded value: +500Input schema / properties / techStack / items / maxLengthAdded value: +100apply_to_jobcreate_linktreedelete_linktreedelete_profile_itemget_accountget_appsget_digestsget_feedget_linktreesget_listingget_profileget_saved_jobsget_starred_jobssave_educationsave_jobsave_projectsave_work_experiencesearch_jobssearch_listingsstar_listingunsave_jobunstar_listingupdate_profileupdate_saved_job_noteVerified AI/tech jobs from company ATSs: search, fit matching, salary stats; employer job posting
Job application tracker for developers - AI agents write over MCP, you review in a dashboard.
Search job postings, companies, and technology stacks across 10M+ companies.
AI job search MCP — fact-checked jobs, application tracker, alerts. ChatGPT, Claude, Cursor.
Add one secure layer between your agents and this server.
