MERA Robotics

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine value by disclosing the return payload (full Markdown body plus URL and language), which matters because there is no output 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?

A single front-loaded sentence covering action, source of the input, and return content, with zero 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?

With one required parameter, full schema coverage, and no output schema, the description supplies everything an agent needs: the prerequisite tool, the id format, and what comes back. Nothing material 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%, so the `id` parameter is already documented as coming from search. The description goes further by showing concrete id shapes ("en:profile", "pl:service:events", "blog:<slug>"), clarifying the namespace/locale prefix convention that the schema does not.

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 (returns the full Markdown text of a document) and explicitly ties it to the sibling `search` that produces the id, so an agent can distinguish retrieval from discovery without opening 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?

The phrase "found with search" establishes the workflow: search first, then fetch by id. It gives clear context for when to call it, but no explicit exclusion (e.g. what to do if the id is unknown or stale).

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

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world scope, so the safety profile is fully covered. The description adds useful content disclosure (it explicitly says there are no published prices, which prevents the agent from fishing for pricing data) but says nothing about response shape or that the payload is a fixed static fact set. Adequate but not rich.

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?

One dense sentence plus a short routing sentence; the content inventory is front-loaded and the usage rule closes it. The parenthetical list of related entities is slightly crowded but each item is genuinely informative.

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-only, closed-world lookup with no output schema, the description covers what's inside, how it relates to sibling tools, and one important negative fact (no prices). No output schema exists, so a brief note on return structure would have closed the last gap.

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 'lang' parameter is fully documented in the schema, including the subtle rule that fact texts remain in canonical Polish while labels switch. The description adds nothing about lang, so this is the baseline for complete 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?

Names a specific resource (MERA Robotics company profile) and enumerates exactly what it returns: registry data, business description, rental fleet, locations, languages, pricing policy, contacts, related entities. It is clearly distinguishable from siblings like list_robots, get_how_we_work, and get_media_and_proof because it claims the aggregate/general-facts role rather than a single facet.

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?

"Use it first for any general question about MERA Robotics" gives a clear entry-point rule relative to the other tools. It stops short of naming explicit alternatives or exclusions (e.g. 'for a fleet listing use list_robots instead'), so it stays just below the top band.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description adds real behavioural context beyond that: it discloses scope of content and, importantly, that an inquiry does not book a date or confirm a price — a constraint that prevents the agent from over-promising. It still says nothing about the shape of the returned content.

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?

A single sentence with no filler, where each clause maps to a distinct topic an agent might be asked about. It is list-like rather than front-loaded with a main clause, 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 one-parameter, read-only tool this covers what the content is about, which is the main selection question. With no output schema, however, the description never states the return form (a prose article, sectioned text, canonical Polish fact texts), so an agent cannot anticipate what it will get back.

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?

There is a single optional parameter (lang) with 100% schema description coverage, including the enum values and the rule for choosing 'pl' vs 'en'. The description only alludes to languages as a content topic, adding nothing to the schema, so the baseline 3 applies.

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 tool's title and description make clear this is an informational/read tool about MERA's cooperation process, and it enumerates the specific topics returned (inquiry steps, on-site behaviour, purchase and deployment, languages, pricing policy, inquiry contents). It differentiates itself reasonably from siblings like get_company_profile and get_media_and_proof by topic. The only gap is that no explicit verb frames the content ('returns documentation covering...'), so it reads as a topic list.

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?

Usage is implied by the topic list — an agent can infer it should call this for process, pricing-policy, or inquiry-content questions — and the trailing caveat steers it away from promising bookings or prices. But there is no explicit when-to-use/when-not, and no routing to alternatives such as open_inquiry_form or request_quote when the user actually wants to act.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's value is in labelling provenance — third-party independent outlets versus first-party campaign data — which directly affects how the agent should present the evidence. It also flags conditional rendering as source cards depending on host support, which is behavior the annotations cannot convey. Return format details beyond that are absent.

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?

Front-loaded with what the tool returns, then the trigger condition, then rendering behavior — a sound order with no filler sentences. The long outlet enumeration is slightly list-heavy but earns its place by grounding the notion of independent coverage.

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 still conveys the shape of results (per-item subject, source cards, first-party labels) and the kind of sources included. Enough for an agent to call it and describe results accurately, though it does not say what happens when evidence is missing for a requested claim.

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 lang parameter already documents its enum, default, and the rule about Polish fact texts, so the description adds nothing about parameters. Baseline 3 applies when the schema carries the parameter burden.

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 names a concrete resource set — third-party press coverage, Wikipedia/Wikidata entries, documented projects and campaign results — and distinguishes third-party coverage from first-party-labelled data, which is the key semantic split versus siblings like get_company_profile. It never names the sibling it is not, so the differentiation is inferable rather than explicit.

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?

'Use it when someone asks for proof, references or press coverage' gives a clear triggering condition tied to the user's intent. It stops short of exclusions or routing to alternatives such as get_company_profile when the answer is self-reported rather than external.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is low. The description adds real value beyond them: results contain no prices, availability comes from the shop or an inquiry, fact texts stay in canonical Polish, and output may render as robot cards with an inquiry button depending on host support.

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 dense sentences, catalog scope front-loaded, then the price caveat and rendering note. Slightly long enumeration of products, but every clause carries information an agent can use.

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?

No output schema exists, and the description compensates by stating what each entry contains (type, purpose, key specs, shop links) and that prices are absent. A brief note on result volume or whether all robots return by default would close the remaining gap.

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% with all four enums fully documented, so the schema carries parameter meaning. The description adds nothing about how type/robot/availability combine or interact (e.g. 'used' appearing in both enums), leaving only the schema as guidance.

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?

Names a concrete verb+resource: lists the MERA robot catalog, enumerating rent-with-operator units (G1, H2) and for-sale units (humanoids, quadrupeds, industrial, hand, teleop kit, used G1 EDU), plus the fields returned. The scope is very clear, though sibling differentiation is only implicit (the 'no prices, use shop or inquiry' clause gestures at request_quote/open_inquiry_form without naming them).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: call this to browse the robot catalog, and note that pricing/availability requires the shop or an inquiry. There is no explicit when-to-use/when-not or named alternative, so an agent must infer that pricing questions route elsewhere.

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

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

Annotations already declare a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds useful behavioral context by explaining the returned service details and host-dependent rendering as service cards with an inquiry button.

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 and packs the service scope and return behavior into one sentence. It is somewhat dense and partly restates the service enum values, but most of the detail 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?

With no output schema, the description appropriately explains what the result contains: service coverage, fit, deliverables, confirmation points, and card rendering where supported. It does not explain filtering behavior, but that is already well covered by the input schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the two parameters are already documented. The description adds semantic meaning to the service enum values by mapping them to concrete offerings such as event robots with operators, robot purchase, business deployment, MERA OS, campaigns, and media requests.

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 that this tool returns MERA services with coverage, fit, deliverables, and pre-commitment confirmation details. It is specific about the resource and content, but does not explicitly distinguish itself from siblings such as request_quote or open_inquiry_form.

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?

There is no explicit guidance on when to use this tool versus alternatives like request_quote, open_inquiry_form, or search. The description implies a service catalog and mentions an inquiry button, but does not state selection conditions or exclusions.

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

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

Beyond the annotations, the description explains the interaction model: the form is prefilled, the person reviews details, ticks consent, and clicks Send inquiry. It also clarifies that the tool sends nothing by itself, which is important context for a form-display tool.

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 focused sentences with no waste. The action, the no-send behavior, the use case, and the fallback are all front-loaded and easy to scan.

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 form-display tool with fourteen optional parameters, full schema coverage, and no output schema, the description covers the interaction sufficiently. It explains what appears, what the user must do, and what to do if the host cannot render the form.

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 all fourteen optional prefill fields are already well documented. The description lists some prefilled details but does not add meaningful syntax or constraints beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it shows an inquiry form for MERA Robotics in the chat, prefilled with known details. It also immediately clarifies that the tool itself sends nothing, which distinguishes a form-display action from the submission action.

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 says when to use the tool: when someone wants to ask MERA about a date, rental, purchase, or deployment. It also gives a concrete fallback path: if the host cannot show the form, collect details and use request_quote after agreement.

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

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

Adds context beyond annotations: the message is irreversible ('cannot be recalled'), routes to a third party, produces an e-mail reply rather than an in-tool result, and that a repeat within 24 hours is deduplicated. The dedupe window is a mild tension with idempotentHint=false, but it reads as a server-side safety net rather than a contradiction of the destructive/outbound framing.

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?

Five dense sentences, front-loaded with what the tool does and immediately followed by the hard precondition and the alternative. Slightly redundant since the consent rule is restated from the schema, but 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 19-parameter outbound tool with no output schema, the description covers irreversibility, recipient, delivery channel, dedupe, and what the tool does not do. It stops short of saying what a successful call returns or how failures surface, which is the remaining gap.

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%, including per-field guidance like 'Never guess' the e-mail and the anti-spam website field, so the baseline is 3. The description reinforces the contact_consent gating workflow, but that rule is already spelled out in the schema, so it adds little beyond it.

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 — an outbound inquiry sent to the MERA team, delivered by e-mail reply to the given address. It also bounds scope by saying it does not book a date or confirm a price, which separates it from anything a reader might assume a 'quote' tool does.

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 preconditions: call only after the person has seen exactly what will be sent and agreed to share name/e-mail with MERA (contact_consent=true). Names the preferred alternative (open_inquiry_form) and the condition that selects it ('when the host can show it'). Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent and closed-world, so the description only needs to add context — and it does, by disclosing the return shape (ids, titles, URLs, snippets) and the snippet-then-fetch workflow. It adds no permission or rate-limit caveats, which is a minor remaining gap.

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, zero waste. The content scope comes first and the return/workflow contract second, which is the right front-loading for a search tool.

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?

No output schema exists, so the description carries the return-value burden and does so fully: result fields and the id-to-fetch path are spelled out. Combined with a fully documented two-parameter schema, nothing an agent needs to call it correctly 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%: query examples and the 1-20 limit bound are already documented in the schema. The description adds nothing about parameter behavior or syntax beyond what the schema provides, so the baseline 3 applies.

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 (searches) and an explicit resource scope: the MERA Robotics profile, services, robots, evidence and knowledge-base articles. The enumeration of covered content and languages lets an agent distinguish it from the list_* enumerators without opening their schemas.

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 routes the follow-up step: 'pass an id to fetch for the full text', naming the fetch sibling and the condition that selects it. It does not state when to prefer this over list_robots or list_services, so usage is clear but not fully exclusive.

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