AI-agent-first job platform. Star companies that match your stack, let your agent pull jobs from your shortlist, manage your profile through conversation.
Scored across 24 tools
Most tools target distinct resources: profile, jobs, companies, linktrees, account, and feed. The main ambiguity is between get_feed and get_starred_jobs, which both surface jobs from starred companies, though the descriptions clearly separate the composed notification feed from the filterable curated list.
Tool names overwhelmingly follow snake_case verb_noun conventions (get_*, save_*, search_*, star_*, unstar_*). Minor deviations: apply_to_job inserts a preposition, and linktree endpoints mix singular/plural forms like create_linktree versus get_linktrees.
24 tools is on the heavy side, but the server spans several subdomains: job search, company stars, profile management, saved jobs, linktrees, feed, and account. It sits in the 16-25 range that feels heavy, though each tool has a distinct role.
Core workflows are well covered: profile CRUD, job search/save/unsave/apply, company star/unstar, and linktree create/get/delete. However, linktrees lack an update tool, and there is no application-history or application-listing tool, so some user journeys dead-end.
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, and the description adds substantial behavioral detail beyond that: the stream is composed and chronological, entries have kinds, and it explains nuanced semantics such as per-item isStarred=false meaning the user unstarred that company since. This gives the agent a rich picture of what the feed contains beyond the basic safety 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 dense but every sentence earns its place: it defines the stream, enumerates entry kinds and their key fields, explains flag meanings, and gives practical polling and pagination guidance. It is front-loaded with the core concept and then layers detail logically.
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 carries the burden of explaining return values, and it does so thoroughly: entry kinds, per-role fields, per-item flags, semantics, ordering, and pagination. Combined with the annotations' safety profile, the agent has everything needed to call and interpret this 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 both cursor and pageSize. The description adds a small amount of behavioral clarity around cursor usage, but it does not meaningfully expand parameter semantics beyond what the schema already provides. The baseline of 3 is appropriate when the schema carries the full load.
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 specifies a clear verb and resource: it returns the user's dashboard feed as one composed stream, newest first. It enumerates the distinct kinds of entries ('item', 'job_of_the_day', 'blog', 'broadcast'), which makes the tool's purpose concrete and distinguishes it from more specific sibling tools like get_saved_jobs or get_starred_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 gives strong usage context: 'Poll this on the user's schedule to act as their notification layer' and points to the follow-up action save_job. It also explains cursor usage ('Pass nextCursor back to page deeper; omit it for the newest page'). However, it does not explicitly state when to choose this tool over alternatives or when not to use it, so it stops short of a 5.
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 (ISO 8601) | |
| isCurrent | No | Whether you are currently studying here (default false on create) | |
| startDate | No | Start date (ISO 8601) | |
| 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?
Beyond the annotations, it discloses upsert semantics, partial-update behavior ('changing only the fields you send'), and the create-only requirement for institution. It also instructs the agent to confirm dates and not fabricate, which are important behavioral guardrails for a user-facing write.
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?
Four sentences, with the core action and modes front-loaded in the first sentence. Each subsequent sentence adds either a workflow condition or a data-quality guardrail; no filler.
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 9-parameter upsert with no output schema, the description plus schema covers creation vs update, required fields, duplicate avoidance, date handling, and what to ask the user. No critical calling behavior is left unexplained.
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 covers 100% of parameters, so the baseline is 3. The description adds contextual guidance on id/institution usage and tells the agent to ask about degrees/bootcamps/certifications and confirm dates, which enriches but does not fundamentally extend 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?
States 'Add or update an education entry (upsert)' – a specific verb and resource, with the two modes spelled out. The 'education' resource distinguishes it from siblings like save_work_experience, so an agent knows exactly what it targets.
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?
Directs the agent to 'Check get_profile first to avoid duplicates' and to source ids from get_profile, giving a clear precondition and workflow. It does not explicitly name an alternative tool for the same operation or list exclusions, so it stops short of full when-not-to-use guidance.
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 (ISO 8601) | |
| 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 (ISO 8601) | |
| 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?
With annotations all false, the description adds critical behavioral context: upsert semantics, required fields on create, partial-only updates, and a precondition to check get_profile. It also includes an anti-hallucination instruction ('don't fabricate or embellish'), which is beyond 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 informative without being bloated. The first sentence captures core behavior, the second provides strategic guidance, and the third gives a safety instruction. Each sentence adds value, though the motivational sentence could be considered slightly extraneous for tool invocation.
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 essential operational details: upsert behavior, required fields, partial update, and duplicate avoidance. It could mention response format or error cases, but those are less critical given the schema's full parameter coverage.
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 meaning beyond the schema by clarifying that title and shortDescription are required for create (though the schema lists them as optional), and that updates only change passed fields. This is significant for correct invocation.
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 a specific verb and resource ('Add or update a portfolio project (upsert)') and distinguishes create from update behavior with explicit references to id and get_profile. This clearly differentiates it from sibling tools like save_work_experience or update_profile.
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 provides explicit usage context: omit id to create, pass id from get_profile to update, and check get_profile first to avoid duplicates. It does not name alternative tools explicitly or state when not to use it, but the create/update distinction and prerequisite are clear.
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 (ISO 8601), or null if current | |
| 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 (ISO 8601, 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 carry boolean flags, so the description carries the behavioral burden. It explains partial-update semantics ('changing only the fields you send'), the upsert contract, and adds guardrails against duplicates and fabrication. It stops short of disclosing auth needs or error behavior, so not a full 5.
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 upsert behavior and every sentence contributes value. It is slightly dense because it packs in content-quality and workflow guidance alongside tool mechanics, but it remains organized and efficient.
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 10-parameter upsert with no output schema, the description covers the full workflow: create/update choice, required fields, id sourcing, duplicate avoidance, and field-level content expectations. Missing return-value and error-case details are minor for tool selection and 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?
Even with 100% schema coverage, the description adds real meaning: title and startDate are conditionally required for create, ids come from get_profile, technologies feed job matching, and the description field has explicit WHAT/HOW/IMPACT/SCOPE content rules. This goes well beyond the raw 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 opens with 'Add or update a work experience entry (upsert)', giving a specific verb, resource, and operation mode. This clearly distinguishes it from sibling save_education and save_project tools by naming 'work experience' as the target.
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 provides concrete create-vs-update logic: omit id to create, pass an id from get_profile to update, and check get_profile first to avoid duplicates. It does not explicitly name alternatives or state when not to use the tool, but the workflow guidance is clear and actionable.
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_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_note
Add one secure layer between your agents and this server.