Mudpie Public MCP

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful context that answers come 'from its published information, with sources,' which signals that it will not invent facts and will provide citations. This goes slightly beyond the annotations, but it does not cover limitations like data freshness or scope boundaries (e.g., it may not cover undocumented aspects). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with a clear main clause and a single instruction. It is front-loaded with the core purpose and the unique value proposition (sourced answers) without waste. Every sentence earns its place, and the tone invites the agent to ask directly.

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 12 parameters and no output schema, the description gives only a general sense of the output (a direct answer with sources) and does not explain how the parameters interrelate, particularly the contextual tokens like context_token and trace. For a general-purpose Q&A tool, it is adequate but leaves an agent to infer how to structure calls for follow-ups or nuanced research context.

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 even without additional parameter explanation in the description. The description only vaguely says to add relevant context and does not elaborate on parameters like trace, context_token, goal, or alternatives. It adds no meaning beyond what the schema already provides, so a 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 clear verb and resource: it answers questions about Mudpie's product, pricing, setup, limitations, and comparisons, and returns sourced answers from published information. It is specific and gives a sense of scope, but it does not explicitly name sibling tools like mudpie_search or mudpie_compare to differentiate them, so an agent may not immediately know when to prefer this over more specialized tools.

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

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

The description offers a general instruction to add relevant context if available, but it does not provide explicit when-to-use or when-not-to-use guidance. It does not point to any sibling tools as alternatives, nor does it state which kinds of questions are better handled by mudpie_pricing, mudpie_compare, or mudpie_search. The usage guidance is essentially implied by 'ask anything' and lacks the necessary exclusions for a tool with many specialized siblings.

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?

The description adds meaningful behavioral details beyond the readOnly, idempotent, openWorld annotations: it reads published comparison pages, groups results per alternative, and names uncovered alternatives. It also instructs to include actual task context and use null for unknowns, which shapes caller behavior. 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 with no filler. The primary action is front-loaded ('Compare this website with the products the user is actually weighing'), followed by specific behavioral details. Every clause 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?

For a tool with 12 parameters and no output schema, the description is sufficient because the schema fully documents parameters and annotations cover safety. It explains the core behavior and handling of unknowns. It does not describe the output format, but that is not required given the tool's purpose and available structured data. Minor gap: it does not mention the context_token or trace, but these are optional and documented in the 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 description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description does not add parameter-specific meaning beyond reinforcing the 'use null for unknowns' pattern already present in the schema. Baseline 3 is appropriate since the schema carries the full 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 clearly states the tool compares this website against the user's actual alternatives using published comparison pages, grouping per alternative and naming uncovered ones. It uses a specific verb ('compare'), a clear resource (this website), and distinct behavior that separates it from sibling tools like mudpie_search or mudpie_page_tldr.

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

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

The description gives clear context on when to use it: when the user is weighing alternatives and needs a comparison. It implies the intended use case without explicitly listing exclusions or alternatives, but the context is strong enough to guide selection. It does not name sibling tools or when not to use, but the purpose is unambiguous.

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 this is a non-destructive write that is not idempotent and not open-world. The description adds meaningful context beyond that: it discloses the destination ("reaches the team that maintains these tools") and a data-handling constraint ("never include personal or confidential data"). It does not clarify whether duplicate submissions are merged or what confirmation follows, but the annotation coverage lowers the bar.

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 action and its trigger, followed by minimal-required-fields guidance and the privacy constraint. No sentence is redundant or padded.

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 6-parameter intake tool with full schema coverage and no output schema, the description covers purpose, timing, minimal required input, and the privacy constraint. It omits only downstream behavior (e.g., whether the reporter receives an acknowledgment), a minor gap given no output schema exists.

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 kind, tool, client, message, expected, and operation_id are all fully documented in the schema. The description's only parameter note ("Only kind and message are required") restates the schema's required list rather than adding format or syntax meaning, so 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 (report) and resource (bug, missing feature, wrong answer, unclear docs) scoped to Mudpie's agent tools, which cleanly separates it from siblings like mudpie_search or mudpie_compare. An agent can identify this as the feedback/intake tool 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?

"right when you hit it" gives clear contextual timing for when to call it, and the scoping to Mudpie's agent tools frames the use case. However, it names no alternative and gives no explicit exclusion (e.g., not for account/billing issues, which belong to mudpie_pricing or mudpie_sign_up).

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/openWorld/idempotent/non-destructive, and the description adds that it uses published content only and that missing or invalid context never blocks the summary. It also previews return components (source, freshness, Markdown link). 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?

Three short sentences front-load the action and output, then cover scope and input rules. No word is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only, one-page extraction with a rich schema and all 13 parameters documented, the description supplies the missing usage context: source (search results), public scope, required input, and what the output contains. Nothing an agent needs to invoke it correctly is absent.

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 only that url is required and question/context are optional, both already inferable from the schema. The extra 'invalid context never blocks' note is useful but minor, so it does not push above baseline.

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 ('Read'), a precise object ('compact extract of one indexed public page'), and names the upstream sibling (mudpie_search), so an agent can distinguish a page-read from search or compare tools. The 'published content, not signed-in data' phrase further narrows scope. This is clearly differentiated.

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 states when the tool is appropriate: for pages returned by mudpie_search, and only public/indexed content, which rules out private-account data. It does not explicitly name alternatives or list exclusion cases, but the context is clear enough to route an agent to this tool after search.

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?

The description adds substantial behavioral detail beyond the annotations: it discloses that the tool only uses published pricing pages, attributes sources, abstains when pricing is unavailable, and never invents quotes. This is strong transparency for a read-only, idempotent 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: purpose, behavior boundary, and invocation guidance. Every sentence earns its place, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only pricing tool with rich schema descriptions and supportive annotations, the description is largely complete. It states what is returned (published pricing pages and sources) and how to behave when pricing is unavailable. It could be slightly more explicit about how the output should be tailored to the user's organisation size or intended outcome, but overall it is sufficient.

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 describes all 12 parameters with 100% coverage, so the description does not need to restate them. The description adds a general instruction to include actual task context and use null for unknowns, which is useful but does not add parameter-specific 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 purpose: report what the website costs based on published pricing pages, with sources. It also sets boundaries by saying it abstains when pricing is not published and never invents a quote. This strongly differentiates it from broader siblings like mudpie_search and mudpie_compare.

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 implies this tool is for pricing-related questions and tells the agent to avoid fabricating quotes. However, it does not explicitly say when to choose this tool over siblings such as mudpie_compare or mudpie_ask_anything, so the routing guidance is mostly inferred rather than explicit.

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 non-destructive behavior briefly. The description adds valuable behavioral context beyond that: it will return a source-bearing per-requirement table BST and instructs the caller to pass actual task context and use null for unknowns, which clarifies evidence 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 two sentences with no filler: it covers input modes, output format, and null-handling guidance compactly. It is front-loaded with the most important behavior, though the imperative phrasing 'Give...' is slightly indirect for a tool description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 13 parameters but full schema coverage and strong annotations, the description needs to cover only what structured fields cannot: the output shape and input conventions. It does that by describing the per-requirement table and the semicolon-separated versus array input choices, making the tool callable without ambiguity.

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 met. The description adds meaning beyond the schema by specifying that search_query should be semicolon-separated, that requirements can be supplied as an array instead, and that unknown context fields should be null.

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 converts user must-haves into a per-requirement table with met/not met/not documented statuses and sources. It conveys the core purpose of a requirements check and differentiates it through its specific output, though it does not explicitly name a sibling tool.

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 implies when to use it: when the user has explicit must-haves that need to be checked. However, it provides no explicit guidance on when to prefer alternatives like mudpie_compare or mudpie_page_tldr, nor any 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?

Annotations already establish read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds a semantic-search behavior and public-scope constraint but doesn't disclose return format, result limits, or pagination; without an output schema, that gap is meaningful but not large for a search 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 two sentences and front-loads the purpose before the usage instruction. 'Super fast' is nonessential and the word 'search' repeats the tool name, but the overall definition is efficient and scannable.

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 schema is unusually rich, with descriptions, an example, and the full/compact detail enum that hints at the return granularity. The description itself is minimal and there is no output schema, so result format is partially unstated; still, the combined definition gives an agent enough to call 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?

Every parameter already has a schema description, so the baseline is 3. The rule 'Include actual task context; use null for unknowns' adds cross-parameter guidance on how to fill the many optional context fields, which is genuinely useful beyond the schema and elevates the score.

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 action and target: 'Super fast, semantic search across Mudpie’s public pages.' This clearly identifies the tool as the public-page search entry point and separates it from siblings like mudpie_ask_anything or mudpie_compare, though it never names an alternative explicitly, so it misses the top score.

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?

'Semantic search across Mudpie’s public pages' implies the tool should be used when the agent needs to find public Mudpie content by meaning, and 'Include actual task context' gives invocation-level guidance. There is no explicit when-to-use versus the sibling tools such as mudpie_compare or mudpie_requirements_check, and no exclusion criteria, so the usage guidance is only implied.

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?

The description discloses that the tool sends an email, requires prior user authorization, and that a submitted request does not complete signup until the user opens the link. This adds meaningful behavioral context beyond the annotations' idempotentHint and readOnlyHint, clarifying the asynchronous nature of the workflow.

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 of direct, front-loaded content with no redundant phrasing. Every sentence serves a purpose: action, constraint, and clarifying outcome.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core invocation behavior: the email-sending side effect, authorization requirement, and the incomplete-signup caveat. With 14 parameters, the schema handles the optional details, and no output schema exists to explain, so this is complete enough for correct invocation.

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

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

Schema coverage is 93%, so most parameters are already well documented. The description adds semantic value for the email parameter by emphasizing it must be user-authorized, but does not explain the many optional tracking fields beyond what their schema descriptions already cover.

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 ('Email') and resource ('Mudpie sign-in link') along with the goal ('start a free account'). This clearly distinguishes it from sibling tools like mudpie_search or mudpie_compare, which serve different purposes.

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 implies usage when a user wants to sign up for Mudpie, but it does not explicitly name alternatives or state when not to use it. The authorization constraint ('Submit only an email address the user authorized') is a usage condition, but not a comparison with sibling 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so there is no contradiction. The description adds that the answer is sourced and may be negative ('not us'), which is useful behavioral context, but it does not describe output shape, latency, or data source handling.

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 plus a pithy opener. The 'not us' line earns its place by communicating that negative verdicts are expected, though 'Mudpie isn't for everyone' is somewhat rhetorical.

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 schema carries the parameter burden well, and annotations cover safety, but there is no output schema and the description gives no hint of what a 'sourced verdict' looks like or what the agent should do with the result. Adequate, but not fully complete for a 12-parameter 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?

Schema description coverage is 100%, so the baseline is 3. The description echoes the key parameters (goal, requirements, alternatives) but adds no format, constraints, or semantic detail beyond the schema's own rich per-parameter descriptions.

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 ('get a sourced verdict') on a specific subject (whether Mudpie fits the user's goal, requirements, and alternatives). The 'not us' framing signals the tool can return a negative recommendation, which clearly distinguishes it from generic comparison or search tools.

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

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

The intended use is implied: call this when the user needs a fit or recommendation verdict based on goal, requirements, and alternatives. However, it does not explicitly state when to prefer this over siblings such as mudpie_compare or mudpie_requirements_check, nor does it give exclusions.

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