agent-postit

by gerelef

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and operation: topics have create/read/write, postits have create/read/update/delete/rename/list/search/recent, with read subdivided into full, section, and line-range variants that are clearly differentiated. No two tools overlap in purpose.
Naming Consistency4/5
Tool names follow a consistent dot-separated resource.action pattern (e.g., topic.create, postit.read_section), but there are minor deviations: 'ls' is an abbreviation rather than a verb, 'recent' is not a verb, and 'update_body' contrasts with 'write' for topics.
Tool Count5/5
With 13 tools, the set is well-scoped for a note/topic management server. Each tool provides a distinct capability, and the count is within the ideal range—neither too sparse nor overwhelmingly large.
Completeness4/5
The postit lifecycle is fully covered (create, read, update, delete, rename, list, search, recent), and topics have create/read/write. Notable gaps include no topic delete or rename, and postit rename is restricted to the same directory, preventing moves. These are minor but slightly limit full lifecycle management.
Average 3.3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 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
This repository is licensed under MIT License.
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 provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, return values, permissions, or error conditions. For a create operation, important behavioral details are absent.
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 succinct sentence with no redundant words. It is effectively concise, though it lacks structural detail. The brevity is acceptable but does not provide added value beyond a minimal statement.
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 multiple parameters and an output schema, yet the description provides no context about parameter semantics, usage scenarios, or expected behavior. The presence of an output schema mitigates the need to explain return values, but the description remains insufficiently complete for an agent to invoke it correctly without additional guessing.
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 three properties (name, body, dir) but the description provides zero parameter information. With schema description coverage at 0%, the description was expected to compensate, but it mentions none of the parameters or their meanings.
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 'Create a new postit note' uses a specific verb ('Create') and a clear resource ('postit note'), distinguishing it from sibling tools like postit.rename or postit.delete. It is direct and unambiguous, fulfilling the purpose clarity criterion.
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 topic.create or other postit operations. It lacks context about prerequisites, exclusions, or scenarios where a different tool would be more appropriate.
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 behavioral disclosure. It only says 'Read', which conveys a read-only operation, but does not describe what constitutes the 'full body', how the optional 'dir' parameter affects behavior, error handling, or return format. The output schema exists but the description adds no extra behavioral context.
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 unnecessary words. It states the core purpose efficiently and earns its place without redundancy.
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 and sibling tools provide some context, the description omits crucial usage context: when to use this vs. read_section/read_lines, how 'dir' factors in, and what 'full body' means (including formatting or size limits). The tool is simple, but the description alone is insufficient for an agent to confidently invoke it.
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 does not mention the required 'name' parameter or the optional 'dir' parameter. Since the description must compensate for the schema's lack of semantic detail but fails to do so, the parameter semantics are effectively absent.
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 'Read a postit's full body' clearly states the verb (read) and resource (postit), and the 'full body' scope distinguishes it from sibling tools like postit.read_section and postit.read_lines. It is concise and unambiguous, though it does not elaborate on what a 'postit' is in this domain.
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 phrase 'full body' implies this tool is for reading the complete content of a postit, as opposed to partial reads (read_section, read_lines) or listing (postit.ls). However, it does not explicitly state when to prefer this over alternatives or provide any exclusions, so usage guidance is only implied.
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 must carry the full burden of behavioral disclosure. It states that it creates a directory and a TOPIC.md file, but does not disclose what happens if the directory already exists, whether it overwrites content, or any permission requirements. This is a minimal, surface-level description that lacks side-effect and safety details.
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 conveys the core action and outputs without unnecessary words. Every word earns its place, making it compact and easily parseable.
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 lack of annotations, an output schema that is not shown, and zero schema descriptions, the description is insufficient for an agent to reliably invoke the tool. It does not specify what 'dir' should look like (e.g., path vs. name), whether 'description' is the entire file content, or what the tool returns. A simple creation tool still needs more contextual guidance for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage) and the parameters are wrapped in a single 'arg' object. The description hints that 'dir' is the directory name and 'description' is the content for TOPIC.md, but it does not explicitly map parameters, nor does it explain input formats, constraints, or relationships. The description only partially compensates for the lack of schema detail.
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 ('create') and a concrete resource ('topic dir + TOPIC.md description'), clearly stating what the tool produces. It distinguishes from sibling tools like postit.create by focusing on topic-specific content, and the mention of TOPIC.md makes the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like topic.write or postit.create. It does not mention prerequisites (e.g., whether the topic directory must not already exist) or any context in which this tool is appropriate. The name implies creation, but the description itself offers no usage direction.
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?
As a read operation, the core behavior is safe and non-destructive, which is implied by the verb. However, with no annotations, the description carries the full burden and does not disclose potential error conditions, whether it returns raw file content, or any special handling of the TOPIC.md file. It is adequate but lacks depth.
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, six words, with no filler or redundancy. It is front-loaded and appropriately sized for the simple operation it describes.
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 one parameter with zero semantic explanation, and the description does not provide context about what constitutes a 'topic' or how 'dir' is interpreted. While an output schema exists (covering return values), the missing parameter semantics and lack of usage context leave the tool incomplete for an agent to invoke reliably.
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 only parameter, 'dir', is completely undocumented in both the schema (0% coverage) and the description. The description does not hint at what 'dir' represents (e.g., a filesystem path, a topic identifier, or a workspace). This is a critical gap for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'a topic's TOPIC.md description', providing a specific and unambiguous purpose. It distinguishes from sibling tools like topic.write and postit.read by naming the exact file and operation.
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 indication of when to use this tool versus alternatives such as topic.create or postit.read. There is no mention of context, prerequisites, or exclusions, leaving the agent without strategic 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, the description must carry full behavioral disclosure. It reveals that the tool overwrites a description, but does not mention any side effects, permission requirements, or whether the operation is destructive to other parts of the topic file.
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. It states exactly what the tool does, earning every word.
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 no annotations and minimal description, leaving the agent without information about how to specify the topic, whether the operation is safe, or what the output contains (though output schema exists). More context is needed for reliable invocation.
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 explain the parameters. Although 'dir' and 'description' are intuitively named, the nested structure and exact meaning are left unclear, so the description adds little semantic value.
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 ('Overwrite') and names the resource ('a topic's TOPIC.md description'), clearly distinguishing it from sibling tools like topic.create and topic.read.
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. While the verb 'overwrite' implies updating an existing topic, there is no explicit 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must fully disclose behavior. It only states the operation type (append/overwrite) but provides no details on consequences such as whether append adds to the end, whether overwrite replaces entirely, what happens if the postit does not exist, or any permission requirements. 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, front-loaded sentence with no fluff. It efficiently conveys the core action, making it easy to parse. It is appropriately sized for the tool's simplicity, though it sacrifices detail.
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 moderate complexity (nested object, 4 parameters, no annotations, 0% schema description coverage), the description is far from complete. It omits critical parameter context (dir, name, mode default) and behavioral edge cases. The presence of an output schema helps with return values, but the tool remains under-specified for reliable agent usage.
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 for parameter meanings. It only implies 'content' as the body and 'append/overwrite' as the mode, but fails to explain 'name' as identifier, the optional 'dir', or the default mode. The description adds marginal semantic value beyond the schema's raw fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: appending or overwriting a postit's body. The verb 'append/overwrite' plus resource 'postit's body' is specific and distinguishes it from siblings like postit.read, postit.rename, and postit.delete.
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 postit's content, but does not explicitly state when to use it versus alternatives like postit.create or postit.rename. No exclusions or alternative references are provided, leaving the agent to infer from the tool name and context.
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. It discloses the recursive traversal and recency-based ordering ('most-recently-modified'), but it does not mention limit semantics, default directory behavior, or explicitly confirm read-only status. This is partial but not complete 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?
The description is a single, front-loaded sentence with no filler or repetition. It efficiently conveys the core purpose and a key behavioral detail.
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 output schema likely documents return values, and the description covers the primary retrieval purpose and recursive scope. However, it lacks usage context and parameter details, making it minimally viable rather than fully complete for an agent deciding how to invoke it.
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 gives context for 'dir' by saying 'under dir,' but the 'limit' parameter is entirely unexplained, including its meaning or default behavior. Only one of the two parameters receives any semantic clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'most-recently-modified postits' and includes the scope 'always recursive under dir,' which distinguishes it from sibling listing tools like postit.ls and postit.read. The verb 'Return' and resource 'postits' make the operation 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 about when to choose this tool over alternatives like postit.ls or postit.search. The phrase 'always recursive under dir' describes behavior but not the intended use case or exclusions.
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 carry the full burden of behavioral disclosure. It only states the basic action and the 'same dir' constraint, omitting crucial details such as error handling (e.g., what if the postit does not exist), whether the operation overwrites an existing name, permission requirements, or any side effects. This is insufficient for a mutating tool with zero annotation context.
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, front-loaded sentence without redundancy, which is efficient. However, its brevity borders on under-specification, missing useful parameter or behavioral context that would aid the agent. It earns its place but could be enriched without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no annotations, and only an output schema (which helps with return values), the description covers the core operation but leaves out parameter semantics, possible error conditions, and the exact implications of 'same dir'. The description alone is insufficient for a fully informed invocation in a complex 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 references 'same dir' which loosely maps to the 'dir' parameter, but it does not explain the optional/default behavior of 'dir' nor clarify the roles of 'name' and 'new_name' beyond what their names imply. The lack of explicit parameter details leaves room for ambiguity.
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 ('Rename') and resource ('a postit') and adds a scope constraint ('within the same dir'), which distinguishes it from siblings like postit.create, postit.delete, or postit.update_body. The verb-resource pair is 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to rename a postit while keeping it in the same directory. The 'same dir' clause sets a clear limitation, but it does not explicitly mention alternatives or when not to use, such as for moving between directories. Without explicit exclusions, it falls short of a 5.
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 present, so the description must disclose behavioral traits. It only mentions the listing modes and style, but fails to state that the operation is read-only, how invalid inputs or parameter combinations are handled, or whether recursion applies to both modes. This leaves significant behavioral uncertainty.
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, concise sentence with no redundant words. It leads with the verb and clearly lists the two modes, making it highly readable and appropriately front-loaded.
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?
While an output schema exists, the tool has three undocumented parameters and no annotations. The description fails to explain how to set up the parameters for each mode or what happens when both dir and name are provided. It is not complete enough for reliable invocation.
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 hints that 'dir' maps to directory listing and 'name' to headings, but does not explain the 'recursive' parameter, parameter precedence, or expected formats. The compensation is minimal and incomplete.
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 states a specific action ('List') with two clear targets: dir contents in 'ls -la style' and headings of a postit. This clearly distinguishes it from sibling tools like postit.read (full content), postit.read_lines (specific lines), and postit.read_section (sections).
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 defines two explicit use cases—directory listing and heading listing—making it clear when to invoke this tool. It does not explicitly name alternatives or state exclusions, but the context implies the appropriate 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?
No annotations are provided, so the description carries the full burden. It adds useful context about 1-based inclusive indexing, but it does not disclose behavior for invalid line numbers, missing postits, or edge cases like out-of-range start/end. The 'dir' parameter's effect on lookup is also unexplained.
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 immediately states the action and key constraint ('1-based inclusive'), with no filler or redundancy.
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 is relatively simple, but the description leaves parameter semantics and error behavior unaddressed. The output schema exists, so return values are covered, but with no annotations and four parameters, a bit more context would improve completeness.
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 only clarifies that start and end are a 1-based inclusive range. It does not explain what 'name' refers to, what 'dir' does, or how they relate to locating the postit. This fails to compensate for the lack of schema-level descriptions.
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 ('Read'), the resource ('a postit body'), and the specific scope ('1-based inclusive line range'). This distinguishes it from siblings like postit.read (full content) and postit.read_section (sections).
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 when needing a specific line range, but it does not explicitly discuss when to use it versus alternatives like postit.read or postit.read_section. No exclusions or prerequisites are mentioned.
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, the description carries the full burden of safety and behavior. It usefully discloses the matching rule (case-insensitive, exact), but does not explain what happens if no heading matches, if multiple match, or whether subheadings are included. Still, it adds meaningful behavioral context beyond what the schema provides.
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 adds value by specifying the action, resource, and matching exactness.
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 a nested requirement (name and heading are required), an output schema, and no annotations, yet the description is minimal. It omits critical parameter meanings (name, level, dir) and does not explain the return format or edge cases. Sibling tools exist but no comparison is provided, making it incomplete for correct invocation.
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 by explaining parameters. It only clarifies the 'heading' matching semantics. The required 'name' parameter and optional 'level' and 'dir' parameters are not mentioned, leaving the agent to guess how to specify which document and heading level to target.
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 the specific verb 'Read' and identifies the resource as 'markdown section', with clear matching criteria (heading text, case-insensitive, exact). This distinguishes it from sibling read tools like postit.read or postit.read_lines, which presumably read the whole note or lines.
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 when to use this tool (read a specific section by heading) but provides no explicit guidance on when not to use it or how it compares to alternatives like postit.read, postit.read_lines, or postit.search. It lacks exclusions or named alternatives.
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?
No annotations are provided, so the description carries the full burden. It conveys that this is a read-only regex search and adds the 'grep-like' trait, but it does not disclose behavior around directory scoping, recursion, result limiting, or output format. The description 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 is a single sentence, front-loaded with the core action 'Regex search'. Every word contributes meaning, with no filler or redundant information. It is appropriately sized for the tool's simplicity.
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?
With five parameters and no annotations, a one-sentence description is thin. It covers the core purpose but omits context about directory targeting, recursion defaults, and result handling. The presence of an output schema mitigates some ambiguity about return values, but the description still lacks depth for a multi-parameter tool.
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 schema has zero descriptions for its fields, so the description must compensate. It clarifies that 'pattern' is a regex and that 'scope' covers names and/or bodies, but it does not explain 'dir', 'limit', or 'recursive', leaving those to be interpreted from their names and defaults.
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 specific verb 'search' and the resource 'postit names and/or bodies', further clarified by 'grep-like' to indicate regex matching. This distinguishes it from sibling read/list tools such as postit.read or postit.ls.
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 regex-based search across postit fields but provides no explicit guidance on when to choose this tool over siblings, nor any exclusions or alternative recommendations. The use case is inferred from the verb 'search'.
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 the core destructive behavior (deletes a note) and adds one useful nuance: the directory survives. However, with no annotations, it omits other potentially relevant behaviors such as irreversibility, permission requirements, or response details.
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 concise sentence with a clarifying parenthetical. Every word adds value and there is no redundancy.
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 delete tool, the description is minimally adequate but leaves gaps in parameter semantics and usage guidance. Output schema exists, which may explain return values, but the description alone does not fully cover 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?
The input schema has 0% description coverage and the description itself barely explains parameters. 'Name' is implied as the note identifier, and 'dir survives' gives some hint about the dir parameter, but neither is formally explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a postit note, using a specific verb and resource. It distinguishes itself from siblings as the only delete operation, with the parenthetical clarifying scope (directory survives).
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 intended use is clear: delete a postit note. There are no alternative delete tools among siblings, so explicit alternatives are unnecessary. The parenthetical provides context about directory behavior, which helps the agent decide when 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.

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:

[![agent-postit MCP server](https://glama.ai/mcp/servers/gerelef/agent-postit/badges/card.svg)](https://glama.ai/mcp/servers/gerelef/agent-postit)

Score Badge

Copy to your README.md:

[![agent-postit MCP server](https://glama.ai/mcp/servers/gerelef/agent-postit/badges/score.svg)](https://glama.ai/mcp/servers/gerelef/agent-postit)

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/gerelef/agent-postit'

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