EPK Properties Public Knowledge MCP

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context: the document is 'public' and 'full', and it requires an ID from a prior search result. This goes beyond the annotations by clarifying the data scope and source of the ID, though it does not describe error behavior or response format (output schema exists).

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 that directly states when and how to use the tool. Every word earns its place, with no excessive detail or repetition of schema/annotation information.

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 (1 parameter), has a complete input schema, and an output schema is present. Annotations cover safety and idempotency. The description provides the missing usage context (prior search result) and the document scope, making the description complete for the tool's complexity.

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 covers 100% of the parameter semantics with 'id' defined as 'Document ID returned by search.' The description reinforces this by saying 'identified by a prior search result,' but it does not add additional meaning beyond the schema. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly states the tool retrieves the full public property or guide document identified by a prior search result. The verb 'fetch' is implied and the resource is specific ('full public property or guide document'), which distinguishes it from siblings like get_guide_section (section-level) and search (returns results, not full documents).

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 provides a clear usage context: 'Use this when the user wants the full public property or guide document identified by a prior search result.' It implies the tool is for post-search retrieval but does not explicitly exclude alternatives like get_guide_section or get_property. This gives clear context without formal 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds useful context that the section is complete and public, but does not disclose additional behavioral details like error cases, auth requirements, or return format. This is adequate but not rich beyond 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 short, front-loaded sentence that fully conveys the tool's purpose and usage context. Every word earns its place, with no redundancy or filler.

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

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

For a simple, single-parameter read tool with rich annotations and an output schema, the description is complete. It explains what the tool returns (complete public guide section), how the ID is obtained (from search_guides), and the annotations cover safety. No significant missing 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%, and the single 'id' parameter already has a clear description ('Guide section ID returned by search_guides'). The tool description does not add any new parameter-level meaning beyond what the schema provides, so the baseline score of 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 clearly states this tool retrieves the complete public EPK guide section, using a specific resource type and scope. It distinguishes itself from sibling tools like search_guides by framing search_guides as the source of the section identifier, making the purpose unambiguous.

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 complete public EPK guide section identified by search_guides,' providing clear guidance on when to invoke this tool. It references search_guides as the related lookup step, though it does not formally state when-not to use the tool or name explicit alternatives beyond that implied workflow.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context about the combined response type and compatibility with company knowledge/deep research, which goes beyond annotations without contradicting them.

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, front-loaded with the primary purpose, and every sentence serves a distinct function: usage guidance and behavior/benefit. No redundancy or unnecessary detail.

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 output schema exists and annotations are rich, the description adequately covers usage, combined result behavior, and compatibility. For a simple one-parameter search tool, it is 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?

Schema coverage is 100% with the query parameter described as 'Natural-language search query'. The description does not add parameter-specific details, so the baseline 3 applies.

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

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

The description clearly states the tool's purpose: 'Use this for EPK public knowledge searches' and specifies it returns 'both result types in one response', distinguishing it from siblings like search_guides and 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?

It provides explicit usage guidance: 'always when one request combines property listings with guides, regulations, taxes, residency, relocation, or due diligence' and implies alternatives for non-combined queries via the 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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety traits. The description adds behavioral context by specifying the content scope (guides only, not properties) and that using 'search' merges both kinds, which is useful beyond 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, front-loaded with the purpose and alternative usage. Every word earns its place; it is concise and immediately actionable.

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 an output schema present, return values need no explanation. The description covers use cases, distinctions, and topical scope. It is slightly incomplete in not mentioning language handling, but that is already covered in the schema. Overall, it is well-rounded for the tool's complexity.

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%, so the description must compensate. It does so by enumerating query topics (buying, taxation, regulations, etc.) and geographic scope (Panama/Dominican Republic), giving meaning to the 'query' and 'country' parameters. It doesn't elaborate on limit/offset, but those are self-evident, and the schema provides defaults.

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 explicitly states the tool searches for public real estate guides on specific topics in Panama or the Dominican Republic. It uses a clear verb+resource combination and distinguishes itself from the sibling tool 'search' by clarifying that properties are excluded unless requested together.

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 provides explicit when-to-use guidance: 'Use this when the user asks only for EPK public guidance...' and an alternative: 'If the same request also asks for properties, use search instead'. This clearly delineates the boundary between search_guides and 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds behavioral scope: it only returns public listings with explicit filters, and clarifies the difference from search regarding guides/regulations. There's no contradiction. It doesn't disclose pagination or ordering, but output schema covers those.

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, front-loaded with the action and scope, ending with the alternative. Every word earns its place; no filler.

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

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

The description fully orients the agent: when to use, what filters to apply, and when to defer to search. With 15 params and an output schema, the description is complete for selection and invocation; any missing details like defaults are 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 67%, so the schema does most of the work. The description mentions the filter categories (country, sale/rent, property type, price, bedroom, bathroom, area) which map to parameters, but doesn't add semantics beyond what parameter descriptions already provide. It reinforces the filtering behavior but isn't strictly necessary.

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: retrieving public EPK Properties listings with specific filters. It uses a directive 'Use this when...' and specifies the resource (public EPK Properties) and action (search with filters), distinguishing it from siblings like search and search_guides.

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 provides usage guidance: 'Use this when the user wants only public EPK Properties listings...' and gives a direct alternative: 'If the same request also asks for guides or regulations, use search instead...' This is textbook when-to-use and when-not-to-use guidance.

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