Dawarich MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.5
Disambiguation4/5
Most tools are clearly distinct: places, visits, points, timeline, stats, and recalculate all have separate purposes. However, the three trip tools (create/update/delete) are functionally identical stubs that all report an API gap, making them hard to distinguish by action despite different names.
Naming Consistency5/5
All tools follow a consistent dawarich_<verb>_<noun> pattern in snake_case, with verbs like search, find, create, update, delete, add, merge, and bulk_update. This is highly predictable and readable.
Tool Count4/5
At 19 tools, the server is slightly over the ideal 3-15 range but still reasonable for a domain covering places, visits, points, trips, stats, timeline, and map context. The three non-functional trip tools could be trimmed, but the count is not excessive.
Completeness3/5
Core place/visit/point operations are well represented, plus useful extras like timeline, stats, and map context. However, trip tools are non-functional stubs that only report an API gap, creating dead ends for trip workflows, and there is no delete_visit tool. These are notable gaps.
Average 3/5 across 19 of 19 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 only states that a place is created, without mentioning persistence details, required permissions, idempotency, or side effects. It does not contradict annotations (none provided), but it is far too minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in word count, but it is under-specified for a tool with six parameters. It lacks essential details and is closer to under-specification than to effective conciseness. There is no front-loading of critical information because there is almost no information to front-load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, and an output schema that is not detailed in the description), the description is grossly incomplete. It does not explain what a 'manual place' means, how it relates to visits or points, or what the output represents. It is inadequate 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate at all. It does not explain the meaning or purpose of any of the six parameters (e.g., name, latitude, longitude, note, dry_run, tag_ids), leaving the agent to infer everything from the parameter names alone. The description adds zero semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a manual Dawarich place' uses a specific verb and resource, clearly indicating the action. It adds the modifier 'manual' which gives some context, but it does not distinguish this tool from siblings like dawarich_create_visit or dawarich_create_trip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as dawarich_update_place or dawarich_create_visit. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior, but it only says 'select' without indicating whether this is a mutation, whether it modifies a visit's place, how dry_run is handled, or any side effects. This is essentially no behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it extremely concise. However, it is under-specified; still, for what it contains, it is efficient and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a tool that likely performs a meaningful side-effect (selecting/assigning a place to a visit). It lacks any context about input semantics, the meaning of dry_run, or the behavior of the operation, leaving the agent to guess despite 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the tool description does not mention any of the three parameters (visit_id, place_id, dry_run). The description provides no meaning beyond the raw schema, so the agent gets no help in understanding what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Select one of Dawarich's possible places') and its object ('for a visit'), distinguishing it from sibling tools like create_place or create_visit. It is not a tautology, though 'select' could be more precise about what it does (e.g., assign or link).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites, such as needing an existing visit_id, or contrast with similar tools like dawarich_update_visit or dawarich_create_place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral detail ('Defaults to dry-run'), but with no annotations, the full burden falls on the description. It does not disclose potential side effects, whether changes are permanent, or what 'supported' recalculation means operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with no filler. However, its brevity sacrifices essential details that would help an agent. It is concise but under-specified, earning a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered, but the description leaves major gaps for a tool that likely modifies data. It does not explain what kinds of recalculations are supported, the meaning of dry_run in practice, or the expected workflow. This is insufficient for a tool with two parameters and zero schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the 'kind' parameter or list possible values. It only repeats the dry_run default, which is already encoded in the schema. The term 'supported' implies constraints but offers no specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('queue') and resource ('Dawarich recalculations'), but 'supported' is vague and does not specify what kinds of recalculations are available. It is not a tautology, but it lacks the specificity needed to fully distinguish the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool, what prerequisites exist, or how it compares to alternatives. The only hint is the dry-run default, which implies testing but is not explicitly stated as a use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'search,' which implies a read-only operation, but it does not state whether it is read-only, how 'saved' and 'nearby' results are combined or ranked, whether authentication is needed, or any rate limits. This is insufficient for a tool with two distinct search modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and resource. It is not bloated, but it is slightly under-specified; however, conciseness is not the same as completeness, and this description demonstrates good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters, two search modes (saved and nearby), and no annotations, the description is too brief to be considered complete. It fails to explain how to invoke either mode or what the output represents. The output schema exists, so return values are covered, but invocation semantics are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters (limit, query, latitude, longitude, radius_km) with 0% description coverage. The tool description mentions none of these parameters, leaving their semantics entirely unexplained. It does not even hint that 'query' is for saved places or that 'latitude'/'longitude' are needed for nearby search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Dawarich places, specifically 'saved and nearby' places. The verb 'search' and resource 'places' distinguish it from CRUD tools like dawarich_create_place and from search tools for other entities like dawarich_find_visits. However, it could be more specific about what 'nearby' means or how saved and nearby searches relate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any sibling tools, prerequisites, or differentiating factors like 'use dawarich_find_points for point-level searches.' The only implied usage is that it is for searching places.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose mutation side effects, whether specific fields are overwritten, the behavior of dry_run, or authorization requirements. The read-before-write hint is helpful but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but it is under-specified and contains a typo ('Dawarick' vs 'Dawarich'). It does not waste words, but the single sentence omits critical details that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no annotations, and an output schema), the description is incomplete. It does not explain partial vs full update semantics, the dry_run flag, or when to use bulk alternatives. The read-before-write hint is a start but not sufficient for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any of the 8 parameters. Parameter names like dry_run and status have implied meanings but lack context (e.g., accepted values, whether updates are partial). The description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a Dawarich visit, using a specific verb and resource. It distinguishes from create/delete tools, though it does not explicitly mention alternatives like bulk_update_visit_status. The phrase 'after reading its current value' adds workflow context but not differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a prerequisite (read current value before updating) but provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or when to prefer sibling tools like dawarich_bulk_update_visit_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does mention that the tool may also create a place, which is a meaningful side effect, but it does not explain what 'matching/manual' entails, when it triggers, or other important behaviors like idempotency, permission requirements, or error handling. The description is too sparse to adequately inform an agent of the tool's full impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient, but it is under-specified. It provides the main action up front but omits essential details that would require additional sentences. The brevity crosses the line from conciseness into incompleteness, so while it is well-structured, it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—it creates a visit and potentially a place, with 7 input parameters—the one-sentence description is not sufficient. There is an output schema, so return value details are not required, but the description does not explain the relationship between visits and places, the conditions under which a place is created, or how the parameters interact. The overall context is incomplete and would leave an agent uncertain about the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description provides no explanation for any of the 7 parameters. It does not mention how fields like name, latitude, longitude, started_at, or ended_at map to the visit or the optional place. The description fails to compensate for the low schema coverage, leaving the agent to guess the meaning and relationships of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary action: creating a Dawarich visit. It also distinguishes itself from the sibling dawarich_create_place by focusing on visits, and its mention of 'matching/manual place if needed' hints at a secondary behavior. However, the phrase 'matching/manual place' is ambiguous and could confuse the agent about when a place is actually created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Create a visit', but it does not explicitly explain when to choose this tool over alternatives like dawarich_update_visit or dawarich_create_place. No exclusions or alternative scenarios are mentioned. The context is only implicit, so it meets the 'implied usage' baseline but stops short of providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'Defaults to dry-run because merge is destructive', disclosing a default behavior and warning about danger. However, it does not specify what makes the merge destructive (e.g., deletion, overwriting) or what output to expect, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action and including a critical safety note. There is no filler or repetition. It is appropriately sized for the amount of information it conveys, though it is under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema, two parameters, and many siblings, this description is too sparse. It lacks operational details such as merging rules, reversal options, or output semantics. The destructive warning is present but does not compensate for missing context about how merging works in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain visit_ids or dry_run. The mention of dry-run defaults is redundant with the schema's default value, and visit_ids remains undocumented. The parameter names are somewhat self-explanatory, but the description adds almost no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Merge Dawarich visits' clearly states a specific action (merge) and resource (visits), distinguishing it from sibling tools that create, update, or delete. It doesn't elaborate on what merging entails, but the core 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The only usage related hint is that it defaults to dry-run due to destructiveness, which implies caution but does not explain scenarios where merging is appropriate or when another tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a behavioral caveat: the tool currently reports an API gap, implying it may not complete a deletion. Since no annotations are provided, this is useful transparency, but it fails to disclose other important behaviors such as irreversibility of deletion or the effect of the dry_run parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and action-oriented, but the phrasing 'when /api/v1/trips exists; currently reports that API gap' is awkward and somewhat confusing. It is concise but not optimally structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described, but the tool's actual behavior is critically underspecified. The agent is left uncertain whether calling this tool will delete a trip or simply report a missing endpoint. The dry_run parameter's effect is also unexplained, making it difficult to assess consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: the description does not mention trip_id or dry_run. The dry_run parameter, in particular, is critical for understanding whether the tool performs an actual delete or a simulated one, and this is left entirely unexplained. The schema provides only types, adding minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a Dawarich trip') and identifies the resource, distinguishing it from siblings like delete_place. However, the added clause 'when /api/v1/trips exists; currently reports that API gap' introduces ambiguity about whether the tool actually performs deletion, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is the conditional 'when /api/v1/trips exists,' which is vague and not actionable. No mention of when to use this tool over alternatives (e.g., update_trip) or when not to use it. The 'currently reports that API gap' suggests a limitation but does not instruct the agent on handling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It only says 'Get', implying a read operation, but omits details like output grouping, pagination, timezone handling, or format constraints. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, and front-loaded with the verb and resource. Efficient for what it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role among many sibling context tools and the lack of annotation and schema descriptions, the description leaves important gaps in when and how to invoke it. The output schema may help, but the description does not bridge usage semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of parameters, and the description does not name start_at, end_at, or distance_unit explicitly. 'Date range' loosely maps to date params but distance_unit is entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and resource ('day-by-day Dawarich timeline context') with a date-range scope. It is specific enough to distinguish from sibling tools focused on map context, stats, or point search, though 'context' remains somewhat abstract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over siblings like dawarich_get_map_context or dawarich_get_stats, or on prerequisites. The phrase 'for a date range' gives minimal context but no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden. It explicitly states 'currently reports that API gap', which is a significant behavioral disclosure indicating the tool may not perform actual updates. However, it does not explain what 'reports' means (error, warning, etc.) or other behaviors like permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise, but its structure is awkward, combining the purpose with a conditional clause and a semicolon. It is not a tautology and includes some essential limitation info, but could be better phrased.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and an output schema, the description provides minimal context. It fails to describe when to use the tool, what parameters mean, or what the output represents. The only valuable information is the current limitation about the API gap, which is insufficient for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions no parameters, leaving all six parameters (trip_id, name, started_at, ended_at, description, dry_run) without semantic context beyond their names. For example, the effect of dry_run is unexplored.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly starts with 'Update a Dawarich trip', which conveys the action and resource, distinguishing it from create/delete siblings. However, the appended condition 'when /api/v1/trips exists; currently reports that API gap' introduces ambiguity about whether the tool actually performs updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The only condition mentioned is about the API endpoint existence, not user intent or prerequisites. Sibling tools like create_trip and delete_trip are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description's disclosure that it 'currently reports that API gap' is valuable, revealing the tool does not perform a real creation in its current state. However, it does not elaborate on what 'reports' means or how failures are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence but awkwardly phrased ('reports that API gap') and somewhat repetitive with the 'when /api/v1/trips exists' clause. It is short but not well-structured or polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and an output schema, the description covers only a conditional and a limitation. It omits what a successful creation entails, what the API gap means for the output, and how parameters are used, leaving the tool under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 5 parameters, and the description itself offers no explanation of name, started_at, ended_at, description, or dry_run. All parameter meaning is left to inference from their names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Create a Dawarick trip', which is a specific verb+resource that distinguishes it from sibling tools like dawarich_update_trip and dawarich_delete_trip. The caveat about the API gap adds clarity about its current limitations, though it introduces some ambiguity about whether it actually creates trips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear precondition for use ('when /api/v1/trips exists') but does not explicitly name alternative tools or offer when-not-to-use guidance. The condition implies a narrow use case but lacks explicit comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'after reading its current value', suggesting a read-before-write pattern, but does not explain partial update behavior, field optionality, idempotency, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and includes a meaningful precondition. Every word contributes to the intended workflow, making it highly concise without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no annotations, and 0% schema coverage, but the description provides no information about parameters, return values, or conditional usage. While an output schema exists, the description alone is insufficient for correct invocation. The phrase 'after reading its current value' hints at a workflow but does not establish completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the 7 parameters. It does not compensate by explaining which fields are updatable or how they relate to the 'current value' precondition. The agent must infer parameter meaning solely from schema names, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and the resource (Dawarich place), distinguishing it from sibling tools like create_place and delete_place. The phrase 'after reading its current value' adds a specific precondition, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing place after reading its current state, which is a valuable workflow hint. However, it does not explicitly contrast with alternatives (e.g., create or delete) or state when not to use this tool. The guidance is more implied than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool 'Defaults to dry-run,' which is a safety-relevant behavioral trait not visible in the schema. However, with no annotations, it fails to warn about the destructive nature when dry_run=false, potential irreversibility, or effects on associated places/visits. The dry-run note adds some value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences with no wasted words. It front-loads the core action and adds a critical behavioral note in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with a dry-run flag, the description is too terse. It doesn't explain how to actually execute the deletion (e.g., setting dry_run to false), what the output schema represents, or whether deleting a place cascades to related entities. The existing output schema does not mitigate the missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the dry_run default, but that information already exists in the schema's default value. It does not explain what dry_run does (e.g., preview vs. actual deletion) or provide any semantics for place_id beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a Dawarich place' is a specific verb+resource statement that clearly identifies the tool's function. It distinguishes from sibling operations like create/update place and delete trip, and the dry-run mention adds a useful qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as updating a place or deleting a trip. There are no exclusions, prerequisites, or contextual clues about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. The verb 'Get' implies a read-only operation, and the year filter adds context, but there is no explicit statement about side effects, aggregation behavior, or what data is included. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-optional-parameter tool with an output schema, the description is minimally sufficient. It captures the core purpose and year filtering, but omits the important 'include_monthly' parameter and offers no broader usage context, leaving clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It only addresses 'year' as an optional filter; the 'include_monthly' parameter is never mentioned. No format, units, or behavioral implications are provided for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names a distinct resource ('aggregate Dawarich travel stats'), and mentions the optional year filter. This clearly differentiates it from sibling tools like dawarich_get_timeline and dawarich_find_points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of use cases, and no exclusions. The description only states what it does, leaving the agent to infer when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'Add raw Dawarich points' without mentioning side effects, idempotency, permission requirements, or the behavior of the dry_run parameter. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences, front-loaded with the action, and the second sentence adds valuable usage guidance. There is zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool's mutation nature and sparse input schema demand more context. The description fails to clarify the expected format of 'points', the function of 'dry_run', or any constraints/limits. It is inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not compensate by explaining the 'points' array structure, the meaning of 'raw', or the purpose of 'dry_run'. The agent must guess parameter semantics entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add raw Dawarich points') with a specific verb and resource. It distinguishes from siblings by emphasizing 'raw' points and explicitly naming alternatives (visit/timeline tools), 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Prefer visit/timeline tools unless raw samples are needed.' This directly tells the agent when to use this tool versus alternatives, satisfying the usage guideline requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It reveals the dry-run default, which is a key behavioral trait. However, it does not explain what happens when dry_run is false, whether partial failures occur, or required permissions. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no wasted words. The action and key behavioral note are front-loaded, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks essential invocation details: acceptable status values, behavior when dry_run is false, and error handling. An agent cannot reliably know what to put in the status field or what will happen on real execution, leaving the tool under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It does not explain allowed values for status, the meaning of visit_ids, or the full effect of dry_run. The phrase 'Defaults to dry-run' gives some hint about dry_run, but the other parameters are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a bulk update of Dawarich visit status, with a specific verb and resource. It is distinguished from the sibling dawarich_update_visit by the 'bulk' qualifier, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'bulk' term implies use for multiple visits, but there is no explicit comparison to the singular update tool or guidance on when to use dry-run versus a real update. The dry-run default provides some usage context but no when/when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. Only 'capped' hints at limits, but no details on output, read-only nature, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded verb, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple retrieval tool with an output schema, but lacks usage exclusions and behavioral depth given zero annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It hints at start_at/end_at as bounds and include_fog/include_hexagons/max_features as context, but doesn't explain formats or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Get' + resource 'map bounds' + optional hexagon/fog context. Clearly distinguishes from sibling tools like search_places or find_visits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: use when map bounds/hex/fog context needed. No explicit comparisons to alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but only discloses that results are raw points. It does not mention pagination, anomaly filtering behavior, ordering, or side effects. 'Find' implies read-only, but important behavioral details are left to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, each earning their place: one states the core function, the other guides tool selection. No redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 8 parameters with zero schema descriptions, and the description omits all parameter semantics. It gives a high-level selection heuristic but is not complete enough for an agent to invoke filtering/pagination correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter guidance. It ignores all 8 parameters (start_at/end_at, pagination, slim, anomaly flags) without explaining semantics or formats, so it fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Find raw Dawarich points') and the qualifier 'raw' clearly separates it from sibling tools that return visits, timeline, or map context. It states exactly what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Prefer timeline/map context unless point evidence is needed' explicitly tells the agent when to use this tool (point-evidence needs) and when to choose alternatives (timeline/map context). This is actionable and distinguishes from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a search/query operation ('Find') and identifies the filtering dimensions (time, status). However, it does not disclose behavioral details such as pagination behavior, whether date ranges are inclusive, or what status values are accepted. These gaps limit transparency beyond the basics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that immediately states the action and resource. It contains no filler, and every word contributes to the core meaning. This is an example of concise, effective writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters and an output schema, so the description doesn't need to explain return values. However, the description is minimal and omits guidance on pagination, parameter relationships, and when to use this over alternatives. It covers the fundamental purpose but leaves meaningful gaps in a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It maps 'time' to start_at/end_at and 'status' to status, adding semantic meaning to these core filters. However, it completely ignores the pagination parameters (page, per_page), leaving them without explanation. This partial compensation warrants a moderate score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find'), names the resource ('Dawarich visits'), and specifies the scope ('by time and status'). This clearly distinguishes it from sibling tools like create_visit or find_points, which have different actions or resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when searching for visits filtered by time and/or status. It provides clear context for the primary use case, though it does not explicitly mention alternatives or exclusion cases. The lack of an explicit 'use this instead of X' prevents a 5, but the filtering criteria give adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dawarich-mcp MCP server](https://glama.ai/mcp/servers/SebastianWild/dawarich-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SebastianWild/dawarich-mcp)

Score Badge

Copy to your README.md:

[![dawarich-mcp MCP server](https://glama.ai/mcp/servers/SebastianWild/dawarich-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SebastianWild/dawarich-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SebastianWild/dawarich-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server