Signed
Server Details
Connect your AI assistant to Signed and ask about your angel investing in plain English: how the portfolio is doing, what distributions came in this year, what’s sitting in the pitch queue. It's a view into the startups that you've invested in (or are thinking of investing in!)
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 22 of 22 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose. Overlaps like list_companies and search_companies are explained by scope (portfolio vs. all), and descriptions differentiate them effectively.
Most tools follow a verb_noun pattern (create_note, list_companies), but 'search' and 'whoami' are single-word exceptions, causing minor inconsistency.
22 tools cover portfolio management, CRM, transactions, notes, and updates without being overwhelming. Each tool addresses a specific need.
Core operations are present but missing update/delete for entities like companies, notes, and transactions. Agents have create and list but cannot modify or remove, creating potential gaps.
Available Tools
22 toolscreate_noteAInspect
Add a note to a company, pitch, or person. The body is rendered as markdown, so headings, lists, and emphasis are formatted; plain text works too, with paragraphs and line breaks preserved. Give exactly one of company (a slug from list_companies / list_pitches) or person (a uuid from list_people). Set ai_generated: true when you (the AI) wrote the note yourself rather than transcribing the user's own words, so it can be visually distinguished from human-authored notes.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The note text. Markdown is rendered. | |
| person | No | Person to note, by uuid. | |
| company | No | Company or pitch to note, by slug. | |
| ai_generated | No | Set true if the note text is your own AI-written content, not the user's verbatim words. Defaults to false (attributed to the user as human-authored). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds value by disclosing markdown rendering and the ai_generated attribution flag, which are not obvious from schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four clear sentences: purpose, markdown behavior, constraint on company/person, and ai_generated guidance. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 4 parameters with usage context, rendering behavior, and attribution. No output schema needed; description fully supports correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds clarity by specifying that company is a slug from specific tools, person is a uuid, and explaining the meaning of ai_generated beyond its schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Add a note' and specifies targets (company, pitch, person). It clearly distinguishes from sibling tools like list_notes or create_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States that exactly one of company (slug from list_companies/list_pitches) or person (uuid from list_people) must be provided. Also advises when to set ai_generated=true, giving clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_transactionAInspect
Record a transaction (cash flow) on a company: a buy (equity purchase or fund capital call), SAFE, sell, or distribution. Amounts are positive USD. Target an existing company by slug, or pass a domain to find or create the company. Recording a transaction on a pipeline pitch converts it into a portfolio position.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ISO 8601 date (YYYY-MM-DD). Defaults to today. | |
| type | Yes | The cash-flow type. buy covers equity purchases and fund capital calls. | |
| amount | Yes | Amount in USD, positive. Direction comes from type, not sign. | |
| domain | No | Alternative to company: the company's website domain. Matches your existing company by domain, or creates a new portfolio company from it. | |
| entity | No | Investing entity id (from list_entities). Defaults to the entity the company was first transacted under. | |
| shares | No | Shares bought or sold, for equity transactions. | |
| company | No | Company or pitch to record on, by slug (from list_companies / list_pitches / search_companies). | |
| valuation_cap | No | Valuation cap, for SAFEs. Also records a valuation mark on the company. | |
| price_per_share | No | Price per share. Derived from amount / shares when omitted. | |
| post_money_valuation | No | The round's post-money valuation, if known. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description correctly conveys a write operation. Beyond annotations, it explains that amounts are positive and direction comes from type, and that using a domain can create a company. This adds useful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: definition of operation, clarification of amount and target, side effect. No unnecessary words, well front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no output schema, the description covers the primary use cases and key constraints. It explains how to identify the company and the effect on pitches. Could mention entity defaulting more explicitly, but the schema handles it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by grouping parameters into a coherent narrative: it explains how to specify the company via slug or domain, and that amount sign is irrelevant. This ties parameters together beyond their individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a transaction (cash flow) on a company, listing specific types (buy, SAFE, sell, distribution). It distinguishes from sibling tools like list_transactions, and explains side effects like converting a pipeline pitch to a portfolio position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: to record cash flow on an existing or new company, and that it converts pipeline pitches. It does not explicitly exclude alternatives, but the sibling list_transactions is obvious for reading. It offers practical guidance on targeting companies via slug or domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_companyARead-onlyIdempotentInspect
One of the authenticated user's companies by slug, with position aggregates, founder-authored description and comments, valuation history (marks, newest first), operating metrics (ARR, cash, monthly burn — newest first), people (team, individual investors, intro source), and institutional investor funds. Slugs come from list_companies / search_companies.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The company's slug. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds value by detailing the returned data (valuation history, operating metrics, people, etc.), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with comprehensive enumeration of returned fields. Dense but efficient, though could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with one parameter and no output schema, the description sufficiently covers input source and output structure. No missing critical details given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'slug' is described in schema (100% coverage). Description adds practical context that slug comes from list_companies/search_companies, aiding the agent in proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves a specific company by slug and enumerates the data returned (position aggregates, founder description, valuation history, etc.). Differentiates from siblings list_companies and search_companies by mentioning slugs come from those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical guidance that slugs are obtained from list_companies or search_companies, helping the agent know prerequisites. Does not explicitly state when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_personARead-onlyIdempotentInspect
One of the authenticated user's CRM people by uuid, with their company relationships (employee, individual investor, or intro source). Uuids come from list_people, list_notes, and get_company.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | The person's uuid. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and no destructive behavior. The description adds value by specifying the returned relationships (employee, individual investor, intro source) and context ('authenticated user's CRM people'). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences clearly convey purpose, return data, and uuid sourcing. No extraneous information; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is complete: it specifies input (uuid), output (person with relationships), and how to obtain uuids. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for uuid. The description adds context on where uuids originate, which helps the agent understand parameter source. Given high schema coverage, a baseline of 3 is appropriate; the additional context merits a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a CRM person by uuid and includes specific company relationships (employee, individual investor, intro source). It distinguishes from sibling tools like list_people (which lists) and get_company (which gets a company).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates where uuids come from (list_people, list_notes, get_company), providing clear sourcing guidance. It implies use when you have a uuid, but does not explicitly state when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_portfolioARead-onlyIdempotentInspect
Portfolio-wide metrics for the authenticated user: current value, invested, realized, MOIC, DPI, and IRR, with a by_type breakdown (company, fund, SPV). Amounts are USD. Use list_companies for the per-company rows.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that amounts are in USD and the breakdown type. No contradictions, and it provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous information. Front-loaded with key metrics and ends with clear sibling differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and simple structure, description fully covers what the tool returns (metrics, breakdown, currency) and how it relates to siblings. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema, so description does not need to add parameter details. It describes the output metrics instead, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns portfolio-wide metrics (current value, invested, realized, MOIC, DPI, IRR) with a by_type breakdown. It distinguishes from list_companies by directing users to that sibling for per-company rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions 'for the authenticated user' and suggests list_companies for per-company data, providing a clear alternative. No explicit when-not-to-use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_portfolio_historyARead-onlyIdempotentInspect
Portfolio value over time for the authenticated user: a dated series of total value, cumulative invested, cumulative realized, and MOIC, built by replaying position snapshots and transactions. Amounts are USD. Defaults to the full history, downsampled to 60 points.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End the series at this ISO 8601 date (YYYY-MM-DD). | |
| from | No | Start the series at this ISO 8601 date (YYYY-MM-DD). Cumulative figures still include earlier activity. | |
| max_points | No | Downsample the series to at most this many points (default 60, max 366). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable context: how it's computed ('replaying position snapshots and transactions'), currency (USD), default and limits, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Structure efficiently conveys core functionality and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description fully explains the return value (dated series of total value, cumulative invested, cumulative realized, MOIC), defaults, downsampling, and currency. Complete for a read-only history tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds meaning beyond schema: explains that cumulative figures include earlier activity for 'from', and specifies default (60) and max (366) for 'max_points'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'portfolio value over time' with specific components (total value, cumulative invested, realized, MOIC). It distinguishes from sibling tools like get_portfolio (current snapshot) and list_transactions (raw data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes default behavior ('defaults to the full history', 'downsampled to 60 points') and provides context for when to use, but does not explicitly exclude alternatives or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_userARead-onlyIdempotentInspect
A public Signed user profile by login. Private profiles are indistinguishable from nonexistent ones.
| Name | Required | Description | Default |
|---|---|---|---|
| login | Yes | The user's login (username). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds critical context that private profiles are indistinguishable from nonexistent ones, which is beyond what annotations provide and prevents misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and contains no extraneous information. Every word is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, safe annotations), the description fully covers the essential behavior and edge case (private vs public profiles). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'login' clearly described. The description adds no extra meaning beyond the schema, meeting baseline for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a public user profile by login, and distinguishes public from private profiles. It uses specific verb 'get' and resource 'user profile', with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (public profiles) and when not (private profiles, which are indistinguishable from nonexistent). However, it does not explicitly mention sibling tools or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_companiesARead-onlyIdempotentInspect
List the companies in the authenticated user's portfolio, alphabetically, with per-company position aggregates (invested, current value, realized, MOIC, DPI). Pass a tag name (from list_tags) to filter. Amounts are USD.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Only companies carrying this tag, by name (see list_tags). | |
| page | No | 1-indexed page number (default 1). | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds order (alphabetical), currency (USD), and aggregate fields returned. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action and key features, followed by filter and currency. No unnecessary words, high information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return content (aggregates). Covers all key aspects: what, order, filter, currency. For a simple list tool with good annotations and 3 optional parameters, description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for tag, page, per_page. Description adds that tag should come from list_tags. Does not provide additional syntax or semantics beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List the companies' with specific features: portfolio, alphabetical order, per-company aggregates (invested, current value, realized, MOIC, DPI). Distinguishes from sibling list tools like list_people or list_notes by specifying portfolio context and aggregates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells when to use: when needing portfolio companies with position aggregates. Provides filter instructions referencing list_tags. No explicit when-not or alternatives, but context signals (many list tools) and description imply this is for portfolio-specific listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_entitiesARead-onlyIdempotentInspect
List the authenticated user's investing entities (personal accounts, LLCs, trusts, retirement accounts), default entity first, each with its tax status (taxable, tax_deferred, tax_free). Entity ids feed the entity filter on list_transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number (default 1). | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds context about default entity order, tax status, and linking to list_transactions, which goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose and output details, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately describes return data (entities with tax status) and pagination parameters. Minor omission: no mention of error cases or authentication requirements, but adequate for a list tool with simple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; description adds no additional parameter information, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists the user's investing entities with examples and tax status. It distinguishes from siblings like list_companies by specifying entity types, though it doesn't explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for fetching entities before using list_transactions, but no explicit when-not or alternatives among sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_followersARead-onlyIdempotentInspect
Public users following the authenticated user, alphabetically by name. Private accounts are never included.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number (default 1). | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses that results are limited to public users, sorted alphabetically, and that private accounts are never included. This adds meaningful behavioral context not captured by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the core purpose front-loaded. Every sentence adds value—sorting order and privacy exclusion—without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description covers the key behavioral aspects (scope, sorting, exclusion). However, it does not describe the return format or fields, which would help the agent interpret the results. Still, given the low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (page, per_page). The description does not add any additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists public followers of the authenticated user, sorted alphabetically by name, and explicitly excludes private accounts. This is a specific verb+resource+scope combination that distinguishes it from sibling tools like list_follows or list_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only clarifies one boundary condition (private accounts excluded), but does not suggest when to use other tools like list_follows or list_companies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_followsARead-onlyIdempotentInspect
Public users the authenticated user follows, alphabetically by name. Private accounts are never included.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number (default 1). | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by clarifying that private accounts are never included and that results are alphabetically ordered, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that conveys all essential information without waste. Every word is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and rich annotations, the description is sufficient: it covers purpose, ordering, and exclusion criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description does not add meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists public users the authenticated user follows, alphabetically by name. It distinguishes from sibling tools like list_followers by specifying 'public users' and excluding private accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly differentiates from similar tools (e.g., list_followers, list_people) by its specific focus on follows and alphabetical ordering, but does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_marksARead-onlyIdempotentInspect
List valuation marks across the authenticated user's portfolio, newest first — funding rounds, secondaries, estimates, and dissolutions, each with the company it reprices. Pass a company slug to scope to one company. Amounts are USD.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number (default 1). | |
| company | No | Only this company's marks, by slug. | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: results are ordered newest first, include specific mark types (funding rounds, secondaries, etc.), and amounts are in USD. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, focused, and front-loaded with the core purpose. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description covers ordering, types of marks, currency, and scoping. It does not detail the fields of each mark (e.g., value, date), but the annotations provide a strong safety profile, making the description adequate for most selection decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal new meaning beyond restating the 'company' parameter's purpose. Baseline is 3 for high coverage, and the description provides no significant additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists valuation marks across the user's portfolio, specifies ordering (newest first), and lists the types of marks included. It also mentions the company slug scoping, distinguishing it clearly from sibling tools like list_companies and list_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool and how to scope to a single company via the 'company' parameter. However, it does not explicitly state when not to use this tool or compare it to alternatives among the sibling tools, leaving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_metricsARead-onlyIdempotentInspect
List operating metrics (ARR, cash, monthly burn) reported across the authenticated user's portfolio, newest first, each with the company it belongs to. Pass a company slug to scope to one company. Amounts are USD.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number (default 1). | |
| company | No | Only this company's metrics, by slug. | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint. Description adds ordering, currency, and portfolio scope but does not elaborate on pagination behavior or response structure beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the main purpose, are efficient, and contain no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool without output schema, the description adequately covers scope, ordering, optional filter, and currency. Minor gaps in pagination and return format are acceptable given schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. Description adds context for company slug (scoping to one company) but adds little for page and per_page beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists operating metrics (ARR, cash, monthly burn) across the user's portfolio, newest first, with company association and optional scoping. It differentiates from sibling tools by focusing on specific metric types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for listing metrics, but lacks explicit guidance on when to use versus alternatives like list_companies or get_company. It mentions optional company filter but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_notesARead-onlyIdempotentInspect
List the authenticated user's notes, newest first, each with the company, pitch, or person it is about. Pass a company slug (from list_companies / list_pitches) to scope to one company or pitch.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number (default 1). | |
| company | No | Only notes on this company or pitch, by slug. | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the constraint that it lists only the authenticated user's notes and describes ordering, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main purpose, followed by optional usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and scoping, but lacks info on return format and pagination beyond schema. Still sufficient given annotations and schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds value by explaining the company parameter's source and scoping purpose, while page/per_page are adequately covered in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists the authenticated user's notes, newest first, with content details (company/pitch/person). It distinguishes from siblings like list_companies and create_note by specifying the resource and default scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for scoping via company slug, but does not explicitly mention when not to use this tool (e.g., for text-based search) or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_peopleARead-onlyIdempotentInspect
List the authenticated user's CRM people (founders, co-investors, intro sources), newest first. Filter by name/email text, investor flags, or company slug. Person uuids feed get_person.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Match against person name and email (case-insensitive substring). | |
| page | No | 1-indexed page number (default 1). | |
| company | No | Only people affiliated with this company (any relationship), by slug. | |
| investor | No | Only people flagged (true) or not flagged (false) as investors. | |
| per_page | No | Results per page (default 30, max 100). | |
| following | No | Only people the user follows (true) or doesn't (false). | |
| angel_investor | No | Only people flagged (true) or not flagged (false) as angel investors. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: sorting order (newest first) and hint to use person uuids with get_person. Annotations already declare read-only, idempotent, and non-destructive. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and sorting, no filler. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, sorting, filtering, and chaining. Pagination is in schema, so not needed in description. No output schema but the tool is a list; missing explicit mention of pagination behavior is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all parameters. Description summarizes filtering by name/email, investor flags, and company slug, adding value beyond the schema by grouping them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists the authenticated user's CRM people with sorting and filtering options, and distinguishes from siblings by noting it feeds into get_person.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains what the tool does and links to get_person for chaining, but does not explicitly mention when to avoid it or compare to other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_pitchesARead-onlyIdempotentInspect
List pitches in the authenticated user's deal pipeline, newest first. Defaults to the triage stage (new, unreviewed pitches); pass a stage to filter, or all=true for every stage.
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Return pitches from every stage (ignored when stage is given). | |
| page | No | 1-indexed page number (default 1). | |
| stage | No | Filter to one deal stage. | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds behavioral context: it retrieves pitches from the user's pipeline, defaults to triage, and orders by newest first. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It is front-loaded with the core purpose and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with clear annotations and schema, the description covers input filtering and ordering. Pagination is implied by parameters; no output schema is needed. Minor improvement would be mentioning pagination explicitly, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by clarifying the default stage behavior and the interaction between 'all' and 'stage' parameters (e.g., 'all' ignored when stage is given).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists pitches in the authenticated user's deal pipeline, sorted newest first, with default stage triage and options for filtering. This distinguishes it from sibling list tools (e.g., list_companies) as it is the only pitch-specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (listing pitches) and how to filter by stage or get all stages. It does not explicitly mention alternatives or when not to use, but the context is clear and self-contained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tagsARead-onlyIdempotentInspect
List the authenticated user's tags alphabetically, each with the number of portfolio companies carrying it. Tag names feed the tag filter on list_companies; tags on pitches are listed but don't add to the count.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number (default 1). | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, destructiveHint. Description adds valuable behavioral details: alphabetical ordering, inclusion of counts, and special handling of pitch tags (listed but not counted).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence concisely conveys purpose, ordering, count behavior, and relationship to other tools. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately explains output (tag names with counts). For a simple list tool with known parameters, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (page and per_page) at 100% coverage. Description adds no additional meaning beyond what schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists authenticated user's tags alphabetically with count of portfolio companies. Distinguishes from list_companies by mentioning the tag filter and from pitch tags by noting they don't add to count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies when to use: to get tag names and their counts, especially before using list_companies filter. Does not explicitly state when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_transactionsARead-onlyIdempotentInspect
List the authenticated user's transactions (cash flows), newest first: buys, SAFEs, sells, distributions, and SAFE conversions. Filter by company slug, entity id, type, and/or date range. total_amount_by_type sums the full filtered set, not just the page. Amounts are USD.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only transactions on or before this ISO 8601 date (YYYY-MM-DD). | |
| from | No | Only transactions on or after this ISO 8601 date (YYYY-MM-DD). | |
| page | No | 1-indexed page number (default 1). | |
| type | No | Filter to one transaction type. | |
| entity | No | Only transactions made through this investing entity, by id (from list_entities). | |
| company | No | Only this company's transactions, by slug. | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful behavioral context: results are newest first, total_amount_by_type sums the full filtered set (not just the page), and amounts are in USD. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core purpose. It efficiently conveys essential information, though breaking into bullet points could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not specify what fields are returned per transaction. While annotations cover safety, the agent lacks knowledge of the response structure. The total_amount_by_type hint is helpful but incomplete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description rephrases filter options (company slug, entity id, type, date range) but does not add significant meaning beyond the schema's own descriptions. Missing any additional parameter nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the authenticated user's transactions, specifying they are cash flows sorted newest first, and enumerates the types (buys, SAFEs, sells, etc.). This distinguishes it from sibling tools like create_transaction or list_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists filter options but does not explicitly state when to use this tool versus alternatives (e.g., search or other list endpoints). It provides implied context through parameter descriptions but lacks when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_updatesARead-onlyIdempotentInspect
List investor updates (founder update emails) across the authenticated user's portfolio, newest first, each with its plain-text body and any operating metrics extracted from it. Filter by company slug and/or date range, or fetch a single update by id (search returns update ids). Slugs come from list_companies / search_companies.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Fetch one specific update by id — the id search returns for update hits. | |
| to | No | Only updates received on or before this ISO 8601 date (YYYY-MM-DD). | |
| from | No | Only updates received on or after this ISO 8601 date (YYYY-MM-DD). | |
| page | No | 1-indexed page number (default 1). | |
| company | No | Only this company's updates, by slug. | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds ordering ('newest first') and output content (plain-text body, metrics), providing some behavioral context beyond annotations. However, it doesn't disclose additional traits like rate limits or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly defines purpose and output, the second covers filtering and source info. Every sentence adds value with no redundancy, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return content (plain-text body, metrics). Parameter use is summarized and schema-covered. Pagination is implicitly covered by schema but not mentioned in description. Overall, it is sufficiently complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation. The description adds extra context by summarizing filtering options and explaining that slugs come from other tools and that search returns update ids for the id parameter, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists investor updates (founder update emails) with plain-text body and metrics, newest first. This distinguishes it from sibling list tools like list_companies or list_notes, as it specifies a unique resource and output details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains filtering by company slug and/or date range, and fetching a single update by id. It also tells where to get slugs (list_companies / search_companies). While it doesn't explicitly state when not to use this tool, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyIdempotentInspect
Search everything in the authenticated user's Signed account in one call: portfolio companies, pipeline pitches, people, notes, and documents (founder updates and uploaded files), with a short snippet for each text match. Use search_companies instead when you only need to resolve a company name to a slug.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query. | |
| limit | No | Max results per type (default 10, max 25). | |
| types | No | Only return these result types (default: all). updates are founder update emails; files are uploaded documents. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: it returns short snippets for each text match, which is not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first covers scope and output snippet behavior, second provides usage guidance for alternative. No superfluous words; efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains result includes snippets and covers all searched types. It also mentions the alternative tool. Lacks detail on result structure, but sufficient for a search tool with annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds clarity by explaining the meaning of types enum values (e.g., 'updates are founder update emails; files are uploaded documents'), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches across multiple content types (companies, pitches, people, notes, documents) with snippets. Explicitly distinguishes from sibling 'search_companies' by stating when to use that tool instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use this for broad search, and use search_companies specifically when only needing to resolve a company name to a slug. This helps the agent decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_companiesARead-onlyIdempotentInspect
Search the authenticated user's companies (portfolio and pipeline) by name, domain, or entity name.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query — matched against company name, domain, and entity name. | |
| page | No | 1-indexed page number (default 1). | |
| per_page | No | Results per page (default 30, max 100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety traits (readOnlyHint, idempotentHint, destructiveHint). The description adds valuable context that the search is scoped to the authenticated user's portfolio and pipeline. However, it does not disclose pagination behavior or result format, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core functionality. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the output format, which is not provided in an output schema. Given the presence of sibling list tools and annotations, it covers basic context but leaves some practical usage details (like case sensitivity or exact matching) unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter already has a description. The tool description echoes the search fields but adds no new semantic information beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the authenticated user's companies by name, domain, or entity name, specifying the resource and action. However, it does not explicitly differentiate from sibling tools like 'search' or 'list_companies', making it slightly less sharp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs alternatives. It implies searching within the user's companies, but does not mention when not to use it or which sibling tools (e.g., 'search', 'list_companies') might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiARead-onlyIdempotentInspect
The authenticated Signed user's own profile: name, login, email, plan, and investing preferences. Aggregate portfolio metrics live on get_portfolio.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds specific fields returned (name, login, email, plan, investing preferences), which is beyond what annotations cover. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information, zero waste. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-param tool with no output schema, description covers return fields adequately and points to alternative for missing data. Complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Per guidelines, baseline is 4. Description does not need to add param semantics as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns the authenticated user's own profile. Differentiates from sibling get_portfolio by noting aggregate portfolio metrics are there. The verb 'whoami' implies identity retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to get_portfolio for aggregate portfolio metrics, providing clear guidance on when not to use this tool and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!