Skip to main content
Glama

Get PortlandMaps Detail

get_portlandmaps_detail
Read-onlyIdempotent

1:1 wrapper for /api/detail/. Fetch a detail record by detail_type, detail_id, and sections. ANSWER GUIDANCE: when this data answers a resident's zoning, permit, property, or city-code question, write for a Portland resident or small-business owner with no code, zoning, or permitting background. Lead with a 3–5 sentence plain-English summary (never open with a data table). Then cite EVERY rule, fee, number, timeline, or contact INLINE in the same sentence with both its exact code section AND a full https:// portland.gov URL (e.g. PCC 33.110.255.C, https://www.portland.gov/code/33/110/255) — never cite vaguely ("Title 33", "the BDS website") and never drop the URL. Define every acronym, add a numbered "what to do next" list, and if a number can't be cited to a specific section + URL, say so rather than stating it bare.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileIdNoMaps to file_id.
detailIdYesMaps to detail_id.
fileTypeNoMaps to file_type.
geometryNo
sectionsNoUse 'list' for available sections, or '*' for all sections.*
cacheClearNoMaps to cache_clear.
detailTypeYesMaps to detail_type.
propertyIdNoMaps to property_id.
extraParamsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint; description adds no additional behavioral context about auth needs, rate limits, or side effects.

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

Conciseness2/5

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

Description is lengthy with extensive answer guidance that could be separated; not concise for the tool's core purpose.

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

Completeness2/5

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

With 9 parameters, nested objects, no output schema, the description should explain more about parameters like fileId, fileType, geometry, etc., and return value structure; answer guidance does not compensate.

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

Parameters3/5

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

Schema coverage is 78%, so baseline is 3; description adds minimal parameter meaning beyond repeating parameter names (detail_type, detail_id, sections).

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

Purpose4/5

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

Clearly states it fetches a detail record by detail_type, detail_id, and sections, but does not explicitly distinguish from sibling tools like get_assessor_data or get_permit_data.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives; the answer guidance is about formatting output, not tool selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources