EPK Properties Public Knowledge MCP

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) already convey the safety profile. The description adds the scoping constraint of requiring a prior search result, which is useful, but it doesn't describe return format or any additional behavioral traits. This meets the bar set by the 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 one concise sentence, front-loaded with the primary use case and no wasted words. It is appropriately sized for the tool's simplicity.

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

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

Given the tool's low complexity (1 parameter), rich annotations, and presence of an output schema, the description is sufficient. It clearly identifies when to use it and what it returns, without needing to explain return values since the 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?

The only parameter 'id' is fully described in the schema as 'Document ID returned by search.' The description reinforces this by mentioning 'prior search result,' but adds no new semantic detail beyond the schema. With 100% schema coverage, a baseline of 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 clearly states the tool fetches the full public property or guide document after a prior search. It uses a specific verb ('fetch') and resource ('full public property or guide document'), which somewhat distinguishes it from siblings like get_guide_section or get_property, though it doesn't explicitly name alternatives.

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 explicitly says 'Use this when the user wants the full public property or guide document identified by a prior search result,' giving a clear condition for use. It implies that search should happen first, but it doesn't explicitly mention 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?

Annotations already declare readOnly, idempotent, and non-destructive. The description adds useful context beyond annotations: the section is 'public' and 'complete', and the ID must come from search_guides. This gives the agent expectations about dependencies and data scope without contradicting 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 a single, front-loaded sentence with no filler. Every word contributes: 'complete', 'public', 'EPK guide section', and 'identified by search_guides' all earn 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 one-parameter getter with a rich schema, output schema, and full annotations, the description is quite complete. It conveys the main use case, the dependency on search_guides, and the nature of the response ('complete'). It does not explain what EPK stands for, but that is not necessary for the agent to invoke the tool 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 coverage is 100%; the id parameter already includes a pattern and description ('Guide section ID returned by search_guides'). The description reinforces this dependency but adds no new parameter-level meaning beyond the schema. 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 clearly states that the tool provides the complete public EPK guide section, and the phrase 'identified by search_guides' differentiates it from the search_guides sibling. However, it uses a usage directive ('Use this when...') rather than a direct verb like 'retrieves', so it stops short of a perfect 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?

The description explicitly tells the agent when to use this tool ('when the user wants the complete public EPK guide section') and references search_guides as the identifier source. It does not explicitly name alternatives to avoid, but the context is clear enough for a simple getter with distinct 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about returning 'full public details' and the UUID source, but does not disclose additional behavioral traits beyond that.

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 a single sentence that front-loads the usage condition and is free of any filler. Every word adds value.

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 tool is simple (2 parameters, output schema present), and the description adequately covers purpose and usage. However, the lack of parameter semantics for 'language' is a minor gap, so it is not a 5.

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 only 50% (property_id is described, language is not). The tool description does not compensate for the missing language parameter semantics—it only reinforces property_id via 'property UUID returned by search_properties'. This leaves the language parameter's purpose and default behavior unexplained.

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

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

The description clearly states the tool's function: 'get full public details for a property UUID'. It uses a specific verb ('get') and resource ('property UUID'), and distinguishes it from siblings by noting the UUID comes from search_properties.

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 explicitly tells when to use the tool: when the user wants full public details for a property UUID returned by search_properties. It provides clear context but does not explicitly mention when not to use it or alternatives.

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 read-only and idempotent behavior, so the agent knows it is a safe read operation. The description adds minimal behavioral context ('standard search tool', compatible with company knowledge) but does not mention return formats, pagination, or limitations. This is 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?

The description is concise at two sentences, front-loading the usage instruction. The second sentence adds some context but is slightly vague; nonetheless, there is no wasted verbiage.

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 tool with one parameter, strong annotations, and an output schema present, the description adequately explains its scope and usage context. It does not cover distinctions from sibling tools, but that is more relevant to usage guidelines. Overall, it is sufficiently complete.

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 provides 100% coverage for the single query parameter with a clear 'Natural-language search query' description. The tool description adds domain context (listings and guides) but no additional parameter-level detail, so the baseline score of 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 clearly identifies the tool as a search over EPK Properties public real estate listings and educational guides, with a specific verb and resource. It does not explicitly differentiate from sibling search tools like search_guides or search_properties, so it falls just 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?

Provides explicit usage context: 'Use this when the user wants to search...' and mentions compatibility with company knowledge and deep research. However, it does not discuss when to use alternatives or when not to use this tool, so it lacks 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which inform the agent this is a safe read-only operation. The description adds no additional behavioral context such as search execution details, result format, pagination, or language inference behavior, so its contribution beyond annotations is minimal.

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 a single sentence that immediately states when to use the tool and enumerates the relevant topics and countries. There is no redundant information or filler, making it highly efficient.

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

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

Given the tool's moderate complexity (5 parameters, output schema present, annotations available), the description covers the essential use case and domain. The output schema handles return structure details, and annotations cover safety. It lacks any mention of search behavior or limitations, but these are secondary given the schema and simple nature of the tool.

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

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

The schema description coverage is 40%, with query and language having descriptions but limit, offset, and country lacking them. The description mentions the topic list and the two countries, which helps interpret the query and country parameters, but it does not address pagination or other parameter details. It partially compensates for the coverage gap but does not fully map all parameters.

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 is phrased as a usage trigger ('Use this when...') but it clearly identifies the resource (EPK public guidance) and the topical scope (buying, taxation, regulations, etc.) in two specific countries. It distinguishes from property search siblings by focusing on guides rather than property records, though it never explicitly states the verb 'search'.

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 explicitly states when to use the tool: when the user asks about EPK public guidance on a specific list of topics in Panama or the Dominican Republic. It does not mention when not to use it or name alternative tools, but the criteria are clear and actionable.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the scope 'public' but does not disclose additional behavioral details like pagination, sorting, or default ordering. This is adequate but not rich, so a mid-range score is appropriate.

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 a single sentence, front-loaded with 'Use this when', and contains no redundant information. It is concise and structured effectively.

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

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

Given the tool's complexity (13 parameters, output schema present), the description is sufficient for guiding the agent on the core use case. The output schema covers return values, and the description captures the essential filter dimensions. It does not mention pagination or language details, but those are documented in the schema, so the description adds adequate contextual value.

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 46%, requiring some compensation from the description. The description lists the filter categories (country, sale/rent, property type, price, bedrooms, bathrooms, area), which helps map to parameters. However, it does not explain min/max semantics or the available enums, leaving some ambiguity for parameters without schema 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 clearly states the tool's verb ('find'), resource ('public EPK Properties listings'), and scope ('with explicit ... filters'). It distinguishes itself from the generic 'search' sibling by specifying that this is for public property listings with structured filters.

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 provides a clear 'when to use' condition: when the user wants to find public properties using specific filters. However, it does not explicitly mention when not to use it or suggest alternatives like 'get_property' for single-listing lookups, so it falls short of the top score.

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