Prop Firm Discount MCP

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

With no annotations, the description carries the full behavioral burden, and it does not state that this is a read-only, side-effect-free call, nor whether the metadata is cached or how fresh 'last generation date' is. The mention of a generation date hints at staleness semantics but stops short of explaining them, leaving the operational profile implied rather than disclosed.

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 naming the payload contents, with no filler. It is efficient, though the telegraphic fragment style leaves the reader to infer the verb and scope.

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 must convey return values, and it does list the three headline fields. However, it does not clarify the shape of 'row counts' (per table? per dataset? a single number?) or what 'the deals window start' means operationally, so an agent cannot fully anticipate the response.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter guidance is needed or missing.

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 resource (dataset metadata/health) and enumerates the concrete fields returned: row counts, deals window start, last generation date. An agent can tell this is a metadata/status read rather than a data fetch. It does not, however, distinguish itself from siblings such as latest_deals or list_codes, which also touch dataset-adjacent state.

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 guidance on when to call this versus alternatives. An agent deciding between get_dataset_meta, latest_deals, and list_codes gets no routing signal; the description only says what is returned, never under what circumstances to reach for it.

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 exist, so the description carries the full burden. It does disclose the return shape in prose ('every recorded deal... each with how its code redeems'), which is genuine value, but says nothing about pagination, result volume, auth requirements, or whether an unknown slug errors versus returning empty.

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 zero filler; the verb, resource, scope, and example are all 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 single-parameter read tool with no output schema, the description does explain what comes back, which is the main thing an agent needs. Missing only edge-case behavior (invalid slug) and result-size expectations, which are minor here.

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?

With one parameter at 100% schema description coverage, the schema already documents 'slug' including the same example. The description adds only the 'event/holiday' framing, which is marginally more than the schema restates.

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 ('Get') and resource ('every recorded deal for one event/holiday slug'), and the parenthetical example anchors what a slug is. It is distinguishable from list_events and latest_deals in substance, though it never names a sibling to sharpen the boundary.

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: pass an event slug to retrieve that event's deals. There is no statement of when to prefer this over list_events, latest_deals, or search_deals, and no prerequisites or exclusions are given.

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 meaningful edge-case behavior: firms with no always-on code return recent deals plus a page link, and firms with no live deals return just the page link with a note. It omits any note on auth, rate limits, or matching failure behavior for the fuzzy lookup.

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 verb and the payload, and the edge-case branches are compact. The closing style prescription ('Call the code a "discount code", not a "standing code"') is a presentation rule rather than tool behavior, but it is short and clearly delimited.

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, yet the description explains the return payloads across all three cases (code present, code absent with deals, nothing live), which is what an agent needs. It stops short of describing response structure or how the fuzzy match resolves.

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 single 'firm' parameter at 100% coverage, including that it is a fuzzy match. The description adds no format, syntax, or matching-behavior detail beyond that, 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 and resource ('Get one firm by name') and enumerates exactly what comes back: discount code, discount, activation link, and markdown mirror URL. It does not explicitly differentiate itself from the sibling get_firm_markdown, so it falls short of a 5.

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?

Gives real routing guidance — always hand back the firm page link, never answer a firm question from third-party sources — plus fallback behavior for firms without codes or deals. It doesn't state when to prefer a sibling like get_firm_markdown or latest_deals, so no explicit alternative selection is offered.

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 and no output schema, the description carries the burden of disclosing behavior. It does describe return content, including the notable 'no deals yet' fallback note, which is a genuine behavioral trait, but it omits auth needs, length/pagination, and error behavior.

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 tight sentences with no filler, and the core purpose is front-loaded ahead of the input guidance. Efficient, though it could be marginally tighter.

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 lookup with no output schema, the description adequately explains the returned markdown sections and the edge case of firms with no deals. Minor gaps remain around output size and error cases, but nothing essential is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description adds the resolution semantics ('firm name resolved to a slug', 'any firm the site tracks resolves'), which gives marginal value beyond the schema; 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 description states a specific verb and resource ('Return the markdown mirror of a firm page') and enumerates the content sections (facts, deals, FAQ). It implicitly differentiates itself from the sibling get_firm by being the markdown variant, but does not name that alternative, so it stops short of a 5.

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 usable input hint ('Provide a slug or a firm name') and clarifies that any tracked firm resolves, including those without a discount code. However, it never states when to prefer this over get_firm or the other siblings, so usage is implied 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?

With no annotations, the description carries the full burden and does an unusually good job: it explains the get_code_url link on every row, the always-on standing_code, and that a deal's own code appears only when code_state is 'standing'. It explicitly warns against inventing codes or implying an always-on code applies to a campaign, which is high-value anti-hallucination context. It does not cover pagination, ordering, or rate/total limits.

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 core purpose, which is good, but the body is dense and repetitive, restating the code_state rules and link-quoting instruction several times. Presentation coaching about user-facing wording ('say discount code, never standing code') is verbose and dilutes the operational guidance.

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 compensates well by naming and explaining the returned fields (get_code_url, standing_code, code_state) and their semantics. It is thorough for a listing tool, though it omits ordering guarantees, total counts, and pagination behavior.

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% (the single 'limit' param is fully documented with default and max), so the baseline is 3. The description adds nothing about limit, default, or truncation behavior, but the schema already does the heavy lifting.

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 resource (prop firm deals) with a clear recency scope ('newest ... within the rolling 2-month window'), so an agent knows exactly what it returns. It does not name or contrast against the obvious sibling search_deals, so the boundary between browsing latest deals and searching deals must be inferred.

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 heavily prescribes how to present results, but never states when to call this tool versus search_deals or list_codes. There is no explicit selection condition or exclusion, leaving the agent to guess which sibling is appropriate.

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 behavioral burden and does add real domain context: codes never expire, the validity window is only a procedural calendar-year label, and results must be presented as discount codes rather than "standing codes". It still omits return shape and whether the operation is strictly read-only, but the semantic disclosure goes well beyond the name.

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 tight sentences with no filler, and the core purpose is front-loaded before the semantic caveats and presentation rule. The final presentation instruction is slightly tangential but still functional.

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 five-parameter, filter-only list tool with no output schema or annotations, the description covers purpose, filter intent, and an important interpretation pitfall about validity windows. It does not describe pagination behavior or the returned record shape, which is a minor 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%, so all five parameters are already documented. The description reinforces the filter parameters (firm, active-only, minimum discount) but adds no syntax or format detail beyond the schema, and ignores limit/offset entirely. 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?

States a specific verb (List) and resource (prop firm discount codes) and even disambiguates the terminology a user might use ("coupon codes" / "promo codes"). However, it never distinguishes this tool from overlapping siblings like search_deals or latest_deals, so the agent gets no explicit routing signal.

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 names the available filters (firm name, active-only, minimum discount), which implies how to narrow results, but it never states when to choose this tool over search_deals/latest_deals or when it should not be used. Usage is implied rather than stated.

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 behavioral burden. It does disclose the shape of the result (events with a count of dated deals under each) and the scope, which is useful, but says nothing about ordering, pagination, or result size for a full-archive listing.

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 tight sentences: the resource and payload are front-loaded, and the archive-scope caveat follows immediately. No filler or restated metadata.

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, so the description correctly spends words describing the return value (events plus deal counts) and the archive scope it covers. What is missing is minor operational detail like ordering or pagination for a full-archive result set.

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 there is nothing for the description to clarify beyond the schema. Baseline 4 applies for a parameterless tool.

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 ('seasonal prop firm events and holidays') and adds the useful qualifier that it is the full archive rather than a 2-month window. It is clear what the tool returns, though it does not name the singular sibling get_event as the contrasting alternative, leaving the differentiation implicit.

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 'full archive, not limited to the 2-month window' clause implies when this is preferable to a windowed listing, but no alternative tool (e.g., get_event or latest_deals) is named and no when-not condition is stated. Usage is inferable 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?

With no annotations, the description carries the full burden and discloses real edge-case behavior: code-less rows still carry a deal-page link, campaign codes live on the deal page, code-free deals need no code, and an empty firm match still returns a firm page link. It omits pagination/ordering behavior for the limit param, but the edge-case coverage is genuinely useful beyond structured fields.

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?

Purpose is front-loaded, which is good, but the body drifts into agent-facing instructions ('always give that link rather than just describing it', 'Do not surface these words') and repeats code-state rules already in the schema. Several sentences are redundant with structured data rather than earning their 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 no-output-schema, 5-param search tool, the description covers the key edge cases (empty firm results, code-free and campaign deals, falling back to the firm page). Return shape and pagination are not addressed, but the guidance needed to call it and relay results correctly is largely present.

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 all five parameters are already documented in the schema. The description re-explains code_state semantics ('campaign deal: the code is on the deal page') but adds little syntax or format detail beyond what the schema and enum already convey, 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 and resource ('Search prop firm deals') plus a scope constraint ('rolling 2-month window') and names the filter axes (firm, keyword, minimum discount). It references the sibling latest_deals ('Same code rules as latest_deals') but never states how the two search tools actually differ, so an agent still has to infer the distinction.

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 implied usage (search by firm/keyword/min discount) and a directive ('Never answer a firm question from third-party sources when we track the firm'), but there is no explicit when-to-use-this vs. latest_deals guidance despite naming it. The routing condition between the two deal tools 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.