Find robotics, humanoid and embodied AI jobs from PhysicalAI.jobs.
search_jobs and latest_jobs both return jobs, but their descriptions clearly separate keyword-based discovery from recency-based discovery. get_job and search_companies serve distinct purposes with minimal overlap.
Most tools follow a clear verb_noun snake_case pattern: get_job, search_jobs, search_companies. latest_jobs breaks the pattern by using an adjective instead of a verb, and there is minor singular/plural inconsistency.
Four tools is well-scoped for a niche job board server. Each tool covers a meaningful user action without unnecessary redundancy or bloat.
The tool surface covers the full read-only job discovery flow: search jobs, view latest jobs, fetch job details, and search companies. There are no obvious dead ends for the stated purpose.
Retrieve additional sanitized public details for one PhysicalAI.jobs listing. Use this after search_jobs or latest_jobs when the user wants more information. The result links back to PhysicalAI.jobs and never exposes a hidden employer ATS URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stable public job ID returned by PhysicalAI.jobs. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| slug | No | |
| tags | No | |
| title | Yes | |
| remote | No | |
| salary | No | |
| company | No | |
| summary | No | |
| category | No | |
| location | No | |
| open_url | Yes | |
| description | No | |
| published_at | No | |
| canonical_url | Yes | |
| location_type | No | |
| employment_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context on top: results are 'sanitized public details', link back to PhysicalAI.jobs, and 'never exposes a hidden employer ATS URL' – a privacy guarantee not inferable from 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?
Two sentences with no filler. The first states the operation, and the second covers usage context and key behavioral guardrails. Information is front-loaded and each sentence contributes a distinct fact.
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 output schema covers return values, and the description supplies the remaining operational context: when to call it, what kind of data to expect, and the linking/privacy behavior. For a one-parameter read-only detail fetcher, nothing essential 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 fully documents the sole `id` parameter with type constraints and the description 'Stable public job ID returned by PhysicalAI.jobs.' The description's phrase 'for one ... listing' aligns with the parameter but adds no new syntax or format details, so the baseline 3 applies given 100% 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?
Description uses a clear verb-object structure: 'Retrieve additional sanitized public details for one PhysicalAI.jobs listing.' The singular 'one' and 'details' distinguish it from the sibling search tools, and the title reinforces the same purpose. No ambiguity about what resource the tool acts on.
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?
States the intended workflow: 'Use this after search_jobs or latest_jobs when the user wants more information.' That gives a clear trigger condition and places it in a sequence with siblings. It does not explicitly spell out when not to use it or name an alternative tool, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the newest current Physical AI, robotics, humanoid, embodied AI, autonomy, manipulation, perception and controls jobs on PhysicalAI.jobs. Use this for recent-job or jobs-since-a-date questions.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Public PhysicalAI.jobs specialty/tag slugs or names. | |
| limit | No | ||
| since | No | Only jobs published at or after this ISO 8601 date-time. | |
| cursor | No | Opaque next_cursor returned by a previous call with identical filters. | |
| remote | No | True for remote-only results; false for onsite or hybrid results. | |
| company | No | PhysicalAI.jobs company slug or company name. | |
| country | No | Country name, country slug, or two-letter country code. | |
| category | No | Public PhysicalAI.jobs category slug or name. | |
| currency | No | V1 salary thresholds use normalized annual USD compensation. | |
| location | No | Location text such as California, Taipei, or San Carlos. | |
| min_salary | No | Minimum comparable annual salary in USD. | |
| employment_type | No |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| count | Yes | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a bit of behavioral context by emphasizing 'newest current' and the temporal use case, but it does not disclose details like result ordering guarantees, pagination behavior, or whether 'current' means only active listings.
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 two sentences with no wasted words. The core purpose and the primary use case are both front-loaded, making it easy for an agent to parse quickly.
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 12-parameter tool, the description is short but sufficient for selection and initial invocation because the schema and output schema carry most of the invocation details. It clearly identifies the temporal scope and domain. It would be more complete if it explicitly routed broader searches to search_jobs or clarified whether results are ordered purely by publication date.
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 83%, so the schema already documents most parameters. The description adds no meaningful parameter-level detail beyond reinforcing the 'jobs-since-a-date' use case, which aligns with the `since` parameter. This is acceptable given the high schema coverage, but the description itself does not compensate for the undocumented `limit` and `employment_type` parameters.
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 ('Find') and resource ('newest current ... jobs on PhysicalAI.jobs'), and clearly scopes the domain to PhysicalAI/robotics/humanoid/embodied AI jobs. It conveys recency as the distinguishing feature, but it does not explicitly contrast itself with sibling tools like search_jobs, so the differentiation is implied rather than named.
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 says to use this tool for 'recent-job or jobs-since-a-date questions,' which is clear and actionable. However, it does not state when not to use it or point to an alternative such as search_jobs for broader or more complex filtered job searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public PhysicalAI.jobs company profiles and optionally restrict results to companies that currently have public live jobs. Use this for questions about robotics, humanoid or embodied AI companies and who is hiring.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| cursor | No | Pagination token returned by a previous call with identical filters. | |
| hiring_only | No |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| companies | Yes | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context about the data source being public, the optional live-jobs restriction, and the current-hiring angle. 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?
Two sentences, front-loaded with the action and scope. Every phrase earns its place and there is no redundant 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 low-complexity, read-only search tool with no required parameters and an output schema, the description gives enough orientation to select and invoke it. Minor gaps remain around query matching and pagination semantics, but they are not blocking.
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 only 25%, and the description does not compensate. It implies query and hiring_only semantics but leaves limit, cursor, and exactly what query matches undocumented. With low schema coverage, this is a meaningful gap.
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: 'Search public PhysicalAI.jobs company profiles.' It also differentiates from the job-focused siblings by targeting companies, and clarifies the domain as robotics, humanoid, and embodied AI companies.
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 context: 'Use this for questions about robotics, humanoid or embodied AI companies and who is hiring.' It doesn't name sibling alternatives or say when not to use the tool, but the use-case guidance is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search current robotics, humanoid, embodied AI and Physical AI roles from PhysicalAI.jobs by keyword, specialty, company, location, remote status and compensation. Use this when a user wants to discover or shortlist relevant jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Use salary_desc only when comparing jobs with usable compensation data. | |
| tags | No | Public PhysicalAI.jobs specialty/tag slugs or names. | |
| limit | No | ||
| query | No | Keywords or specialty, for example robotics controls, humanoid, perception, or VLA. | |
| since | No | Only jobs published at or after this ISO 8601 date-time. | |
| cursor | No | Opaque next_cursor returned by a previous call with identical filters. | |
| remote | No | True for remote-only results; false for onsite or hybrid results. | |
| company | No | PhysicalAI.jobs company slug or company name. | |
| country | No | Country name, country slug, or two-letter country code. | |
| category | No | Public PhysicalAI.jobs category slug or name. | |
| currency | No | V1 salary thresholds use normalized annual USD compensation. | |
| location | No | Location text such as California, Taipei, or San Carlos. | |
| min_salary | No | Minimum comparable annual salary in USD. | |
| employment_type | No |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| count | Yes | |
| next_cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the search covers 'current' roles and is sourced from PhysicalAI.jobs, but it does not disclose additional behavioral details like pagination behavior or any limitations beyond what annotations and schema already provide. No contradiction exists.
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 two concise sentences with no wasted words. The primary action and resource are front-loaded, and the usage guidance is a clear second sentence. Every part earns its place.
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 has 14 parameters and a high schema coverage of 86%, the description provides enough context: the source of jobs, the search scope, and the intended use case. The output schema is present, so the description need not explain return values. It could be slightly more explicit about how it differs from sibling tools, but it is not incomplete for invoking 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 high (86%), so the burden on the description is low. The description lists filter dimensions such as keyword, specialty, company, location, remote status, and compensation, which map to query, tags, company, location, remote, and min_salary/currency. However, it adds little meaning beyond what the schema descriptions already cover, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Search') and resource ('current robotics, humanoid, embodied AI and Physical AI roles from PhysicalAI.jobs'), and lists the main filter dimensions. It is clear and unambiguous, but it does not explicitly name sibling tools like get_job or latest_jobs to differentiate when each should be used.
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 usage context: 'Use this when a user wants to discover or shortlist relevant jobs.' This tells the agent when to invoke the tool, though it does not state when not to use it or explicitly point to alternatives such as get_job or latest_jobs.
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. Dates show when Glama detected each change.
get_joblatest_jobssearch_companiessearch_jobsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Job platform for AI agents. Track tech jobs from companies that match your stack.
Embodied AI & robotics MCP — 180+ companies, funding, Pulse, sector data (CC BY-NC 4.0)
Search AI-native jobs, inspect application forms, and fetch free interview-prep resources.
Vendor-neutral catalog of 300+ commercial robots: search, compare specs, request vendor intros.
