freeport-nostr
Server Details
Search Freeport Nostr events by kind, tag & geohash radius (rides, services, reputation).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ptrinh/freeport
- GitHub Stars
- 15
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.9/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: creating intents, fetching events, profiles, raw queries, searching intents, and reputation. No overlap.
Most tools use the 'nostr_' prefix but one uses 'freeport_'. Verb patterns are mixed: 'nostr_profile' lacks a verb, while others follow verb_noun (create_post, get_event, search_intents). Readable but inconsistent.
6 tools is well-scoped for a Nostr/Freeport integration, covering creation, search, reputation, and general Nostr utilities without bloat.
Core functionality for Freeport intents (create, search, reputation) is covered, plus general Nostr tools. Missing update/delete for intents, but likely not needed given the domain.
Available Tools
6 toolsfreeport_create_postAInspect
Publish a Freeport intent — an OFFER (side "offer": driver/provider/seller) or a REQUEST (side "request": rider/buyer). Provide EITHER a secretKey (nsec or hex — the server builds, signs and publishes; use a DEDICATED agent key, never a personal one — it is used once and never stored) OR a pre-signed event (you sign locally; nothing secret reaches the server). Strict rate limits apply. Returns the published event id + addressable d.
| Name | Required | Description | Default |
|---|---|---|---|
| d | No | Stable id to republish/replace an existing post; defaults to random. | |
| side | No | offer = provider/seller/driver; request = buyer/rider. | |
| event | No | A complete, signed Nostr event (kind 32101/32102). Use instead of secretKey to keep keys off the server. | |
| title | No | ||
| market | No | Market key, e.g. "rideshare" or "service". | |
| relays | No | ||
| schema | No | Payload schema, e.g. "rideshare/1" or "service/1". | |
| topics | No | Topic `t` tags (area/category), e.g. ["vn_hanoi","vn_hanoi_ridesharing"]. | |
| window | No | ||
| payload | No | Intent payload (from/to/location, payment, etc.) per the freeport://protocol resource. | |
| geohashes | No | Geohashes for location-scoped discovery. Each is expanded into all its prefixes (precision 1-6) so radius searches at any precision match. | |
| secretKey | No | nsec or 64-hex private key. Used transiently to sign; never stored. Omit if passing a pre-signed `event`. | |
| expiresInMinutes | No | How long the post stays live (default 720). Max 30 days. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that secretKey is used once and never stored, that rate limits apply, and that the tool returns the published event id and addressable 'd'. It lacks details on error handling or behavior when both authentication methods are provided, but is otherwise transparent for a posting tool.
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, information-dense paragraph that front-loads the core purpose. Every sentence adds value (authentication options, security warning, rate limits, return value). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, no required ones, nested objects), the description covers the essential workflow: authentication, sides, return value, and rate limits. However, it does not clarify the interaction between 'event' and other parameters when a pre-signed event is used, nor does it specify if 'd' is mandatory for updates. The return value is stated, compensating for the lack 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?
The description adds significant meaning beyond the schema: it explains the trade-off between secretKey and event, the default behavior of the 'd' parameter, and how geohashes are expanded. With 77% schema coverage, the description enriches understanding of key parameters like 'side', 'secretKey', and 'geohashes'.
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 'Publish a Freeport intent' with specific verb and resource, and distinguishes between OFFER and REQUEST sides. It implicitly differentiates from sibling tools which are for reading/searching Nostr events, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use secretKey (with security warnings) versus a pre-signed event, and mentions strict rate limits. However, it does not explicitly state when not to use this tool or describe alternative tools for similar tasks, though sibling names imply their different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nostr_get_eventBInspect
Fetch one or more events by id. Returns the raw signed events.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| relays | No | Override the relay set for this call (ws/wss URLs, max 10). Defaults to the server relays. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions returning 'raw signed events' but does not disclose read-only nature, error behavior, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary words. Front-loaded with the core action and return format.
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, the description is minimally adequate but lacks details on batch behavior, error handling, or output structure.
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 50% (only relays has a description). The description adds no parameter-specific meaning beyond the schema; for example, 'ids' format or constraints are not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches events by ID and returns raw signed events, distinguishing it from sibling tools like nostr_profile and search tools.
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 (e.g., nostr_query_raw or search). No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nostr_profileAInspect
Fetch NIP-01 profile metadata (kind 0) for one or more pubkeys — name, about, picture, nip05, lud16, etc. Optionally include each author's most recent notes (kind 1). General-purpose: works for any Nostr user, not just Freeport.
| Name | Required | Description | Default |
|---|---|---|---|
| relays | No | Override the relay set for this call (ws/wss URLs, max 10). Defaults to the server relays. | |
| pubkeys | Yes | Hex pubkeys to fetch profiles for. | |
| recentNotes | No | If >0, also fetch up to this many recent text notes (kind 1) per pubkey. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions fetching metadata and optionally recent notes but omits details on return format, pagination, error handling, rate limits, or authentication needs. The behavioral coverage is significantly incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence front-loading the core purpose and fields. Every word contributes meaning, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic function but lacks details on return values, error cases, and parameter behavior like relay override. It could be more complete without becoming overly long.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters documented. The description adds context by explaining that 'recentNotes' optionally fetches kind 1 notes and that the tool works for any user. However, it does not significantly enhance the schema's explanations, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Fetch NIP-01 profile metadata (kind 0)' and specifies the resource (profile for one or more pubkeys). It lists example fields (name, about, picture, etc.) and distinguishes itself from sibling tools by noting it is 'general-purpose' and 'works for any Nostr user, not just Freeport.'
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 broad use ('general-purpose') but does not explicitly contrast with sibling tools like nostr_get_event or nostr_search_reputation. There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nostr_query_rawAInspect
Escape hatch: run an arbitrary NIP-01 filter (kinds/authors/ids/tags/since/until/limit). Use the typed tools above when they fit. Returns raw signed events.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ||
| tags | No | Tag filters, e.g. {"t":["vn_hanoi"],"g":["w3gv"]}. Keys are single tag letters. | |
| kinds | No | ||
| limit | No | ||
| since | No | ||
| until | No | ||
| relays | No | Override the relay set for this call (ws/wss URLs, max 10). Defaults to the server relays. | |
| authors | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It states returns 'raw signed events', implying read-only, but does not disclose potential hazards like high cardinality or server load. Minimal but adequate.
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 concise sentences: first defines purpose and scope, second provides usage guidance. No fluff, perfectly 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?
For a tool with 8 parameters, nested objects, and no output schema, the description covers the high-level purpose but lacks details on return format, error handling, pagination, or rate limits. Siblings are typed, so this is a fallback, but more context would help.
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 low (25%), and description merely lists parameter names without explaining their meaning or usage. The NIP-01 reference adds context, but does not compensate for missing parameter details.
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 an 'escape hatch' for arbitrary NIP-01 filters, listing filter components like kinds/authors/ids/tags/since/until/limit. It distinguishes itself from typed tools by emphasizing raw access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use the typed tools above when they fit', providing clear when-to-use and when-not-to-use guidance. 'Escape hatch' further signals it is for exceptional cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nostr_search_intentsAInspect
Search Freeport ride/service/product intents (offers & requests). Filter by side, category/area topic tags, and an optional geographic radius. Results are decoded, expiry-filtered, and sorted nearest-first when a point is given.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | Filter & sort by distance from this point. | |
| side | No | offer = drivers/providers/sellers; request = riders/buyers; any = both | any |
| limit | No | ||
| since | No | Only events created at/after this unix-seconds time. | |
| until | No | Only events created at/before this unix-seconds time. | |
| relays | No | Override the relay set for this call (ws/wss URLs, max 10). Defaults to the server relays. | |
| topics | No | Topic `t` tags to require (category/subcategory/area keys, e.g. "vn_hanoi", "ridesharing"). | |
| includeExpired | No | ||
| relaySideGeohash | No | Also narrow at the relay via a #g cover of the radius. Only effective if posts carry geohash-prefix tags; off by default. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses decoding, expiry filtering, nearest-first sorting, and filtering by side/topics/radius. Does not mention authentication or rate limits, but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.
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 9 parameters and no output schema, description explains filtering and output processing but lacks details on response structure (e.g., what fields are in decoded results). Adequate but incomplete.
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 78%, so baseline is 3. Description adds value by mentioning geographic radius and topics, but does not detail limit, includeExpired, or relaySideGeohash beyond schema.
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 the tool searches Freeport ride/service/product intents (offers & requests), with specific verbs and filters (side, topics, radius). It distinguishes from sibling tools like nostr_get_event or nostr_search_reputation.
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 when-to-use or when-not-to-use guidance. Context allows inference (e.g., for intents vs. events), but no exclusions or alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nostr_search_reputationAInspect
Fetch reputation signals for a pubkey: karma ratings (kind 32103) it received and deal receipts (kind 32104). Returns proven-deal count (both receipt halves present) and a karma summary. Note: scores are subjective and un-weighted here; do not treat as Sybil-proof.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| pubkey | Yes | Subject pubkey (hex) to look up reputation for. | |
| relays | No | Override the relay set for this call (ws/wss URLs, max 10). Defaults to the server relays. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the kinds queried, the returned metrics (proven-deal count, karma summary), and the subjective nature of scores. It does not mention destructive actions or authentication, which is appropriate for a read-only reputation lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action and key details, with no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema), the description explains what is returned (proven-deal count, karma summary) and a caveat. It is complete enough for an agent to understand the tool's output and limitations, though it could specify the format of the karma summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters described). The description adds context about kinds (32103, 32104) but does not add parameter-specific meaning beyond the schema. The 'limit' parameter lacks description in both schema and description, keeping the score at baseline 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 states 'Fetch reputation signals for a pubkey' with specific kinds (32103, 32104) and what is returned (proven-deal count, karma summary). It clearly distinguishes from sibling tools like nostr_profile (basic profile) and nostr_search_intents (search intents).
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 implicitly warns against over-trusting scores ('do not treat as Sybil-proof'), suggesting when NOT to use it for authoritative decisions. However, it does not explicitly state when to use it versus alternatives or provide prerequisites.
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!