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.
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.
Tool Definition Quality
Average 3.4/5 across 11 of 11 tools scored. Lowest: 2.6/5.
Each tool has a clearly distinct purpose, targeting different data types (assessor, permits, geometry, land use, sewer, etc.) with no overlap. The descriptions and endpoint mappings ensure an agent can easily distinguish them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_assessor_data, search_landuse_cases). The naming is predictable and uniform across the entire set.
With 11 tools, the server is well-scoped for an unofficial Portland city data portal. It covers essential data categories without being excessive or too sparse.
The tool surface covers the primary data retrieval needs for PortlandMaps, including geometry, assessor, permits, details, spatial queries, land use, sewer, and address suggestions. Missing operations like write/update are not expected for a read-only data access layer.
Available Tools
11 toolsconvert_geometryConvert GeometryBRead-onlyIdempotentInspect
1:1 wrapper for /api/geometry/. Convert geometry between ESRI, WKT, GeoJSON, GPolyline, and EncodedGPolyline.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description confirms it is a conversion operation, which aligns with these hints. No additional behavioral details (e.g., error handling, performance) are provided, but the simple conversion nature doesn't demand more.
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 efficiently communicates the tool's nature (wrapper), the input/output format (geometry), and the supported formats. No extraneous information, and key details are 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?
Given the lack of an output schema, the description should clarify what the tool returns (e.g., converted geometry as a string, format, error handling). It does not. Additionally, with low schema coverage, the description is incomplete in explaining parameter semantics. The tool's simplicity doesn't fully excuse these omissions.
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 only 25% of parameters described in the schema (only 'geometry' has a brief description), the description should add meaning for the enum parameters ('from', 'to', 'srid'). However, it does not explain the enum values or the purpose of 'srid'. The conversion formats are standard, but the lack of explanation for spatial reference IDs is a gap.
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: it is a 1:1 wrapper for a specific API endpoint that converts geometry between five named formats. This is specific and uniquely distinguishes it from all sibling tools, which deal with data retrieval and lookups, not format conversion.
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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, constraints, or situations where another tool would be preferred. Users must infer usage solely from the purpose statement.
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 DataARead-onlyIdempotentInspect
1:1 wrapper for /api/assessor/. Search assessor records by address, property IDs, geometry, or assessor filters.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it is a '1:1 wrapper' and the search scoping (e.g., by address, geometry), neither contradicting nor repeating annotations. No additional behavioral traits (e.g., rate limits, auth) are disclosed, but annotations cover the safety profile adequately.
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 sentence, front-loaded with '1:1 wrapper for /api/assessor/.' It efficiently conveys purpose but includes the slightly redundant '1:1 wrapper' phrase. Otherwise, it is concise and to the point.
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 26 parameters, no output schema, and complexity of search criteria, the description is adequate but not complete. It misses details on pagination, default sorting, error handling, or response structure. Annotations provide safety context, but additional behavioral documentation would improve completeness.
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 62%, with many parameters having 'Maps to ...' descriptions. The tool description adds general search categories ('address, property IDs, geometry, or assessor filters') but does not detail individual parameters beyond what the schema provides. Baseline 3 is appropriate given moderate coverage and no significant extra value from description.
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 'Search[es] assessor records by address, property IDs, geometry, or assessor filters,' clearly indicating the verb (search) and resource (assessor records). It distinguishes from siblings like 'get_permit_data' or 'search_landuse_cases' by specifying the assessor domain.
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 implies usage for searching assessor records but provides no explicit when-to-use or when-not-to-use guidance. It lacks mention of alternatives or exclusion criteria, relying on sibling names for differentiation.
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.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it is a '1:1 wrapper', confirming direct API mapping. No contradictions, but little extra value 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?
Description is not concise; it contains a verbose 'ANSWER GUIDANCE' section that is irrelevant to the tool's definition. The first sentence is clear, but the remainder is an instruction for response formatting, bloating the description unnecessarily.
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?
Tool has 21 parameters, no output schema, and nested objects. Description lacks details on pagination, response structure, or typical usage patterns. The guidance paragraph is about response writing, not tool behavior, leaving gaps in completeness.
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 descriptions cover 62% of parameters, which is below the 80% threshold. The tool description adds no explanation of parameters or their usage. The 'ANSWER GUIDANCE' focuses on output formatting, not input semantics. Missing parameter context for the 21 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?
Description clearly states it is a wrapper for /api/permit/ and searches permit records. It differentiates from siblings like get_assessor_data and search_landuse_cases, which focus on different data types. However, the extensive 'ANSWER GUIDANCE' section is confusing and detracts from purpose clarity.
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?
No explicit guidance on when to use this tool versus alternatives. The 'ANSWER GUIDANCE' discusses how to use the output, not when to invoke the tool. Sibling tools suggest different domains, but the description does not help an agent decide.
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.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds no new behavioral traits (e.g., authentication needs, rate limits, error scenarios). The answer guidance text is not about tool 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?
The description is overly verbose with answer formatting advice that belongs elsewhere. The functional core is just two sentences; the rest is filler, making it inefficient for an agent to parse.
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, yet the description provides no hint about the response structure. It also only covers 3 of 9 parameters. The tool's complexity and parameter count demand a more thorough description.
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 78%, so baseline is 3. The description mentions three parameters (detail_type, detail_id, sections) but does not add meaning beyond their schema descriptions. It ignores other parameters like fileId, geometry, and cacheClear.
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 it is a wrapper for /api/detail/ to fetch a detail record by detail_type, detail_id, and sections. However, it mixes in extensive answer formatting guidance that is not part of the tool's purpose, causing some confusion.
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?
No guidance is provided on when to use this tool versus sibling tools like get_assessor_data or get_permit_data. The description implies it covers zoning, permit, property, or city-code questions, but does not distinguish from alternatives.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying exactly what is returned—detail_type values and their expected identifiers—enhancing understanding 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 a single, focused sentence with no unnecessary words, efficiently conveying the tool's purpose and output.
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 simplicity (no parameters) and the clear linkage to get_portlandmaps_detail, the description fully specifies the return content. No output schema is needed as the description directly states what is returned.
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 zero parameters and 100% schema coverage, baseline is 4. The description does not need to add param info, but its absence is fine since there are no 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 clearly states the tool returns the 'detail_type values' accepted by get_portlandmaps_detail and the expected identifier, distinguishing it from sibling tools like get_portlandmaps_detail itself.
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 implies usage when needing to know valid detail_type values for get_portlandmaps_detail. While it doesn't explicitly state when not to use, it provides clear context by naming the dependent tool.
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 MetadataBRead-onlyIdempotentInspect
1:1 wrapper for /api/agol/. Retrieve City of Portland ArcGIS Online metadata, webmaps, locators, and portal info.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| type | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds '1:1 wrapper for /api/agol/' which implies a direct API call but does not provide behavioral context beyond annotations. Minimal added value.
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, no wasted words. However the first sentence uses technical jargon ('1:1 wrapper') that may not be immediately clear. Efficient but could be slightly more front-loadable.
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 2 parameters, 1 required, and no output schema, the description should explain what each type returns and what 'id' refers to. It fails to do so, leaving the agent to guess.
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 0% with no property descriptions. The description lists example data types (metadata, webmaps, etc.) that loosely map to enum values, but does not explain the 'id' parameter or how it interacts with 'type'. Incomplete guidance for agent.
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 verb 'retrieve' and the resource 'City of Portland ArcGIS Online metadata, webmaps, locators, and portal info'. It distinguishes from sibling tools that cover different data domains like assessor, permits, etc.
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?
No explicit guidance on when to use this tool vs siblings. The description implies it's for AGOL data but doesn't provide when/why to choose it over alternatives like search_landuse_cases or get_permit_data.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| buffer | No | ||
| detail | No | ||
| include | No | ||
| geometry | Yes | ESRI JSON geometry in wkid 2913, 3857, or 4326. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by listing example layers (row, taxlot, etc.) but does not detail behavioral traits like geometry format requirements, error handling, or response structure.
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, but includes technical jargon ('1:1 wrapper for /api/intersects/') that is not front-loaded. It is concise but could be more user-focused.
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 4 parameters, a nested object, and no output schema, the description fails to explain return values, pagination, error handling, or limits. It only mentions layers, leaving significant gaps for an 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 25%, with only geometry described. The description clarifies that layers like 'row' and 'waterbody' correspond to the include parameter, adding meaning beyond the enum list. However, buffer and detail parameters are 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 is a spatial intersection query against named city layers, using 'query' verb and 'intersects' resource. It distinguishes from siblings like get_assessor_data or convert_geometry by focusing on spatial intersection.
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 implies use for spatial intersection queries but does not explicitly state when to use this tool versus alternatives (e.g., search tools). No when-not or alternative tool guidance is provided.
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.
| 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
| Name | Required | Description |
|---|---|---|
| rings | Yes | |
| title | No | |
| basemap | No | |
| areaSqFt | Yes | |
| setbacks | No | |
| buildings | No | |
| neighbors | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds context about fetching data from Portland's public ArcGIS layers, rendering in specific hosts, and the overlay behavior, going beyond annotations without contradiction.
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 front-loaded with the main purpose and structured with clauses. While slightly wordy, every sentence contributes value, and the overall length is reasonable for the complexity.
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 complex tool with 6 parameters, multiple data sources, and rendering hosts, the description covers input methods, optional toggles, data provenance, and compatibility. It is sufficiently complete without needing to explain return values due to the presence of an output 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?
With 100% schema coverage, the baseline is 3. The description adds meaning by explaining the workflow, the effect of basemap and includeContext, and the coordinate system for rings, providing value beyond the schema alone.
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 renders a property's lot as an interactive SVGI with multiple overlays. It specifies the resource (property lot) and the action (render as interactive UI component), and distinguishes from siblings like convert_geometry and get_assessor_data by focusing on visual rendering.
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 explains two input methods (detailType+detailId or rings) and optional parameters like basemap and includeContext. It provides clear context for usage, but does not explicitly state when not to use it versus alternatives.
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 CasesBRead-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.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is already clear. The description does not contradict these but adds no additional behavioral context beyond the search action. With annotations covering core traits, a score of 3 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 bloated with a large block of answer guidance that is unrelated to the tool's input or behavior. This extraneous text harms conciseness and should be moved elsewhere. Only the first sentence is directly relevant to the tool's purpose.
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 19 parameters and no output schema, the description should cover pagination, response format, and constraints. It does not mention what the response contains, how pagination works, or any limitations. The answer guidance hints at data types but is insufficient for operational completeness.
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 68%, meaning most parameters are documented in the schema. The tool description does not add any parameter-specific meaning beyond what the schema provides. For high coverage, the description need not compensate extensively, but it adds no extra value.
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 begins with '1:1 wrapper for /api/landuse/. Search land use review cases, including Historic Resource Review and Tree Review.' This clearly states the tool's purpose with a specific verb and resource, and distinguishes it from sibling tools like get_permit_data or search_sewer_records by focusing on land use cases.
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 contains extensive answer guidance for output formatting but lacks guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when-not-to-use, or explicit comparisons to sibling tools such as get_assessor_data or lookup_agol.
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 RecordsBRead-onlyIdempotentInspect
1:1 wrapper for /api/sewer/. Search sewer assets, as-builts, and easements.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds that it is a '1:1 wrapper' but provides no additional behavioral context beyond what annotations cover.
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, efficient sentence with no redundancy. It is appropriately short but could benefit from slight restructuring to front-load the core purpose better.
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 24 parameters and no output schema, the description is too minimal. It does not explain return values, pagination, or parameter relationships, leaving the agent under-informed for complex use.
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 63%, so the schema already documents many parameters. The description only adds context for the 'type' parameter by naming the record types. This marginal improvement justifies a 3.
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 it is a search tool for sewer assets, as-builts, and easements via a specific API endpoint. However, it does not differentiate from siblings like search_landuse_cases, but the purpose is 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?
No guidance on when to use this tool versus alternatives. The context of use is implied by the tool's name and description, but no explicit when/when-not/alternatives are provided.
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.
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that it is a direct API wrapper and lists searchable entity types (addresses, intersections, landmarks, IDs). This goes beyond annotations, though it omits pagination details and result format.
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 bloated with answer guidance that is irrelevant to tool invocation. The essential functional description is concise ('1:1 wrapper...'), but the extraneous instructions (writing for residents, citing rules) take up space and could mislead. A clean separation would improve conciseness.
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?
Despite annotations covering safety, the description lacks critical context: no explanation of return format, pagination behavior, or defaults for the many parameters. Without an output schema, the agent needs to know what the tool returns to integrate effectively. The answer guidance assumes result structure but doesn't define it.
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 21 parameters but only 19% schema description coverage, the description adds minimal value. It only explains the 'query' parameter (search term) and mentions 'altIds' and 'altCoords' via schema refs. The answer guidance does not explain parameters, leaving most parameters opaque for the agent.
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: a 1:1 wrapper for /api/suggest/ that searches PortlandMaps autocomplete for addresses, intersections, landmarks, or IDs. The purpose is specific and distinguishes it from sibling tools like get_assessor_data or get_permit_data, though the inclusion of answer guidance slightly dilutes clarity.
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?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when to prefer this over other search tools, or typical workflows (e.g., using this before get_portlandmaps_detail). 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.
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!