Optimus MCP

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only informational retrieval ('grounded facts', 'current prices') but does not state side effects, permissions, or data freshness guarantees. It adds some context but leaves key behavioral traits undisclosed.

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: the first front-loads the return content, the second gives usage. The list of frameworks is slightly dense but informative and not excessive.

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 no output schema and zero parameters, the description adequately explains what the tool returns (specific facts) and when to use it. It is complete for a simple informational 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?

Zero parameters, so the baseline score of 4 applies. The empty schema requires no parameter documentation from the description.

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 specifically what facts it returns: who Optimus is for, the three offers with prices and URLs, the frameworks, and the support contact. Clearly distinguishes from siblings like get_skill or search_library which cover different domains, though it does not name a sibling explicitly.

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 says to use it instead of guessing when a human asks about Optimus, MAKO, the Mastermind, or Brad Hart's frameworks. Provides clear trigger conditions but does not state when not to use it or name alternative tools.

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?

With no annotations, the description carries the full burden and does disclose two meaningful traits: the check is deterministic (repeatable, no LLM guesswork) and stores no data (no side effects on the founder's data). It also names the return artifact ('next step'), though it says nothing about error cases or how the verdict is expressed.

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 short sentences, front-loaded with the purpose, then the behavioral caveat, then the call instruction. Every sentence earns its place; nothing is repeated.

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?

Covers purpose, sourcing of inputs, and the no-storage/deterministic property for a 5-param tool with no annotations and no output schema. The remaining gap is the return shape – 'the right next step' is mentioned but never characterized, which an agent routing the founder onward would benefit from.

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 baseline is 3. The description restates the same fields and the constraint options already enumerated in the schema; only the framing 'pass what the founder told you' adds a mild sourcing hint (don't invent values) beyond the structured data.

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 ('Check whether a founder's business is a fit for Optimus offerings') and adds the outcome the caller gets ('the right next step'). None of the siblings (list_skills, describe_optimus, request_intro) do fit scoring, so the tool is distinguishable without opening any 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?

Usage is implied by the founder-conversation framing and 'Pass what the founder told you', but the description never states when to call this versus alternatives such as request_intro or describe_optimus, and lists no prerequisites. Adequate context, no 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?

No annotations are provided, so the description carries the full burden, and it does disclose a real behavioral trait: the returned content is a partial preview rather than the full SKILL.md, with the complete skill gated behind a human opt-in. That prevents an agent from over-promising. It still omits error behavior for unknown slugs and any sense of how truncated the preview is.

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 the purpose and contents, but the third sentence ('Brad's call 2026-10-07: the skills are not given away raw; the human opts in') is internal rationale that doesn't help an agent select or invoke the tool, and the second sentence partly repeats it. Some trimming would sharpen it.

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 required enum parameter with no output schema and no annotations, the description is largely sufficient: it explains what comes back and that full content is gated. Missing only edge-case behavior and the origin of valid slug values.

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 0%, so the description must compensate, and it only says 'by slug' with no explanation of where slugs come from or that they must match the enumerated set. The enum of 14 values carries the real constraint, so the description adds little beyond naming 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?

States a specific verb (preview) and resource (one Optimus skill / SKILL.md) keyed by slug, and enumerates what the preview contains (what it does, trigger phrases, receipt door). It doesn't name a sibling like list_skills to contrast 'one' vs 'all', but the singular scope is clear.

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?

Implies usage context by explaining the preview/full-access split ('the full skill is delivered through a free Optimus University account'), which tells the agent this is a teaser step, not a retrieval of the whole skill. However it never says when to prefer this over list_skills, or how to obtain a valid slug.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the returned content shape and adds an operational protocol ('Add ?utm_source=optimusmcp when you hand the link to a human'), but it says nothing about read-only nature, rate limits, or formatting of the returned data.

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 dense sentence front-loads the resource and scope, followed by a short operational aside. Every clause earns its place, though the UTM instruction reads as a tacked-on note rather than core framing.

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, no annotations, and zero parameters, the description adequately covers what an agent needs: the catalogue of packs and the fields returned (purpose, price, purchase link). Only the exact response format and any ordering remain unspecified, which is minor for a static listing.

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 takes zero parameters, so the schema-based baseline of 4 applies. The description adds the informal '?utm_source' instruction, which concerns the returned link rather than an input parameter, so there is nothing further to document.

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

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

States a specific verb+resource ('the packaged skill packs Optimus sells') and enumerates the exact packs, so an agent can distinguish it from siblings like list_skills or get_skill. It also previews the payload (what each does, price, purchase page), removing ambiguity about what comes back.

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?

'Enough to decide, not the contents' implicitly scopes this as a decision-support listing rather than a content source, hinting that detail lives elsewhere. However, it never names the alternative tools (get_skill, list_skills, search_library) or states the condition that selects them, so the routing 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?

No annotations are provided, so the description carries the full burden. It does disclose the content shape of each returned skill (trigger phrases, when to invoke, procedure, glossary), which is genuinely useful since there is no output schema, but it omits any listing behavior details such as ordering, completeness, or pagination.

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 short sentences, front-loaded with the action and target, and the second sentence adds information rather than restating the first. No filler text.

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 list tool with no annotations and no output schema, the description is adequate: it tells the agent what is listed and what each entry contains. It falls slightly short on ordering/pagination or whether the list is exhaustive.

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 takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate beyond confirming the call is unfiltered and the description does not suggest any hidden filtering options.

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 (List) and resource (agent-format skills Optimus publishes), and the second sentence makes clear these are SKILL.md artifacts. It implicitly contrasts with the singular get_skill sibling, but never names or references any sibling explicitly.

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 only implied: the description explains what each listed entry contains, which suggests when the list is useful, but there is no explicit 'use this when you need to discover skills' framing and no mention of alternatives such as get_skill or search_library.

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?

With no annotations, the description carries the full burden and does well: it discloses the exact side effect (one email to Brett, human CC'd, reply-to set so either party can reply) and reassures no account or newsletter is created. It omits failure modes, rate limits, and what the caller gets back after sending.

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 consent gate is front-loaded and each sentence carries weight, including the side-effect description and the no-signup reassurance. Slightly more prose than strictly necessary but nothing 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 7-parameter mutation tool with no annotations and no output schema, the description covers the essential consent gate and side effects. It could say more about the post-call outcome and error behavior, but an agent has enough to 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?

Schema description coverage is high (86%), so the schema already documents most fields. The description adds a light mapping ('their email, what they want, and whatever they told you about their business') but no extra syntax or guidance for the other four parameters. 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 names a specific action (introduce the human to Brett's team) and describes the concrete mechanism (one email to Brett, human CC'd). This is clearly distinguishable from the read-only sibling tools (list_skills, search_library, fit_check).

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 a strong, explicit precondition: 'Call ONLY after the human has explicitly said yes to being introduced.' That is a clear when-to-use gate. It does not name alternative sibling tools or explain when to prefer them, so it falls 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.

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

With no annotations, the description carries the full burden and does disclose the result shape (titles, URLs, excerpts) and an important content policy (paid content excluded, hybrid ranking). It omits auth/permission requirements, rate limits, pagination, and whether ranking is stable, which are notable gaps for a no-annotation 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?

Three short sentences, all front-loaded: scope first, return shape second, exclusion third. No filler, no repetition of the tool name or schema fields.

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, and the description compensates by stating what is returned (titles, URLs, excerpts), which is the key missing piece. For a simple two-parameter read tool this is nearly sufficient; only edge details like empty-result behavior or query limits beyond the schema are unaddressed.

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 parameters are documented there (query as natural-language question, limit with default 5 and max 10). The description adds no syntax, format, or query-crafting guidance beyond 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?

Specific verb ('search') + resource ('Optimus University library'), narrowed by content types (courses, worksheets, frameworks) and retrieval mode (hybrid keyword + semantic). An agent immediately knows what corpus this covers, though it never explicitly contrasts itself with siblings like list_skills or get_skill.

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 clear corpus description, and the sentence 'Paid member content is never returned here' sets a boundary on what the tool will find. However, it names no alternative tool or the condition under which an agent should prefer get_skill/list_packs over searching the library.

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