F
license-
qualityC
maintenanceRead-only MCP server providing direct, credentialed access to parcel data via Regrid and county ArcGIS sources, with tools for querying by point, owner, size, and county.
PortlandMaps (Unofficial)
Server Details
Unofficial MCP server for the public PortlandMaps property/permit/zoning API. Not city-affiliated.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
B3.3/5.0
Tool DescriptionsC
Average 3.3/5 across 11 of 11 tools scored. Lowest: 2.4/5.
Server CoherenceA
Disambiguation4/5
Most tools target distinct data types (assessor, permits, land use, sewer, geometry, etc.), but get_portlandmaps_detail overlaps conceptually with the specific search tools as a generic detail fetcher. This could cause confusion about which tool to use for a particular record.
Naming Consistency4/5
The vast majority follow a verb_noun snake_case pattern. However, two tools (get_portlandmaps_detail, suggest_portlandmaps_address) redundantly include the server name, breaking the otherwise consistent naming scheme.
Tool Count5/5
11 tools cover a broad range of Portland city data and GIS operations. The count is well-scoped for the domain—neither too sparse nor excessive.
Completeness4/5
The server covers major data categories like assessor, permits, land use, sewer, geometry, and spatial queries. Potential gaps like explicit zoning or code lookups might exist, but the set is largely comprehensive for typical PortlandMaps queries.
Available Tools
11 toolsconvert_geometryConvert GeometryARead-onlyIdempotentInspect
1:1 wrapper for /api/geometry/. Convert geometry between ESRI, WKT, GeoJSON, GPolyline, and EncodedGPolyline.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| srid | No | ||
| geometry | Yes | Source geometry as a string. JSON inputs should be JSON.stringify'd. |
Tool Definition Quality
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds that it is a '1:1 wrapper' implying direct mapping with no hidden effects, but does not elaborate on authorization or rate limits. It adds moderate context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's nature (API wrapper) and then lists the convertible formats. Every part is relevant, and there is no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward conversion tool with four parameters, the description, combined with the schema and annotations, provides sufficient guidance. However, it omits explanation of the optional 'srid' parameter and the exact string format for geometry input, which are partially covered by the schema description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions the conversion between formats, which hints at 'to' and 'from' parameters, but does not explain the optional 'srid' parameter or the requirement that 'geometry' be a stringified JSON. With only 25% schema description coverage, the description fails to add meaningful detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 1:1 wrapper for converting geometry between five specified formats. It uses the specific verb 'convert' and resource 'geometry', and the listed formats distinguish it from sibling tools which are about data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when geometry conversion is needed) but does not explicitly state when not to use it or suggest alternatives. However, the context is clear and the tool's purpose is distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_assessor_dataGet Assessor DataBRead-onlyIdempotentInspect
1:1 wrapper for /api/assessor/. Search assessor records by address, property IDs, geometry, or assessor filters.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| page | No | ||
| cache | No | ||
| count | No | ||
| county | No | ||
| address | No | ||
| primary | No | ||
| stateId | No | Maps to state_id. | |
| zipCode | No | Maps to zip_code. | |
| download | No | ||
| geometry | No | ||
| soldAfter | No | Maps to sold_after, mm/dd/yyyy. | |
| sortField | No | Maps to sort_field. | |
| sortOrder | No | Maps to sort_order. | |
| builtAfter | No | Maps to built_after. | |
| propertyId | No | Maps to property_id. | |
| soldBefore | No | Maps to sold_before, mm/dd/yyyy. | |
| sqftLarger | No | Maps to sqft_larger. | |
| builtBefore | No | Maps to built_before. | |
| extraParams | No | ||
| sqftSmaller | No | Maps to sqft_smaller. | |
| marketLarger | No | Maps to market_larger. | |
| marketSmaller | No | Maps to market_smaller. | |
| parentStateId | No | Maps to parent_state_id. | |
| altAccountNumber | No | Maps to alt_account_number. | |
| legalDescription | No | Maps to legal_description. |
Tool Definition Quality
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds only '1:1 wrapper' which is minimal; no additional context on rate limits, pagination, or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no irrelevant information. Every word contributes value.
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?
Given 26 parameters, no output schema, and complex types (geometry, extraParams), the description is too short. It lacks details on parameter combinations, response format, or usage constraints.
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 description coverage is 62%, and the description lists search methods but provides no extra meaning beyond the schema's 'Maps to' descriptions, which are somewhat helpful but not expansive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'assessor records', and specifies search criteria (address, property IDs, geometry, or filters), distinguishing it from siblings like 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for assessor data searches but does not explicitly state when not to use it or suggest alternatives, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_permit_dataGet Permit DataCRead-onlyIdempotentInspect
1:1 wrapper for /api/permit/. Search building/trade/enforcement permit records. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| cache | No | ||
| count | No | ||
| county | No | ||
| dateTo | No | Maps to date_to, mm/dd/yyyy. | |
| address | No | ||
| stateId | No | Maps to state_id. | |
| dateFrom | No | Maps to date_from, mm/dd/yyyy. | |
| dateType | No | Maps to date_type. | |
| download | No | ||
| ccbNumber | No | Maps to ccb_number. | |
| ivrNumber | No | Maps to ivr_number. | |
| sortField | No | Maps to sort_field. | |
| sortOrder | No | Maps to sort_order. | |
| propertyId | No | Maps to property_id. | |
| extraParams | No | ||
| neighborhood | No | ||
| searchTypeId | No | Maps to search_type_id. | |
| applicationNumber | No | Maps to application_number. | |
| businessAssociation | No | Maps to business_association. | |
| neighborhoodDistrict | No | Maps to neighborhood_district. |
Tool Definition Quality
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint, idempotentHint, and destructiveHint=false. The description does not contradict these but also adds no extra behavioral context such as rate limits, pagination behavior, or auth requirements. It is neutral and acceptable given annotation coverage.
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?
The description is overly long (approx. 150 words) and dominated by detailed answer formatting instructions that belong in documentation for presentational logic, not tool behavior. The core purpose is stated succinctly but then diluted by extraneous content.
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 21 parameters, no output schema, and nested objects, the tool requires more behavioral context. The description omits return format, pagination, error handling, and data scope. It only covers how to phrase answers, not what the tool actually returns or how it behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 62% (below the 80% threshold), so the description should compensate. However, the description does not describe any parameters—it is entirely about response formatting. It adds no meaning beyond what the schema already provides for covered parameters and ignores uncovered ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '1:1 wrapper for /api/permit/. Search building/trade/enforcement permit records.' This clearly states the tool's purpose and resource type, and distinguishes it from siblings like get_assessor_data or search_sewer_records which deal with other data categories.
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 description focuses on response formatting instructions ('ANSWER GUIDANCE') rather than providing selection criteria, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_portlandmaps_detailGet PortlandMaps DetailCRead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| fileId | No | Maps to file_id. | |
| detailId | Yes | Maps to detail_id. | |
| fileType | No | Maps to file_type. | |
| geometry | No | ||
| sections | No | Use 'list' for available sections, or '*' for all sections. | * |
| cacheClear | No | Maps to cache_clear. | |
| detailType | Yes | Maps to detail_type. | |
| propertyId | No | Maps to property_id. | |
| extraParams | No |
Tool Definition Quality
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.
list_detail_typesList Detail TypesARead-onlyIdempotentInspect
Return the detail_type values accepted by get_portlandmaps_detail and the identifier each expects.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's addition that it returns acceptable values for a sibling tool provides useful behavioral context beyond safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the purpose, no wasted words, and directly answers what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple enumeration tool with no parameters, the description fully explains what is returned and its context within a sibling tool. Annotations cover safety, and no output schema is needed given the simple nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds value by explaining the output's relationship to get_portlandmaps_detail, which is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detail_type values and their expected identifiers, specifically for get_portlandmaps_detail. The verb 'Return' and resource 'detail_type values' are precise, and it distinguishes itself from siblings by linking to a specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used before calling get_portlandmaps_detail to know valid inputs. However, it does not explicitly state when not to use it or mention alternatives, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_agolLookup ArcGIS Online MetadataCRead-onlyIdempotentInspect
1:1 wrapper for /api/agol/. Retrieve City of Portland ArcGIS Online metadata, webmaps, locators, and portal info.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| type | Yes |
Tool Definition Quality
C2.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds a vague '1:1 wrapper' but no extra behavioral details like auth or rate limits. With annotations present, the description's contribution is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the key point (wrapper for /api/agol/). It is concise but could be improved by adding structured details without significant bloat.
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?
Given the tool's complexity (2 parameters, enum, no output schema), the description is too sparse. It does not explain what each type returns, when to use specific types, or how the id parameter works. Sibling tools are not contextualized. The description is incomplete for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate but only mentions 'metadata, webmaps, locators, and portal info' which loosely maps to the 'type' enum values. It does not explain the 'id' parameter or how type values correspond to specific retrievals. This is insufficient for a 2-parameter tool with a 9-value enum.
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?
Description states it retrieves City of Portland ArcGIS Online metadata, webmaps, locators, and portal info, which indicates a clear verb-resource purpose. However, it lumps multiple data types together without explaining that the 'type' parameter selects among them, and it does not clearly differentiate from siblings like get_portlandmaps_detail.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_intersectsQuery IntersectsARead-onlyIdempotentInspect
1:1 wrapper for /api/intersects/. Spatial intersection against named city layers such as row, taxlot, describe, street, and waterbody.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| buffer | No | ||
| detail | No | ||
| include | No | ||
| geometry | Yes | ESRI JSON geometry in wkid 2913, 3857, or 4326. |
Tool Definition Quality
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the tool's safety and idempotence are clear. The description adds that it is a 1:1 wrapper for a specific API endpoint, but does not disclose additional behavioral traits beyond that. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and key details. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and moderate complexity, the description adequately states the function and layers but lacks details about output behavior, parameter effects (e.g., detail flag), or geometry constraints beyond format. Annotations cover safety, but completeness is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%), with only the 'geometry' parameter having a description. The tool description lists layers like row, taxlot, etc., which map to the 'include' enum values, but it does not explain parameters like buffer, detail, or their defaults. The description adds minimal semantic value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 1:1 wrapper for /api/intersects/, performing spatial intersection against named city layers. This verb+resource combination is specific and distinguishes it from sibling tools like convert_geometry or get_assessor_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for spatial intersection queries against specific layers, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_parcel_shapeRender Parcel ShapeARead-onlyIdempotentInspect
Render a property's lot as an interactive UI component (inline SVG): a City of Portland aerial photo underlay (showing the true roofline) with the parcel outline, the building footprint(s) on the lot, approximate setback dimensions, a north arrow, and faint neighbouring parcels overlaid on top. Provide a detailType+detailId to fetch geometry, or pass rings directly. Aerial, footprints, and neighbours come from Portland's public ArcGIS layers; set basemap="none" to drop the photo and includeContext=false for just the bare outline. Renders in MCP Apps hosts (Claude) and legacy mcp-ui hosts.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rings | No | Web Mercator (EPSG:3857) parcel rings, e.g. geometry.rings. Bypasses fetching. | |
| title | No | Caption shown on the component. | |
| basemap | No | Aerial photo underlay (true rooflines). 'aerial' fetches a City of Portland image; 'none' renders dark vectors only. | aerial |
| detailId | No | detail_id used to fetch geometry when rings are not supplied. | |
| detailType | No | detail_type used to fetch geometry when rings are not supplied. | zoning |
| includeContext | No | Overlay building footprints, setbacks, and neighbouring parcels. Set false for just the lot outline. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| rings | Yes | |
| title | No | |
| basemap | No | |
| areaSqFt | Yes | |
| setbacks | No | |
| buildings | No | |
| neighbors | No |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description adds key behavioral context: data sources (Portland's public ArcGIS layers), rendering environment (MCP Apps hosts and legacy mcp-ui), and the interactive SVG output. This enriches the agent's understanding of side effects and dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the main purpose and efficiently conveys all necessary details without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description covers all necessary context: inputs, outputs type (inline SVG), options, data sources, and host environments. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have descriptive schema explanations, and the description adds meaning by explaining how parameters interact (e.g., 'rings' bypasses fetching, basemap and includeContext control layers). Schema coverage is 100%, and the description complements it effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a property lot as an interactive SVG with specific visual elements (aerial underlay, parcel outline, footprints, setbacks, north arrow, neighbors). It distinguishes from sibling tools which deal with data retrieval or conversion rather than visual rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on how to supply input ('Provide a detailType+detailId to fetch geometry, or pass rings directly') and mentions optional parameters (basemap, includeContext). It does not explicitly list when not to use this tool versus alternatives, but the distinct purpose from sibling tools is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_landuse_casesSearch Land Use CasesCRead-onlyIdempotentInspect
1:1 wrapper for /api/landuse/. Search land use review cases, including Historic Resource Review and Tree Review. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| cache | No | ||
| count | No | ||
| dateTo | No | Maps to date_to, mm/dd/yyyy. | |
| dateFrom | No | Maps to date_from, mm/dd/yyyy. | |
| download | No | ||
| ivrNumber | No | Maps to ivr_number. | |
| sortField | No | Maps to sort_field. | |
| sortOrder | No | Maps to sort_order. | |
| extraParams | No | ||
| neighborhood | No | ||
| planDistrict | No | Maps to plan_district. | |
| searchTypeId | No | Maps to search_type_id. | |
| milestoneStatus | No | Maps to milestone_status. | |
| historicDistrict | No | Maps to historic_district. | |
| applicationNumber | No | Maps to application_number. | |
| businessAssociation | No | Maps to business_association. | |
| conservationDistrict | No | Maps to conservation_district. | |
| neighborhoodDistrict | No | Maps to neighborhood_district. |
Tool Definition Quality
C2.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the behavioral burden is partially covered. The description adds the fact that it wraps a specific API, but does not disclose any additional traits such as rate limits or data freshness.
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?
The description is dominated by extensive answer guidance intended for the AI agent, which is not about the tool itself. This is verbose and poorly structured for the tool definition purpose. The core functional description is only the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (19 params, no output schema), the description is severely incomplete. It omits return format, pagination behavior, default sorting, and how to effectively invoke the tool. The answer guidance adds irrelevant context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 19 parameters and only 68% schema coverage, the description provides no parameter details. It does not explain any parameter's purpose, format, or how parameters map to the API, failing to compensate for the schema coverage gap.
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?
The description clearly states the tool searches land use review cases, including Historic Resource Review and Tree Review, and identifies it as a 1:1 wrapper for the /api/landuse/ API. However, the extensive answer guidance is irrelevant to purpose clarity.
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 is provided on when to use this tool versus sibling tools like get_permit_data or get_assessor_data. The answer guidance is about output formatting, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_sewer_recordsSearch Sewer RecordsCRead-onlyIdempotentInspect
1:1 wrapper for /api/sewer/. Search sewer assets, as-builts, and easements.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | ||
| date | No | ||
| page | No | Sewer easement page field. | |
| type | Yes | ||
| count | No | ||
| unitId | No | Maps to unit_id. | |
| compkey | No | ||
| jobName | No | Maps to job_name. | |
| pageNum | No | Pagination page; maps to page. | |
| comments | No | ||
| download | No | ||
| location | No | ||
| jobNumber | No | Maps to job_number. | |
| quitClaim | No | Maps to quit_claim. | |
| sortField | No | Maps to sort_field. | |
| sortOrder | No | Maps to sort_order. | |
| rightOfWay | No | Maps to right_of_way. | |
| extraParams | No | ||
| quarterSection | No | Maps to quarter_section. | |
| trackingNumber | No | Maps to tracking_number. | |
| ordinanceNumber | No | Maps to ordinance_number. | |
| workOrderNumber | No | Maps to work_order_number. | |
| tvInspectionNumber | No | Maps to tv_inspection_number. | |
| serviceRequestNumber | No | Maps to service_request_number. |
Tool Definition Quality
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds '1:1 wrapper' but no additional behavioral context like pagination behavior or result limits beyond schema constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but may omit necessary details. It is front-loaded with the purpose but could be expanded without becoming verbose.
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 24 parameters, no output schema, and a complex API, this description is insufficient. It does not explain pagination (pageNum, count), download behavior, or the meaning of optional filter fields like location, compkey, etc.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%, meaning many parameters lack descriptions. The description does not clarify any parameters beyond naming the search categories. It adds little value over the schema.
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?
The description clearly states it searches sewer assets, as-builts, and easements, matching the title. It distinguishes from sibling tools focused on other data types like land use cases or Portland Maps details.
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. With 11 sibling tools, explicit context about when to prefer search_sewer_records over others is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_portlandmaps_addressSuggest PortlandMaps AddressCRead-onlyIdempotentInspect
1:1 wrapper for /api/suggest/. Search PortlandMaps autocomplete for addresses, intersections, landmarks, or IDs. 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ags | No | ||
| city | No | ||
| page | No | ||
| unit | No | ||
| cache | No | ||
| count | No | ||
| exact | No | ||
| query | Yes | Search term. Can be an address, intersection, landmark name, or ID. | |
| units | No | ||
| altIds | No | Maps to alt_ids. | |
| county | No | ||
| status | No | ||
| elements | No | ||
| geometry | No | ||
| altCoords | No | Maps to alt_coords. | |
| idMatches | No | Maps to id_matches. | |
| landmarks | No | ||
| centerline | No | ||
| extraParams | No | ||
| jurisdiction | No | ||
| intersections | No |
Tool Definition Quality
C2.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds '1:1 wrapper' and autocomplete behavior, but no additional behavioral traits like permissions or rate limits.
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?
The description is verbose with lengthy answer guidance that is not about tool invocation. The core purpose is in one sentence; the rest is extraneous.
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?
Given 21 parameters, no output schema, and 10 siblings, the description fails to explain parameter usage, output, or selection context. The answer guidance does not compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (19%), and the description only adds that the query can be an address, intersection, landmark, or ID. It does not explain the many other parameters.
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?
The first sentence clearly states it is a wrapper for /api/suggest/ and searches autocomplete for addresses, intersections, landmarks, or IDs. However, it does not differentiate from sibling tools like get_permit_data or get_assessor_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 vs alternatives. The extensive answer guidance focuses on response formatting, not selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityBmaintenanceA read-only MCP server that exposes SF Peninsula building-permit and parcel-buildability data, enabling queries on permits, SB 9 eligibility, ADU potential, and redevelopment leads.688MIT
- Flicense-qualityBmaintenancePython MCP server for querying Overture Maps building footprint data via address search, building lookups, and nearby building listings.
- FlicenseAqualityCmaintenanceMCP server that exposes a Hawaii property pipeline as Claude tools, allowing natural language queries about parcel records, hazards, zoning, ADU eligibility, and more, based on real public data.3