Tides
Server Details
Tides MCP — NOAA Tides and Currents data
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-tides
- GitHub Stars
- 0
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 4/5 across 12 of 12 tools scored. Lowest: 2.9/5.
Most tools have distinct purposes, but ask_pipeworx and discover_tools overlap in helping find tools, and entity_profile/compare_entities both target entity data. Memory tools are clearly separate. Overall, ambiguity is low but not zero.
Naming conventions are mixed: some use verb_noun (ask_pipeworx, get_predictions) while others are noun_verb (entity_profile) or just noun (forget). No consistent pattern, but still readable.
12 tools is a reasonable count, but the server is named 'Tides' and only 3 tools are tide-related; the rest are generic Pipeworx utilities. This creates a scope mismatch that reduces appropriateness.
For tide data, the three tools (list_stations, get_water_levels, get_predictions) cover basic read operations adequately. However, the inclusion of many unrelated tools suggests the server is a general-purpose gateway, not focused on tides, leaving the tide domain incomplete.
Available Tools
13 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool 'picks the right tool, fills the arguments, and returns the result,' indicating autonomous decision-making. Since no annotations are provided, the description carries full burden, but it lacks details on limitations, potential errors, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with the main action. It includes examples for clarity, though the examples could be slightly more integrated.
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 simple input schema (one string parameter) and no output schema, the description adequately explains the tool's behavior. It covers the purpose, usage, and example queries, leaving little ambiguity for an AI agent.
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% and the parameter description is clear ('Your question or request in natural language'). The description adds value by explaining how the parameter is used (e.g., 'just describe what you need' with examples), but it doesn't add substantial semantic detail beyond the 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?
The description clearly states the tool's purpose: it answers plain English questions by selecting the best data source. It distinguishes itself from other tools by centralizing access to multiple sources, and it explicitly mentions that users don't need to browse tools or learn schemas, which contrasts with sibling tools like discover_tools or list_stations.
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 clear guidance on when to use the tool: 'just describe what you need' and provides examples. However, it does not explicitly state when not to use it or mention alternative tools for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_entitiesAInspect
Compare 2–5 entities side by side in one call. type="company": revenue, net income, cash, long-term debt from SEC EDGAR. type="drug": adverse-event report count, FDA approval count, active trial count. Returns paired data + pipeworx:// resource URIs. Replaces 8–15 sequential agent calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| values | Yes | For company: 2–5 tickers/CIKs (e.g., ["AAPL","MSFT"]). For drug: 2–5 names (e.g., ["ozempic","mounjaro"]). |
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 that it returns paired data and URIs and is a batch operation, but does not mention potential side effects, authentication needs, or data freshness. Adequate but not thorough.
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, zero waste. Every part adds value: purpose, per-type data, output format, and efficiency claim.
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, so description covers return values ('paired data + URIs') and specifics per type. For a comparison tool, this is fairly complete. Could mention pagination or response size, but not necessary for typical 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 coverage is 100%, so the baseline is 3. The description adds context on what data is returned per type but does not provide new details about the parameters themselves beyond what the schema already describes (enum, min/max, examples).
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: comparing 2–5 entities side by side, with specific data per type (company vs drug). It distinguishes from sibling tools by noting it replaces 8–15 sequential calls, and siblings are generic (ask, discover, 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?
The description gives clear context for when to use: comparing entities, and what data each type returns. It mentions efficiency gains over sequential calls but does not explicitly state when not to use or list alternatives; however, the sibling list provides contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the tool returns 'most relevant tools with names and descriptions,' implying a search/recommendation behavior. However, it doesn't disclose details like whether it uses semantic search, any latency, or side effects. It's adequate but not rich.
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?
Three concise sentences, no fluff. The most critical instruction ('Call this FIRST') is front-loaded. Every sentence adds value: what it does, how it returns results, and when to use it.
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 low complexity (2 params, no nested objects, no output schema), the description is complete. It explains the tool's role in a workflow (call first when many tools exist) and the input format. No gaps are apparent for an agent to misuse 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of the query parameter through an example ('analyze housing market trends'), which helps agents formulate effective queries. The limit parameter is also clarified with default and max values, but the description doesn't repeat schema details beyond that.
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: searching the Pipeworx tool catalog by describing a need. It explicitly says it returns the most relevant tools with names and descriptions, distinguishing it from other tools by its search-and-retrieve function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This provides clear guidance on prioritization and context, differentiating it from siblings like ask_pipeworx which likely answer questions directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
entity_profileAInspect
Full profile of an entity across every relevant Pipeworx pack in one call. type="company": SEC filings (recent), latest revenue/income/cash from XBRL, USPTO patents (assignee match), recent news (GDELT), and LEI (GLEIF). Returns pipeworx:// citation URIs for everything. Replaces 10–15 sequential agent calls. For federal contracts call usa_recipient_profile directly (too slow to bundle).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type. Only "company" supported today; person/place coming soon. | |
| value | Yes | Ticker (e.g., "AAPL") or zero-padded CIK (e.g., "0000320193"). Names not supported — use resolve_entity first if you only have a name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses it returns citation URIs and bundles multiple data types, indicating read-only behavior. Minor gap: no mention of error handling 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler. Front-loads purpose and enumerates data sources efficiently.
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?
Description is comprehensive for a read operation, noting return of citation URIs and listing contents. Lacks output structure details (e.g., format of returned data) but sufficient for an agent to decide to use 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?
Both parameters are well-described in schema, and the description adds valuable context: type limited to 'company', value accepts ticker or CIK, and suggests using resolve_entity for names. This significantly aids correct invocation.
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 retrieves a full entity profile across multiple packs, listing specific data types (SEC filings, XBRL, patents, news, LEI). It contrasts with sibling tools and advises an alternative for federal contracts.
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 says when to use (for comprehensive entity data) and when not (for federal contracts, use usa_recipient_profile). Also hints at prerequisite: use resolve_entity if only a name is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetCInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states deletion is destructive but provides no details on effects (e.g., irreversible? requires confirmation? error handling for non-existent keys?). The description is too minimal.
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?
A single, front-loaded sentence. Every word is necessary and sufficient. No fluff.
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 is destructive (delete) with no annotations, the description is incomplete. It lacks context on return values, idempotency, or behavior when key doesn't exist. Sibling tools like 'remember' likely have similar minimal descriptions, but a deletion tool needs more detail.
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%, so the description does not need to add much. It repeats 'key' as the memory identifier, which aligns with the schema description. No additional semantics beyond what the schema provides.
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 'Delete a stored memory by key.' clearly specifies the action (delete) and the resource (stored memory by key). It is distinct from siblings like 'remember' (store) and 'recall' (retrieve), though it could explicitly name these alternatives.
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 description does not mention when deletion is appropriate or any prerequisites (e.g., memory must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_predictionsBInspect
Get hi/lo tide predictions for a NOAA station over a date range. Dates must be formatted YYYYMMDD.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | End date in YYYYMMDD format (e.g. "20240107") | |
| begin_date | Yes | Start date in YYYYMMDD format (e.g. "20240101") | |
| station_id | Yes | NOAA station ID (e.g. "9414290" for San Francisco) |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of tide predictions returned |
| datum | Yes | Vertical datum reference (MLLW) |
| units | Yes | Measurement units (feet) |
| end_date | Yes | End date in YYYYMMDD format |
| begin_date | Yes | Start date in YYYYMMDD format |
| station_id | Yes | NOAA station ID |
| predictions | Yes | Array of hi/lo tide predictions |
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 does not mention whether the tool is read-only, any rate limits, or what happens if data is unavailable. It only specifies date format, leaving safety and side effects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose. The date format note is relevant but could be shorter. 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 moderate complexity (3 params, no output schema, no nested objects), the description is minimally adequate. It lacks detail on return format, error handling, or station ID lookup hints, but covers core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions). The description adds the date format note (YYYYMMDD) which is already in the schema, so minimal extra value. 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 verb (get) and resource (hi/lo tide predictions for a NOAA station) and specifies the date range constraint. This distinguishes it from siblings like get_water_levels which retrieves water level data.
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 mentions date format requirements but does not explicitly guide when to use this tool vs alternatives (e.g., get_water_levels). There is no exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_water_levelsAInspect
Get the latest observed water level for a NOAA station.
| Name | Required | Description | Default |
|---|---|---|---|
| station_id | Yes | NOAA station ID (e.g. "9414290" for San Francisco) |
Output Schema
| Name | Required | Description |
|---|---|---|
| datum | Yes | Vertical datum reference (MLLW) |
| units | Yes | Measurement units (feet) |
| latest | Yes | Latest observed water level data or null if unavailable |
| station_id | Yes | NOAA station ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It accurately indicates a read operation (Get) but doesn't disclose other behaviors like data freshness, data format, or any rate limits. Adequate but minimal.
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?
Single, concise sentence with no filler. All words are meaningful and front-loaded with the key action and resource.
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 (single required parameter, no output schema), the description is minimally adequate. Could benefit from mentioning output format or data recency, but not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the station_id parameter well-described in schema. Description adds no extra parameter meaning beyond the schema. 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?
Description clearly states the verb 'Get', resource 'latest observed water level', and scope 'NOAA station'. Purpose is specific and unambiguous, though it doesn't explicitly distinguish from sibling tool 'get_predictions' which could be inferred as providing predictions vs observations.
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?
Description implies usage for retrieving current water levels but provides no explicit guidance on when to use this tool vs alternatives like 'get_predictions'. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_stationsAInspect
List all NOAA tide prediction stations with their IDs and names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total number of tide prediction stations |
| stations | Yes | List of NOAA tide prediction stations |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation (listing) and specifies what is returned (IDs and names). With no annotations, this is adequate but lacks details on data freshness or pagination.
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 conveys the tool's purpose and output, with no unnecessary 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 has no parameters, no output schema, and simple behavior, the description is nearly complete. However, it could mention the source (NOAA) and that the list is comprehensive.
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 input schema has no parameters, so the description's mention of 'all NOAA tide prediction stations' adds context that the tool returns the entire set without filters. This is clear and sufficient.
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 lists all NOAA tide prediction stations, providing IDs and names. The verb 'list' and resource 'stations' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a list of stations but does not provide guidance on when to use this tool versus alternatives like get_predictions or get_water_levels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pipeworx_feedbackAInspect
Send feedback to the Pipeworx team. Use for bug reports, feature requests, missing data, or praise. Describe what you tried in terms of Pipeworx tools/data — do not include the end-user's prompt verbatim. Rate-limited to 5 messages per identifier per day. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | bug = something broke or returned wrong data. feature = a new tool or capability you wish existed. data_gap = data Pipeworx does not currently expose. praise = positive note. other = anything else. | |
| context | No | Optional structured context: which tool, pack, or vertical this relates to. | |
| message | Yes | Your feedback in plain text. Be specific (which tool, what error, what data was missing). 1-2 sentences typical, 2000 chars max. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limit of 5 messages per day and states it is 'free'. No annotations provided, so description carries full burden; adequately explains behavior for a feedback 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?
Three concise sentences: purpose, usage guidelines, and rate limit. Front-loaded with most important info, no unnecessary 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?
Provides enough context for an agent to use the tool: what to send, how to format, and constraints (rate limit, avoid prompts). No output schema needed; response confirmation not critical for feedback tool.
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?
Input schema already has 100% description coverage for all parameters. Description adds high-level usage context but does not significantly enhance parameter understanding 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 'Send feedback' and enumerates specific categories (bug, feature request, etc.). It differentiates from sibling tools like ask_pipeworx or discover_tools by being the dedicated feedback channel.
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 lists use cases (bug, feature, data_gap, praise) and gives instructions on what to include (tools/data context) and exclude (end-user prompt). Mentions rate limit but lacks explicit alternatives for when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses the tool is for retrieval, not mutation, which aligns with the verb 'recall'. However, it does not state what happens if the key doesn't exist or whether memories persist across sessions, leaving some ambiguity.
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 action, no redundant words. Each sentence adds value: first explains the action, second explains when to use.
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 simple tool (one optional parameter, no output schema), the description is adequate. It explains both retrieval modes and usage context. Slightly more could be said about return format or error behavior, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines the key parameter well. The description adds context that omitting the key lists all memories, which is useful but not essential beyond the 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?
The description clearly states the tool retrieves a memory by key or lists all memories when key is omitted. It explicitly distinguishes from siblings like 'remember' and 'forget' by focusing on retrieval.
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 when to use (retrieve context saved earlier) and implies when not to use (for listing all, omit key). However, it does not explicitly mention when to prefer other tools like 'discover_tools'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recent_changesAInspect
What's new about an entity since a given point in time. type="company": fans out to SEC EDGAR (filings since), GDELT (news mentions in window), USPTO (patents granted since), in parallel. since accepts ISO date ("2026-04-01") or relative ("7d", "30d", "3m", "1y"). Returns structured changes + total_changes count + pipeworx:// URIs for each item. Use for "brief me on what happened with X" or change-monitoring workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type. Only "company" supported today. | |
| since | Yes | Window start — ISO date ("2026-04-01") or relative ("7d", "30d", "3m", "1y"). Use "30d" or "1m" for typical monitoring. | |
| value | Yes | Ticker (e.g., "AAPL") or zero-padded CIK (e.g., "0000320193"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the parallel fan-out behavior, accepted date formats, and return structure (structured changes + count + URIs). Could mention rate limits or auth, but core behavior is well covered.
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 well-structured paragraph that front-loads purpose, then details behavior, parameters, returns, and use cases. No superfluous sentences.
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 moderate complexity (multi-source fan-out) and no output schema, the description covers all key aspects: entity type, date handling, value formats, return contents, and use cases. Could add more on error handling or response size, but sufficient.
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 parameter descriptions. The description adds context: explains that since accepts ISO or relative dates, type is limited to company, and value can be ticker or CIK, along with usage tips ('Use 30d or 1m for typical monitoring').
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: 'What's new about an entity since a given point in time' and details the specific resources involved (SEC EDGAR, GDELT, USPTO). It distinguishes from sibling tools like entity_profile by focusing on change monitoring.
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 usage cues: 'Use for brief me on what happened with X or change-monitoring workflows' and explains supported entity types ('Only company supported today'). However, it does not explicitly mention when to use alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses behavioral traits: memory persistence based on authentication status and session duration (24 hours). This is critical for understanding data retention. No contradictions.
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?
Three sentences, each adding value: first defines purpose, second lists use cases, third notes persistence. Could combine first two for even tighter structure.
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 no output schema and simple parameters, description adequately covers purpose, usage, and behavioral context. Missing only output format details, but for a store tool, success is implied.
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%, so baseline is 3. Description does not add further parameter details beyond schema, but schema examples are helpful. No additional value provided.
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 uses specific verb 'store' and clear resource 'key-value pair in session memory'. It distinguishes from sibling tools like 'forget' and 'recall' by focusing on saving data.
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?
States when to use ('save intermediate findings, user preferences, or context across tool calls') and provides context about persistence differences between authenticated and anonymous users. Lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_entityAInspect
Resolve an entity to canonical IDs across Pipeworx data sources in a single call. Supports type="company" (ticker/CIK/name → SEC EDGAR identity) and type="drug" (brand or generic name → RxCUI + ingredient + brand). Returns IDs and pipeworx:// resource URIs for stable citation. Replaces 2–3 lookup calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| value | Yes | For company: ticker (AAPL), CIK (0000320193), or name. For drug: brand or generic name (e.g., "ozempic", "metformin"). |
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 for behavioral disclosure. It details the accepted inputs, supported version (v1), and return fields (ticker, CIK, name, URIs). It lacks explicit mention of idempotency or error handling, but still provides substantial context.
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 three sentences long, front-loaded with the main action, and includes a version note and practical examples. Every sentence adds value without redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with 2 required parameters and no output schema, the description covers inputs, outputs, and benefits. It could be improved by noting what happens on error or missing data, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds significant value by providing concrete examples (e.g., 'AAPL', '0000320193', 'Apple') and explaining the purpose of canonical IDs, which goes beyond the schema's basic definitions.
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: resolving entities to canonical IDs across data sources. It specifies the supported type (company) and input formats (ticker, CIK, name), making it distinct from sibling tools like 'ask_pipeworx' which are more general.
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 when to use this tool (for entity resolution) and highlights its efficiency by noting it replaces 2-3 lookup calls. However, it does not explicitly state when not to use it or mention alternative tools, which would improve guidance.
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!