Enquiries for Dynomatix, a software practice.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 7 of 7 tools scored.
Each tool targets a distinct action and resource: about, list/get positions, list/get work, submit application/enquiry. There is no overlap; an agent can easily select the correct tool based on whether it needs company info, a job posting, a case study, or to submit a form.
The dynomatix_ prefix is consistent, and most tools follow a verb_noun pattern (list_open_positions, get_position, submit_application). The exception is dynomatix_about, which uses a noun instead of a verb, but it is a single minor deviation and the overall pattern remains predictable.
Seven tools is well-scoped for a company website that provides company info, job listings, case studies, and two submission forms. Each tool earns its place, and there is no bloat or redundancy.
For the apparent domain (Dynomatix's public site), the tool set fully covers reading about the company, browsing and retrieving jobs and work, and submitting applications and enquiries. There are no obvious dead ends: list tools feed detail tools, and submission tools have clear input requirements.
dynomatix_aboutAbout DynomatixAInspectWho Dynomatix is, what it sells and how to reach it. Returns the company's identity and tagline, its engagement types, both contact addresses, its key pages and its track record. Read this first if you are deciding whether this company fits a need; use dynomatix_submit_enquiry to start a conversation. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| proof | No | Years active, products shipped, how many are still live. |
| contact | No | General and hiring email addresses, and the enquiry page. |
| identity | No | Name, legal name, URL, tagline, description, founding year. |
| keyPages | No | Labelled links to the pages worth reading next. |
| engagements | No | The kinds of work Dynomatix takes on. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It says 'Returns' implying a read-only operation and 'Takes no arguments' clarifying no side effects from parameters. However, it does not explicitly state that it has no side effects or that it is safe to call repeatedly. Minor gap but largely transparent.
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 tool's purpose, and every sentence earns its place: the first lists content, the second gives usage guidance and alternative. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple informational tool with an output schema and no params, the description covers what the tool returns, when to use it, and the alternative. It is complete for the agent to select and invoke 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?
The input schema is empty and the description explicitly states 'Takes no arguments,' confirming the absence of parameters. With 0 params, baseline is 4; this description adds clarity by stating it explicitly.
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 ('Returns') and clearly specifies the resource ('company's identity and tagline, engagement types, contact addresses, key pages, track record'). It distinguishes itself from sibling tools by focusing on company info versus positions, work, or applications.
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 'Read this first if you are deciding whether this company fits a need' and directs to an alternative: 'use dynomatix_submit_enquiry to start a conversation.' This provides clear when-to-use and a sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dynomatix_get_positionRead a job postingAInspectRead one job posting in full: responsibilities, requirements and how the role is set up. Returns the posting's own markdown, frontmatter included — the title and canonical URL it opens with are the citation to quote when you tell someone about the role. Call dynomatix_list_open_positions first to get a valid slug; a slug that is not currently open is refused rather than guessed at.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The position's slug, exactly as dynomatix_list_open_positions returned it. Lowercase letters, digits and hyphens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the return format (markdown with frontmatter), the role of title/canonical URL as citations, and the refusal behavior for invalid slugs. This goes beyond basic expectations.
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 concise, front-loaded with the main purpose, and each sentence provides essential information. No filler or 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?
For a single-parameter read tool with no output schema, the description adequately explains what is returned, how to get the parameter, and error behavior. It is complete for an agent to invoke safely and effectively.
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 slug parameter has a detailed description. The tool description adds the important context that the slug must come from dynomatix_list_open_positions, reinforcing how to obtain it correctly. This adds value 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 tool reads one job posting in full, listing the content (responsibilities, requirements, setup). It distinguishes itself from sibling tools like dynomatix_list_open_positions (list vs. get) by specifying it reads a single posting.
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 instructs to call dynomatix_list_open_positions first to obtain a valid slug, and warns that non-open slugs are refused rather than guessed. This provides clear usage context and differentiates from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dynomatix_get_workRead a case studyAInspectRead one case study in full: what the problem was, what was built and what it changed. Returns the study's own markdown, frontmatter included — the title and canonical URL it opens with are the citation to quote. Call dynomatix_list_work first for a valid slug; only entries whose caseStudyUrl is not null have a write-up to return.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The item's slug, exactly as dynomatix_list_work returned it. Lowercase letters, digits and hyphens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses the return format (markdown with frontmatter), the significance of the title and canonical URL as the citation, and the null-caseStudyUrl behavior. It is slightly shy of a 5 only because it doesn't mention error behavior or response shapes, but for a read tool this is a strong disclosure.
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, front-loaded with the core action, and every clause earns its place. It packs purpose, output, prerequisite, and validity condition without waste.
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 read tool with no output schema, the description fully covers what the tool returns, how to get a valid input, and when no write-up exists. No additional behavioral detail is necessary for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the slug parameter with format constraints (maxLength, lowercase/digits/hyphens). The description adds crucial context beyond the schema by instructing the agent to obtain the slug from dynomatix_list_work and to check `caseStudyUrl` for validity. This exceeds the schema's basic 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 opens with a specific verb and resource: 'Read one case study in full' and clarifies what is returned ('what the problem was, what was built and what it changed'). It also distinguishes itself from the sibling list tool by specifying it returns the study's markdown and frontmatter, making its purpose unambiguous.
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?
Explicit usage guidance is provided: 'Call dynomatix_list_work first for a valid slug' and warns that only entries whose `caseStudyUrl` is not null have a write-up. This tells the agent when and how to use the tool, including a direct prerequisite and a filtering condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dynomatix_list_open_positionsList open positionsAInspectList every role Dynomatix is currently hiring for. Returns one entry per position with its slug, title, one-line summary, employment type, canonical URL and posting dates. Start here before dynomatix_get_position or dynomatix_submit_application: the slug this returns is the value both of them expect. An empty list means there are no openings right now, not that the lookup failed. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| positions | Yes | Open roles, in the order the site lists them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses return contents (slug, title, summary, etc.), empty-list semantics (no openings vs. failure), and confirms no arguments. It doesn't discuss auth or rate limits, but for a simple read-only list tool this is sufficient transparency.
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: purpose, return details + usage guidance, and empty-list semantics. Front-loaded with the main verb phrase. No wasted words.
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 no-param list tool with an output schema, the description covers purpose, return fields, relation to sibling tools, edge case (empty list), and argument expectations. It leaves no meaningful gaps for an agent to misuse the tool.
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 the schema is an empty object. The description explicitly states 'Takes no arguments,' reinforcing the schema and eliminating any ambiguity. This adds value beyond the bare 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 'List every role Dynomatix is currently hiring for', a specific verb+resource statement. It also distinguishes itself from siblings by explicitly positioning as the entry point for get_position and submit_application, clarifying its unique role.
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: 'Start here before dynomatix_get_position or dynomatix_submit_application' and explains that the returned slug is expected by both. Also interprets empty results to avoid false negatives, giving clear context for using the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dynomatix_list_workList past and current workAInspectList the products and client work Dynomatix has shipped. Returns one entry per item with its name, the year it started, its status, a short description and its links. Retired items are included — the site shows them and status says which is which — because a track record with the failures removed is not a track record. Where caseStudyUrl is not null, dynomatix_get_work will return the full write-up for that slug. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| work | Yes | Products and engagements, in the order the site lists them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the return format (one entry per item with specific fields), the inclusion of retired items, the role of `status`, and the behavior around `caseStudyUrl`. It also explains the reasoning for including retired items, which is valuable behavioral context beyond a simple list operation.
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 three sentences long and front-loads the core purpose. Every sentence adds value: the first defines what is listed, the second clarifies item fields and inclusion of retired work, and the third links to a complementary tool. No filler or 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 low complexity (no parameters) and the presence of an output schema, the description covers all necessary ground: scope of items, what fields are returned, handling of retired items, and how to access detailed write-ups. It is fully self-contained for an agent to select and invoke 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?
The tool has zero parameters, so the baseline is 4. The description explicitly states 'Takes no arguments,' eliminating any ambiguity. Since the schema is empty, there is no additional parameter behavior needed, and the description covers the only relevant semantic: no input is required.
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 verb and resource: 'List the products and client work Dynomatix has shipped.' This immediately distinguishes it from sibling tools like dynomatix_list_open_positions (jobs) and dynomatix_get_work (single write-up), making the tool's purpose unambiguous.
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 clear context by explaining that all work is listed, including retired items, and that `caseStudyUrl` links to a more detailed write-up via dynomatix_get_work. It names the alternative for detailed reads, though it does not explicitly state when NOT to use this tool, so it stops short of a full when/when-not guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dynomatix_submit_applicationApply for a positionAInspectSubmit a job application to Dynomatix, résumé included. This is final: it delivers straight to a monitored human inbox and cannot be edited, recalled or deleted afterwards. Confirm the details with the person you are acting for before you call it, and do not call it twice for the same submission — a retry sends a second copy. Set position to a slug from dynomatix_list_open_positions. Supply the résumé exactly one of two ways: resume_url, an https link that downloads the file itself (a sharing page from a drive or a document service is not a direct link and will be refused), or resume_base64 together with resume_filename. Supplying both, or neither, is refused. The résumé must be a PDF, DOC or DOCX file under 5 MB; its contents are checked against its extension, so a renamed file is refused too. Nothing is stored until every field passes, and the reply confirms receipt with a submission id worth quoting in any follow-up — it never returns the résumé or a link to it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The applicant's full name. | |
| Yes | The applicant's email address, in the form name@example.com. This is the only way they will be contacted, so check it before sending. | ||
| phone | No | Optional. The applicant's phone number. | |
| letter | No | Optional cover letter. Newlines are preserved. | |
| position | Yes | Slug of the role, from dynomatix_list_open_positions. A role that is not on that list is not accepting applications. | |
| portfolio | No | Optional. A full web address starting with http:// or https:// — a portfolio, GitHub profile or personal site. | |
| resume_url | No | An https URL that downloads the résumé file directly. Not a sharing or preview page — the response must be the file itself. Use this OR resume_base64, never both. http:// is refused, as are hostnames that resolve inside a private network. | |
| resume_base64 | No | The résumé's bytes, base64-encoded. Use this OR resume_url, never both. Requires resume_filename. Payloads over 5 MB are refused before they are decoded. | |
| resume_filename | No | Required with resume_base64: it is the only source of the file's extension, which must be one of PDF, DOC or DOCX. Optional with resume_url, where the URL's last path segment is used instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and thoroughly discloses the irreversible nature, retry duplication, strict file validation (direct link, extension-content match, size limit), conditional storage, and the submission ID in the reply. This goes well beyond a basic 'submits an application' statement.
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 every sentence is information-dense and necessary for a high-stakes irreversible action. It is front-loaded with the core purpose and warnings, then systematically covers parameter usage and validation.
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 9 parameters, no annotations, and no output schema, the description is exceptionally complete: it covers prerequisites, exact usage rules, refusal conditions, storage behavior, and the shape of the reply. The only minor omission is the absence of a stated response shape, but it says a submission id is returned.
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%, but the description adds meaningful cross-parameter semantics: the mutually exclusive resume_url/resume_base64 pairing, the resume_filename requirement, the direct-link requirement, and the content-extension check. These details are partly in the schema but the description synthesizes them and adds finality/submission-id behavior.
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: 'Submit a job application to Dynomatix, résumé included.' It clearly distinguishes this from sibling tools like list_open_positions and submit_enquiry by focusing on the submission action and its irreversible delivery to a human inbox.
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: it is the final step after choosing a position from dynomatix_list_open_positions, with explicit warnings to confirm details and avoid duplicate submissions. However, it does not explicitly contrast with sibling tools like submit_enquiry or state when not to use this tool other than via the position-slug constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dynomatix_submit_enquirySend a work enquiryAInspectSend a project enquiry to Dynomatix — the same form the site's enquiry page submits. This is final: it delivers straight to a monitored human inbox and cannot be edited, recalled or deleted afterwards. Confirm the details with the person you are acting for before you call it, and do not call it twice for the same submission — a retry sends a second copy. Give the company or product website in company (a bare hostname like example.com is fine) and say what needs building in brief. Nothing is stored: the enquiry becomes an email and nothing else. Ask for a budget on the call, not here — this form does not collect one.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The enquirer's full name. | |
| brief | Yes | What needs building, in the enquirer's own words. Newlines are preserved. There is no minimum — a single line is a fine enquiry. | |
| Yes | The enquirer's email address, in the form name@example.com. This is the only address the reply can go to. | ||
| company | Yes | The company or product website. A bare hostname is accepted and https is assumed; anything that is not a web address is refused. | |
| timeline | No | Optional. One of: exploring (Exploring), this-quarter (This quarter), already-started (Already started and stuck). Omit it if unknown — blank is valid, a value outside this list is not. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly warns that the submission is final, cannot be edited/recalled/deleted, delivers to a monitored human inbox, and that retrying sends a duplicate. It also discloses that nothing is stored and the enquiry becomes an email, which is valuable beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries meaningful warnings or guidance, and the most critical information (finality, retry risk) is front-loaded. It is slightly longer than necessary because the permanence is emphasized twice ('cannot be edited, recalled or deleted' and 'becomes an email and nothing else'), which prevents a 5.
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 high-stakes, irreversible submission tool with no output schema, the description is thorough: it explains finality, retry consequences, delivery destination, data handling, and budget exclusion. It also covers parameter usage sufficiently, so the agent has the full context needed to invoke it safely.
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 a little guidance like 'Give the company or product website in company' and 'say what needs building in brief,' but these mostly restate the schema's own descriptions. It does not significantly extend 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 clearly states the tool's function with a specific verb and resource: 'Send a project enquiry to Dynomatix — the same form the site's enquiry page submits.' It distinguishes from the sibling submit_application by specifying 'project enquiry' and describing the enquiry page, so an agent can tell this is for project inquiries, not job applications.
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 gives strong usage guidance: confirm details before calling, do not call twice, and ask for budget on the call rather than here. However, it does not explicitly name alternative sibling tools like submit_application, so it falls short of full alternative-tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
